Spelling suggestions: "subject:"requisitos n?ofuncionais"" "subject:"requisitos n?funcionais""
1 |
Um estudo de avalia??o e documenta??o de arquiteturas de software na ind?striaSilva, J?lio C?sar Le?ncio da 25 August 2016 (has links)
Submitted by Automa??o e Estat?stica (sst@bczm.ufrn.br) on 2017-03-21T18:19:38Z
No. of bitstreams: 1
JulioCesarLeoncioDaSilva_DISSERT.pdf: 1394881 bytes, checksum: 747cd2cfe814ce2f10219f841055abdb (MD5) / Approved for entry into archive by Arlan Eloi Leite Silva (eloihistoriador@yahoo.com.br) on 2017-03-27T21:23:41Z (GMT) No. of bitstreams: 1
JulioCesarLeoncioDaSilva_DISSERT.pdf: 1394881 bytes, checksum: 747cd2cfe814ce2f10219f841055abdb (MD5) / Made available in DSpace on 2017-03-27T21:23:41Z (GMT). No. of bitstreams: 1
JulioCesarLeoncioDaSilva_DISSERT.pdf: 1394881 bytes, checksum: 747cd2cfe814ce2f10219f841055abdb (MD5)
Previous issue date: 2016-08-25 / Muitas vezes o arquiteto de software respons?vel pela defini??o e avalia??o da arquitetura
de software n?o consegue estabelecer quais requisitos n?o-funcionais devem ser priorizados
no desenvolvimento de seus sistemas. Com isso, falhas podem ocorrer durante a execu??o do
sistema demandando mais tempo e recursos para que seja corrigido. Em muitos casos, com
a inexperi?ncia dos arquitetos ou a necessidade de disponibiliza??o r?pida de um sistema,
os requisitos n?o-funcionais n?o s?o considerados durante a defini??o da arquitetura de
software e tamb?m n?o ? feita a devida documenta??o da arquitetura, tornando dif?cil o
acesso e entendimento da arquitetura pelos demais integrantes da equipe e dificultando a
manuten??o de componentes/m?dulos da arquitetura e respectivos relacionamentos. Este
trabalho buscou levantar junto ?s empresas de software, p?blicas e privadas, quais as
principais estrat?gias utilizadas na defini??o e avalia??o da arquitetura, principalmente
na obten??o e cumprimento dos requisitos n?o-funcionais, e documenta??o arquitetural.
Nosso estudo contou com a participa??o de 17 arquitetos de software para responder o
question?rio proposto. Com a realiza??o do question?rio identificamos que os requisitos
n?o-funcionais de desempenho e confiabilidade s?o os mais importantes a serem atendidos
pela arquitetura e que mesmo com a exist?ncia de algumas abordagens para a avalia??o
de arquiteturas, elas n?o parecem estar bem difundidas e/ou utilizadas entre os arquitetos.
Ao tratar especificamente o requisito de desempenho, os arquitetos julgaram que em
uma an?lise de desempenho de um sistema de software a informa??o mais importante
a ser exibida deve ser o tempo de resposta das requisi??es a um determinado cen?rio,
acompanhado do tempo de execu??o dos m?todos que fazem parte desse cen?rio. Em
rela??o ? documenta??o arquitetural, a maioria dos entrevistados afirmaram utilizar, no
m?nimo, algum tipo de documenta??o no momento de cria??o de um sistema de software,
destacando-se a utiliza??o de diagramas de classe e de componentes como as formas mais
comuns de documenta??o utilizadas pelos arquitetos. Al?m disso, o trabalho prop?e a
utiliza??o de um guia que busca auxiliar arquitetos de software na atividade de avalia??o
do cumprimento dos requisitos n?o-funcionais pela arquitetura durante a evolu??o do
sistema, priorizando o requisito n?o-funcional de desempenho. Ao avaliar a aplica??o
do guia, os entrevistados apontaram a abordagem de an?lise de logs para identificar os
cen?rios priorit?rios numa avalia??o de desempenho como uma das principais contribui??es
do guia e que poderia facilitar na identifica??o e compara??o das vers?es dos seus sistemas. / Usually, the software architect responsible for the software architecture definition and
evaluation cannot prioritize which non-functional requirements must be prioritized during
the development of their systems. Because of that, failures may happen during the system
execution requiring more time and resources to fix them. In many cases, due to the
inexperience of architects or the need for rapid deployment of a system, the non-functional
requirements are not considered in the software architecture definition phase and its
documentation is absent or incomplete, making the software architecture difficult to be
understood, modified and envolved by other team members. This work investigates the
main strategies and techniques used to document software architectures and to evaluate
non-functional requirements by existing software development companies. Our study had
the participation of 17 software architects to answer the survey. Our work identified
that performance and reliability non-functional requirements are the most important
to be addressed by the architecture and even with the existence of some approaches to
evaluate architectures, they do not seem to be disseminated and used among architects.
The architects judged that in a performance analysis of a software system the most
important information to be displayed should be the response time of the system scenarios.
Regarding architecture documentation, most interviewees stated that they used some
kind of documentation. The use of class diagrams and component diagrams are the most
common forms of documentation used by architects. Besides that, we propose a guide
to help software architects in the task of achieving such non-functional requirements
during the evolution of software systems. The proposed guide prioritizes the non-functional
requirement of performance. The logs analysis approach to identify priority scenarios in a
performance assessment was pointed out as one of the key contributions of the guide and
could facilitate the identification and comparison of the versions of their systems.
|
2 |
MoSAC: um m?dulo para sele??o de configura??es arquiteturais baseado em crit?rios de QoS no contexto de sistema distribu?dos autoadaptativosSilva, Daniel Cunha da 17 February 2011 (has links)
Made available in DSpace on 2014-12-17T15:47:53Z (GMT). No. of bitstreams: 1
DanielCS_DISSERT.pdf: 2517555 bytes, checksum: 7a87d4943b3ba068ea03a2691bda7bff (MD5)
Previous issue date: 2011-02-17 / The process for choosing the best components to build systems has become increasingly
complex. It becomes more critical if it was need to consider many combinations of
components in the context of an architectural configuration. These circumstances occur,
mainly, when we have to deal with systems involving critical requirements, such as the
timing constraints in distributed multimedia systems, the network bandwidth in mobile
applications or even the reliability in real-time systems. This work proposes a process
of dynamic selection of architectural configurations based on non-functional requirements
criteria of the system, which can be used during a dynamic adaptation. This proposal
uses the MAUT theory (Multi-Attribute Utility Theory) for decision making from a finite
set of possibilities, which involve multiple criteria to be analyzed. Additionally, it was
proposed a metamodel which can be used to describe the application s requirements in
terms of the non-functional requirements criteria and their expected values, to express
them in order to make the selection of the desired configuration. As a proof of concept,
it was implemented a module that performs the dynamic choice of configurations, the
MoSAC. This module was implemented using a component-based development approach
(CBD), performing a selection of architectural configurations based on the proposed selection
process involving multiple criteria. This work also presents a case study where an
application was developed in the context of Digital TV to evaluate the time spent on the
module to return a valid configuration to be used in a middleware with autoadaptative
features, the middleware AdaptTV / O processo para a escolha dos melhores componentes a serem usados na constru??o de sistemas tem se tornado cada vez mais complexo; isso se torna mais cr?tico quando precisamos considerar v?rias combina??es de componentes a serem escolhidos no contexto de uma configura??o arquitetural. Essa preocupa??o ocorre, principalmente, quando lidamos com sistemas que envolvem requisitos cr?ticos, como por exemplo, as restri??es temporais nos sistemas multim?dia distribu?dos, a largura de banda da rede nas aplica??es m?veis ou at? mesmo a confiabilidade em sistemas de tempo real. Este trabalho prop?e um processo de sele??o din?mica de configura??es arquiteturais baseado nos requisitos n?o funcionais do sistema, os quais poder?o ser utilizados durante uma adapta??o din?mica. A presente proposta utiliza a teoria MAUT (Multi-Attribute Utility Theory) para a tomada de decis?o a partir de um conjunto finito de possibilidades, as quais envolvem m?ltiplos crit?rios a serem analisados. Adicionalmente, foi proposto um metamodelo capaz de descrever as necessidades da aplica??o, em termos dos requisitos n?o funcionais e seus respectivos valores esperados, para que as mesmas possam ser interpretadas pelo processo a fim de realizar a sele??o da configura??o desejada. Como prova de conceito, foi implementado um m?dulo que realiza a escolha din?mica das configura??es, o MoSAC. Esse m?dulo foi implementado utilizando a abordagem de desenvolvimento baseado em componentes (DBC) realizando a sele??o das configura??es arquiteturais baseado no processo de sele??o proposto neste trabalho envolvendo m?ltiplos crit?rios. Esse trabalho tamb?m apresenta um estudo do caso onde foi desenvolvido uma aplica??o no contexto de TV Digital para avaliar o tempo que o m?dulo gasta para retornar uma configura??o v?lida a ser utilizada em um middleware com caracter?sticas autoadaptativas; para isso foi utilizado o middleware AdaptTV
|
3 |
Um m?todo semi-automatizado para elicita??o de requisitos de acessibilidade Web / A semi-automated method for elicitation of Web accessibility requirementsOliveira, Romeu Ferreira de 26 February 2014 (has links)
Made available in DSpace on 2014-12-17T15:48:11Z (GMT). No. of bitstreams: 1
RomeuFO_DISSERT.pdf: 4788717 bytes, checksum: 385df6854e63e9219358e4b7d5fe1ee8 (MD5)
Previous issue date: 2014-02-26 / Coordena??o de Aperfei?oamento de Pessoal de N?vel Superior / In the context of Software Engineering, web accessibility is gaining more room, establishing itself as an important quality attribute. This fact is due to initiatives of institutions such as the W3C (World Wide Web Consortium) and the introduction of norms and laws such as Section 508 that underlie the importance of developing accessible Web sites and applications. Despite these improvements, the lack of web accessibility is still a persistent problem, and could be related to the moment or phase in which this requirement is solved within the development process. From the moment when Web accessibility is generally regarded as a programming problem or treated when the application is already developed entirely. Thus, consider accessibility already during activities of analysis and requirements specification shows itself a strategy to facilitate project progress, avoiding rework in advanced phases of software development because of possible errors, or omissions in the elicitation. The objective of this research is to develop a method and a tool to support requirements elicitation of web accessibility. The strategy for the requirements elicitation of this method is grounded by the Goal-Oriented approach NFR Framework and the use of catalogs NFRs, created based on the guidelines contained in WCAG 2.0 (Web Content Accessibility Guideline) proposed by W3C / No contexto de Engenharia de Software, a Acessibilidade Web vem ganhando cada vez mais espa?o, se firmando como um importante atributo de qualidade. Esse fato se deve a iniciativas de institui??es como a W3C (World Wide Web Consortium) e ao surgimento de normas e leis como a Section 508 que fundamentam a import?ncia de elaborar sites e aplica??es Web acess?veis. Apesar dessas melhorias, a falta de acessibilidade na web ainda ? um problema persistente, e pode est? relacionada ao momento ou a fase em que este requisito ? tratado dentro do processo de desenvolvimento. Tendo em vista que a Acessibilidade Web geralmente ? considerada como um problema de programa??o ou tratada quando o aplicativo j? est? totalmente desenvolvido. Dessa forma, considerar a acessibilidade j? durante as atividades de an?lise e especifica??o de requisitos se mostra uma estrat?gia para facilitar o andamento do projeto, evitando retrabalho em fases avan?adas do desenvolvimento de software por causa de poss?veis erros, falhas ou omiss?es na elicita??o. O objetivo desta pesquisa ? desenvolver um m?todo e uma ferramenta para apoiar a elicita??o dos requisitos de acessibilidade web. A estrat?gia de elicita??o presente neste m?todo ? fundamentada atrav?s da abordagem orientada a metas do NFR Framework e na utiliza??o de cat?logos de RNFs, criados com base nas diretrizes contidas no WCAG 2.0 (Web Content Accessibility Guideline) proposto pela W3C
|
Page generated in 0.054 seconds