Spelling suggestions: "subject:"desenvolvimento dde software"" "subject:"desenvolvimento dee software""
411 |
[en] A CONTROLLABLE SOFTWARE DEVELOPMENT PROCESS WITH EMPHASIS ON QUALITY ASSURANCE IN SMALL PROJECTS / [pt] UM PROCESSO CONTROLÁVEL DE DESENVOLVIMENTO DE SOFTWARE FOCADO NA GESTÃO DA QUALIDADE EM PEQUENOS PROJETOSDANIEL CATUNDA MARRECO 16 October 2006 (has links)
[pt] O trabalho a seguir apresenta uma proposta de metodologia
de gerência de
projetos de software aderente a pequenos projetos e
fortemente inspirada em
metodologias já consagradas como Unified Process e eXtreme
Programming. O
objetivo é prover um processo ágil, adaptável porém
prescritivo. Chegaremos a
um processo de fácil implantação e controle e menos
dependente da qualidade
técnica da equipe de desenvolvimento. A seguir, será
apresentado um estudo de
caso conduzido em ambiente real, por uma equipe de um
pequeno
empreendimento que consiste no relato do processo de
amadurecimento e
implantação do processo proposto, com uma análise do
trabalho de implantação
de processos de desenvolvimento em empreendimentos
emergentes na área de TI. / [en] The following work presents a proposal of software project
management
methodology applicable to small projects and strongly
inspired by already well
established methodologies such as the Unified Process and
eXtreme
Programming. The objective of this proposal is to provide
an agile process that is
adaptable yet prescriptive. Through this one plans to
arrive at a process of easy
implementation and control, and less dependent on the
technical quality of the
development team. Subsequently, a case study will be
presented that was
conducted in a real environment, on a small enterprise
development team. It
consists of a report on the maturing and implementation of
the proposed process
and an analysis of the work of implementing development
procedures in emerging
enterprises in the IT area.
|
412 |
CrossMDA-SPL: uma abordagem para ger?ncia de variabilidades dirigida por modelos e aspectosFilgueira, Geam Carlos de Ara?jo 11 August 2009 (has links)
Made available in DSpace on 2014-12-17T15:47:51Z (GMT). No. of bitstreams: 1
GeamCA_3.pdf: 4100171 bytes, checksum: a5754ac2b6b60fbd217e904c104737e4 (MD5)
Previous issue date: 2009-08-11 / This paper proposes a systematic approach to management of variability modelsdriven and aspects using the mechanisms of approaches Aspect-Oriented Software Development (AOSD) and Model-Driven Development (MDD). The main goal of the approach, named CrossMDA-SPL, is to improve the management(ger?ncia), modularization and isolation ou separation of the variability of the LPSs of architecture in a high level of abstraction (model) at the design and implementing phases of development Software Product Lines (SPLs), exploiting the synergy between AOSD and MDD. The CrossMDA-SPL approach defines some artifacts basis for advance the separation clear in between the mandatory (bounden) and optional features in the architecture of SPL. The artifacts are represented by two models named: (i) core model (base domain) - responsible for specify the common features the all members of the SPL, and (ii) variability model - responsible for represent the variables features of SPL. In addition, the CrossMDA-SPL approach is composed of: (i) guidelines for modeling and representation of variability, (ii) CrossMDA-SPL services and process, and (iii) models of the architecture of SPL or product instance of SPL. The guidelines use the advantages of AOSD and MDD to promote a better modularization of the variable features of the architecture of SPL during the creation of core and variability models of the approach. The services and sub-processes are responsible for combination automatically, through of process of transformation between the core and variability models, and the generation of new models that represent the implementation of the architecture of SPL or a instance model of SPL. Mechanisms for effective modularization of variability for architectures of SPL at model level. The concepts are described and measured with the execution of a case study of an SPL for management systems of transport electronic tickets / Este trabalho prop?e uma abordagem sistem?tica para ger?ncia de variabilidades dirigida por Modelos e Aspectos usando os mecanismos das abordagens de Desenvolvimento de Software Orientado a Aspectos (DSOA) e Desenvolvimento Dirigido por Modelos (DDM). O objetivo central da abordagem, denominada CrossMDA-SPL, ? melhorar a ger?ncia, modulariza??o e isolamento das variabilidades da arquitetura de LPSs em um n?vel de abstra??o alto (modelo) nas fases de projeto e implementa??o de dom?nio de desenvolvimento de Linhas de Produto de Software (LPSs), explorando a sinergia entre o DSOA e DDM. A abordagem CrossMDA-SPL define alguns artefatos base para promover a separa??o clara entres as features mandat?rias (obrigat?rias) e opcionais na arquitetura da LPS. Os artefatos s?o representados por dois modelos denominados: (i) modelo do n?cleo (dom?nio base) respons?vel por especificar as features comuns a todos os membros da LPS; e (ii) modelo de variabilidades respons?vel por representar as features vari?veis da LPS. Em adi??o, a abordagem CrossMDA-SPL ? composta por: (i) diretrizes para modelagem e representa??o das variabilidades; (ii) servi?os e processo CrossMDA-SPL; e (iii) modelos da arquitetura da LPS ou inst?ncia do produto da LPS. As diretrizes utilizam as vantagens de DSOA e DDM para promover uma melhor modulariza??o das features vari?veis da arquitetura da LPS durante a cria??o dos modelos do n?cleo e de variabilidades da abordagem. Os servi?os e subprocessos s?o respons?veis pela combina??o autom?tica, atrav?s de processos de transforma??o, entre os modelos de n?cleo e variabilidades, e a gera??o dos novos modelos que representam a implementa??o da arquitetura de LPS ou um modelo de inst?ncia da LPS. Apresentamos mecanismos para uma eficaz modulariza??o de variabilidades para arquiteturas de LPS no n?vel de modelo. Os conceitos s?o mostrados e avaliados com a execu??o de um estudo de caso de uma LPS para sistemas de gerenciamento de bilhetes eletr?nicos de transporte.
|
413 |
GingaForAll: linha de Produtos do Middleware GingaPereira, Lucas Silva 16 December 2010 (has links)
Made available in DSpace on 2014-12-17T15:47:55Z (GMT). No. of bitstreams: 1
LucasSP_DISSERT.pdf: 4412437 bytes, checksum: 1797ce9cec4016d1d5518d6d933435d2 (MD5)
Previous issue date: 2010-12-16 / Many challenges have been imposed on the middleware to support applications for
digital TV because of the heterogeneity and resource constraints of execution
platforms. In this scenario, the middleware must be highly configurable so that it can
be customized to meet the requirements of applications and underlying platforms.
This work aims to present the GingaForAll, a software product line developed for the
Ginga - the middleware of the Brazilian Digital TV (SBTVD). GingaForAll adds the
concepts of software product line, aspect orientation and model-driven development
to allow: (i) the specification of the common characteristics and variables of the
middleware, (ii) the modularization of crosscutting concerns - both mandatory and
concepts variables - through aspects, (iii) the expression of concepts as a set of
models that increase the level of abstraction and enables management of various
software artifacts in terms of configurable models. This work presents the
architecture of the software product line that implements such a tool and architecture
that supports automatic customization of middleware. The work also presents a tool
that implements the process of generating products GingaForAll / V?rios desafios t?m sido impostos a middleware para suporte a aplica??es de
TV digital devido a heterogeneidade e restri??es de recursos das plataformas de
execu??o. Nesse cen?rio, o middleware deve ser altamente configur?vel de forma a
poder ser customizado para atender aos requisitos das aplica??es e das plataformas
subjacentes. Esse trabalho tem como objetivo apresentar o GingaForAll, uma linha
de produtos de software desenvolvida para o Ginga o middleware do Sistema
Brasileiro de TV Digital (SBTVD). GingaForAll agrega os conceitos de linha de
produtos de software, orienta??o a aspectos e desenvolvimento dirigido a modelos
de forma a permitir: (i) a especifica??o das caracter?sticas comuns e vari?veis do
middleware; (ii) a modulariza??o dos conceitos transversais tanto conceitos
obrigat?rios quanto vari?veis atrav?s de aspectos; (iii) a express?o de conceitos
como um conjunto de modelos que aumentam o n?vel de abstra??o e permite o
gerenciamento de diferentes artefatos de software em termos de modelos
configur?veis. Esse trabalho apresenta a arquitetura da linha de produtos de
software e uma ferramenta que implementa tal arquitetura e que oferece suporte
para customiza??es autom?ticas do middleware. O trabalho tamb?m apresenta uma
ferramenta que implementa o processo de gera??o de produtos GingaForAll
|
414 |
Um modelo conceitual baseado em MDD e padr?es para evolu??o de sistemas OAMarinho, ?berton da Silva 02 August 2010 (has links)
Made available in DSpace on 2014-12-17T15:47:59Z (GMT). No. of bitstreams: 1
EbertonSM_DISSERT.pdf: 4801479 bytes, checksum: 4ff5d2fe556a6d3554decf638f20261c (MD5)
Previous issue date: 2010-08-02 / Aspect-Oriented Software Development (AOSD) is a technique that complements the Object-
Oriented Software Development (OOSD) modularizing several concepts that OOSD
approaches do not modularize appropriately. However, the current state-of-the art on AOSD
suffers with software evolution, mainly because aspect definition can stop to work correctly
when base elements evolve. A promising approach to deal with that problem is the definition
of model-based pointcuts, where pointcuts are defined based on a conceptual model. That
strategy makes pointcut less prone to software evolution than model-base elements. Based on
that strategy, this work defines a conceptual model at high abstraction level where we can
specify software patterns and architectures that through Model Driven Development
techniques they can be instantiated and composed in architecture description language that
allows aspect modeling at architecture level. Our MDD approach allows propagate concepts
in architecture level to another abstraction levels (design level, for example) through MDA
transformation rules.
Also, this work shows a plug-in implemented to Eclipse platform called
AOADLwithCM. That plug-in was created to support our development process. The
AOADLwithCM plug-in was used to describe a case study based on MobileMedia System.
MobileMedia case study shows step-by-step how the Conceptual Model approach could
minimize Pointcut Fragile Problems, due to software evolution. MobileMedia case study was
used as input to analyses evolutions on software according to software metrics proposed by
KHATCHADOURIAN, GREENWOOD and RASHID. Also, we analyze how evolution in
base model could affect maintenance on aspectual model with and without Conceptual Model
approaches / O Desenvolvimento de Software Orientado a Aspectos (DSOA) ? uma t?cnica que
complementa o Desenvolvimento de Software Orientado a Objetos (DSOO) modularizando
diversos conceitos que as abordagens para suporte ao DSOO n?o conseguiam modularizar
adequadamente. No entanto, o estado da arte atual do DSOA sofre com a evolu??o de
software, principalmente porque as defini??es de aspectos podem deixar de funcionar
corretamente quando elementos do Modelo Base evoluem. Uma abordagem promissora para
tratar este problema ? a defini??o de pontos de corte (pointcuts) baseados em modelos (model
based-pointcuts), onde pontos de corte s?o definidos em termos de elementos de um Modelo
Conceitual que s?o menos suscept?veis a evolu??o que elementos do Modelo Base. Com base
nessa estrat?gia, este trabalho define um Modelo Conceitual em um alto n?vel de abstra??o
onde se podem definir padr?es de software e de arquiteturas que atrav?s de t?cnicas de
Desenvolvimento Dirigido a Modelos (Model Driven Development -MDD) podem ser
instanciados e compostos em linguagens de descri??o arquitetural que suportem a modelagem
de aspectos em n?vel de arquitetura. A abordagem MDD empregada permite ainda a
propaga??o de conceitos descritos no Modelo Conceitual para outros n?veis de abstra??es
como o de projeto com o uso de regras de transforma??o MDA (Model Driven Architecture).
Este trabalho tamb?m mostra o plug-in para a plataforma Eclipse chamado de
AOADLwithCM que foi implementado para dar suporte ao processo de desenvolvimento
abordado. Esse plug-in foi utilizado para implementar um estudo de caso baseado no Sistema
MobileMedia. Tal estudo de caso ilustra passo-a-passo a t?cnica que utiliza um Modelo
Conceitual no DSOA para minimizar problemas de evolu??o (mais especificamente a
Fragilidade de Pontos de Corte). O MobileMedia tamb?m foi usado como fonte para an?lise
da abordagem sob m?tricas de software propostas por KHATCHADOURIAN,
GREENWOOD e RASHID, e sob a perspectiva de manutenabilidade de software com e sem
o Modelo Conceitual
|
415 |
Uma técnica para verificar não-conformidades em Programas Especificados com Contratos. / A technique for verifying nonconformities in Specified Programs with Contracts.OLIVEIRA, Catuxe Varjão de Santana. 31 August 2018 (has links)
Submitted by Johnny Rodrigues (johnnyrodrigues@ufcg.edu.br) on 2018-08-31T22:55:43Z
No. of bitstreams: 1
CATUXE VARJÃO DE SANTANA OLIVEIRA - PPGCC DISSERTAÇÃO 2013..pdf: 11354934 bytes, checksum: 6a23f31ef43ba211aeaa89eb36061a43 (MD5) / Made available in DSpace on 2018-08-31T22:55:43Z (GMT). No. of bitstreams: 1
CATUXE VARJÃO DE SANTANA OLIVEIRA - PPGCC DISSERTAÇÃO 2013..pdf: 11354934 bytes, checksum: 6a23f31ef43ba211aeaa89eb36061a43 (MD5)
Previous issue date: 2013-03-15 / A escrita de especificações formais por contratos é uma maneira confiável e prática de
construir softwares, em que desenvolvedores e clientes mantêm um acordo contendo direitos e obrigações a serem cumpridos. Essas responsabilidades são expressas basicamente através de pré-condições, pós-condições, e invariantes. Como exemplo de linguagem de especificação por contrato tem-se Java Modeling Language (JML) específica para programas Java. Apesar de a especificação formal melhorar a confiabilidade do software, deve-se haver certificação de que a implementação está em conformidade com a especificação definida. Verificação de conformidade em programas com contratos é geralmente realizada através de análises manuais ou verificação dinâmica, e em fases tardias do processo de desenvolvimento do software, ou seja, quando o produto final encontra-se disponível para o cliente. Nesta situação, o tempo despendido para detectar não-conformidades pode ser muito longo, ocasionando, consequentemente, atrasos no cronograma e aumento nos custos. Neste trabalho,
propomos uma abordagem para checar conformidade entre código fonte e especificação
formal por contratos através da geração e execução de testes. Testes de unidade são
gerados automaticamente, resultando em casos de testes com sequências de chamadas aos métodos e construtores. Os contratos são transformados em assertivas que funcionam como oráculo para os testes. Esta abordagem não garante corretude total do software, mas aumenta a confiança quando uma não-conformidade é encontrada e, além disso, encoraja o uso de especificação por contratos. Nós implementamos JMLOK, uma ferramenta que executa os passos desta abordagem automaticamente no contexto de programas Java especificados com Java Modeling Language (JML). JMLOK foi avaliada em grupos de programas Java/JML, incluindo um módulo do projeto JavaCard. Todas as unidades experimentais totalizam 18 KLOC e 5K de linhas de especificação JML. Todo o processo consumiu menos que 10 minutos de execução e gerou como resultado a detecção de 29 não-conformidades. As causas das ocorrências das não-conformidades foram analisadas manualmente e classificadas em categorias de falhas. / Writing formal specifications by contracts is a practical and reliable way to build softwares
in which developers and clients keep an agreement with rights and obligations to be fulfilled. These responsibilities are expressed basically by pre-conditions, post-conditions and invariants. As example of specification language by contract there is Java Modeling Language (JML) that is specific to Java programs. Although formal specification improves software rehabihty, it should exist certification of conformance with defined specification. Verify conformance between programs and contracts is usually performed by manual analysis or dynamic verification, and in late stages of software development process, that is, when the final product is available to client. In this situation, the time required to detect nonconformances could be so long, causing, consequently, schedule delays and increased costs. In this work, we propose an approach to check conformance between source code and contract formal specification through testing generation and execution. Unit tests are generated automatically resulting in test cases with call sequences of methods and constructors. The contracts are translated in assertions that work like test oracle. We have implemented JMLOK, a tool performs the approach steps automatically in the context of Java programs specified with Java Modeling Language (JML). JMLOK was evaluated in Java/JML programs groups, including a module of the JavaCard project. All the experimental units totalize 18 KLOC and 5K lines of JML specification. All process took less than 10 minutes of running and generated as result 29 nonconformances. The causes of nonconformances occurring were analyzed manually and classified in categories of fails.
|
416 |
[en] AWARE SOFTWARE DEVELOPMENT BASED ON REQUIREMENTS / [pt] DESENVOLVIMENTO DE SOFTWARE CONSCIENTE COM BASE EM REQUISITOSHERBET DE SOUZA CUNHA 25 March 2015 (has links)
[pt] Consciência de software (software awareness) tornou-se um requisito importante na construção de sistemas com capacidade de autoadaptação. Para que aplicações de software possam melhor se adaptar a mudanças nos diversos ambientes em que operam, ter consciência (no sentido de perceber e entender esses ambientes e a seu próprio funcionamento nestes ambientes) é fundamental. Entretanto, mesmo em um nível básico aplicado a software, consciência é um requisito difícil de definir. Nosso trabalho propõe a organização de um catálogo para o requisito de consciência de software, com mecanismos para instanciação e uso do conhecimento armazenado neste catálogo na modelagem e implementação de software para problemas onde a autoadaptação, e por consequência consciência, sejam requisitos chave. / [en] Software awareness has become an important requirement in the construction of self-adaptive systems. As such, the software should better adapt to changes in the various environments in which they operate, be aware of (in the sense of perceiving and understanding) these environment and be aware of its own operation in these environments. However, even at a basic level applied to software, awareness is a requirement difficult to define. Our work proposes the creation of a catalog to the awareness requirement through non-functional requirements patterns (NFR patterns). We also propose mechanisms for enabling the instantiation and use of the knowledge about awareness, represented in this catalog.
|
417 |
Uma abordagem apoiada por linguagens especificas de domínio para criação de linhas de produtos de software embarcadoDurelli, Rafael Serapilha 30 May 2011 (has links)
Made available in DSpace on 2016-06-02T19:05:51Z (GMT). No. of bitstreams: 1
3769.pdf: 7885518 bytes, checksum: 7723f0868651af930744610d4adb9ccb (MD5)
Previous issue date: 2011-05-30 / Financiadora de Estudos e Projetos / Embedded systems have been used in a myriad of devices that are present in our daily lives, thereby the market for such sort of system has increased significantly over the last few years. These systems were once associated with low-level code, however, this is an outdated view of embedded systems technology. Although the current embedded systems are mostly composed of software, no systematic reuse technique is used in throughout their development. Thus, since previous successful experiences are not reused, forcing the developer to create some of the involved elements from the scratch, there is a considerable delay in the production of these systems. Due to the ever increasing complexity of embedded systems it is necessary to apply reuse techniques in order to lessen the effort needed to develop such systems. Within this context, software product lines (SPL) are reuse techniques that allow the creation of several systems belonging to a certain domain. SPL can be used to generate products of a specific domain that share common features but are each different in a specific way. Model-driven development is another reuse technique whose main objective is to reduce the semantic distance between the domain problem and its solution/implementation; thus, the developer does not need to direct interact with the solution source code, being able to focus on models and transforming those models in source code or yet other models. Based on these techniques, a process for the development of SPL in the domain of mobile robots was developed. In order to properly use the proposed process, a SPL called LegoMobileRobots Software Product Line (LMRSPL) was devised. Moreover, a domain specific language (DSL) was also developed. This DSL, called F2MoC, assists the application engineer in instantiating LMRSPL members. / Sistemas embarcados são utilizados em vários dispositivos que fazem parte da vida cotidiana, de modo que o mercado de tais sistemas tem crescido de maneira expressiva. Esses sistemas sempre foram associados com código de baixo nível, no entanto, essa visão está desatualizada. Nas aplicações embarcadas correntes o software é a principal parcela, embora nenhuma técnica sistemática de reuso seja utilizada para sua concepção. Desse modo ocorre um atraso considerável na produtividade dos sistemas, uma vez que experiências anteriores bem sucedidas não são reaproveitadas, sendo necessário que o desenvolvedor comece do zero toda vez que um software for desenvolvido. Com a crescente complexidade dos sistemas embarcados é necessário utilizar técnicas de reuso para diminuir o atrasado da produção de tais sistemas. Nesse contexto, Linha de Produtos de Software (LPS) é definida como uma técnica de reuso que permite a construção de vários sistemas pertencentes a um mesmo domínio. LPS é aplicável para a geração de produtos específicos de um domínio, mas que possuem um conjunto de características comuns e pontos de variabilidades bem definidos. O Desenvolvimento de Software Orientado a Modelos (do inglês Model-Driven Development - MDD) é outra técnica de reuso na qual tem como principal objetivo reduzir a distância semântica entre o problema do domínio e solução/implementação, fazendo com que o engenheiro não precise interagir diretamente como o código-fonte, podendo se concentrar em modelos que possuem maiores níveis de abstração e posteriormente realizar transformações Model-To-Code e/ou Model-To-Model. A partir dessas técnicas de reuso é introduzido um processo para o desenvolvimento de linhas de produtos de software no domínio de Robôs Moveis. A fim de utilizar o processo proposto foi desenvolvida uma LPS intitulada LegoRobosMoveis Linha de Produtos de Software (LRMLPS). Adicionalmente, foi desenvolvida uma linguagem especifica de domínio denominada F2MoC que auxilia o engenheiro de aplicação na instanciação automática de membros da LRMLPS.
|
418 |
TAXOPETIC : proposta de uma taxonomia para a classificação dos artefatos gerados pela metodologia PETICFontes, Adriana de Melo 30 August 2016 (has links)
Advances in Information and Communication Technologies (ICT) can provide competitive
advantages for organizations. The search for innovations by organizations demand better
solutions for the constant technology and market advancements and the guarantee of quality
and satisfaction to its customers. In this sense, organizations need that the Strategic Planning
(PE) and ICT be integrated, coherent and with synergy to ensure the survival of organizations.
The PETIC Methodology is a form of PE that safely help managers identify the maturity and
consequent improvement of ICT processes required in company management. The growing
number of case studies of PETIC in organizations has shown a difficulty to locate and classify
PETIC Artifacts produced during these case studies. In this context, the use of classificatory
structures (taxonomies) has been successfully applied to the classification and retrieval of
information. This work proposes a taxonomy to support methodology PETIC called
TAXOPETIC. Among the various technical approaches to build a taxonomy, we opted for the
use of approaches Aganette et al. (2010) and Bayona-Oré et al. (2014). After the construction
of TAXOPETIC, we performed a comparative study between these used approaches. In this
paper, we present the reasons of choosing Bayonne-Oré et al approach. (2014). To test the
TAXOPETIC structure, a software product called TAXOPETICWeb was built. Among the
results, it was evident that the non-use of TAXOPETICWeb tool disables the centralized and
classified access to Artifacts PETIC legacy. The TAXOPETICWeb enables the storage of all
rated PETIC artifacts and, through the defined metadata tags, allows the most efficient
location and categorizes the artifacts stored in PETIC TAXOPETICWeb. / Os avanços das Tecnologias da Informação e Comunicação (TIC) podem proporcionar
diferenciais competitivos para as organizações. A busca de inovações pelas organizações
exige melhores soluções para o avanço constante da tecnologia e do mercado e a garantia de
qualidade e satisfação aos seus clientes. Nesse sentido, as organizações necessitam que o
Planejamento Estratégico (PE) e as TIC estejam integrados, coerentes e com sinergia para
garantir a sobrevivência das organizações. A Metodologia PETIC é uma forma de PE que, de
forma segura, ajuda gestores na identificação da maturidade e consequente melhoria dos
processos de TIC, necessários na gestão da empresa. O crescente número de estudos de caso
da PETIC em organizações tem evidenciado uma dificuldade de localizar e classificar os
Artefatos PETIC, produzidos durante esses estudos de caso. Nesse contexto, a utilização de
estruturas classificatórias (taxonomias) tem sido aplicada com sucesso para a classificação e a
recuperação de informações. Este trabalho propõe uma taxonomia para dar suporte à
Metodologia PETIC, denominada TAXOPETIC. Dentre as diversas abordagens técnicas para
a construção de uma taxonomia, optou-se pelo uso das abordagens de Aganette et al. (2010) e
Bayona-Oré et al. (2014). Após a construção da TAXOPETIC, foi realizado um estudo
comparativo entre essas abordagens utilizadas. Neste trabalho, são apresentados os motivos
pela escolha da abordagem de Bayona-Oré et al. (2014). Para testar a estrutura da
TAXOPETIC, foi construído um produto de software chamado TAXOPETICWeb. Entre os
resultados, ficou evidenciado que a não utilização da ferramenta TAXOPETICWeb
impossibilita o acesso centralizado e classificado do Artefatos PETIC legados. A
TAXOPETICWeb possibilita o armazenamento classificado de todos os Artefatos PETIC e,
por meio dos metadados e tags definidos, permite a localização mais eficiente e categoriza
dos Artefatos PETIC armazenados na TAXOPETICWeb.
|
419 |
Qualitas: uma modelo de processo de desenvolvimento de software orientado a modelosAlmeida, Carla Cássia de Jesus 25 February 2014 (has links)
The Model Driven Development (MDD) is a paradigm of development of software products, whose objective is to put the models as the main artifact of the development process, instead of putting the source code. In recent years, researches in Software Engineering area have created and adjusted definitions, methods and structures for the achievement of this paradigm. However, the models of the software development process, as well as testing activities
involved in these models are not adequate and do not allow the effective use of this paradigm. In order that the Software Engineering area has as it main goal, the development of software products with quality, it is also necessary that these models of the development process
involves increasingly approaches to software testing, with the intent to commit them from the early stages, aiming to identify and correct the errors as soon as possible, adding quality to the software. An approach that uses models in software testing is the Model Driven Testing (MDT), which one makes use of the MDD practices, through the automatic generation of test artifacts according to the rules of predefined transformation from development models. Thus,
this work presents the Qualitas, a model for the development of model-driven software, which
allows the use of both models in the effective integration of MDD and MDT. The model seeks to promote a greater control of the stages and activities of the software development process, but also to add quality to software products developed. A review and an experimental
study of Qualitas was performed through the implementation of activities related to the Federal University of Sergipe (UFS) Neonatal Screening System of the University Hospital
(HU) functionality, highlighting the advantages and limitations of the model presented. / O Model Driven Development (MDD) é um paradigma de desenvolvimento de produtos de software, cujo objetivo é colocar os modelos como o artefato central do processo de
desenvolvimento, ao invés do código-fonte. Nos últimos anos, pesquisas na área de Engenharia de Software têm criado e adaptado definições, métodos e estruturas para a realização desse paradigma. No entanto, os modelos de processo de desenvolvimento de software, bem como as atividades de testes envolvidas nestes modelos não são adequados e não permitem o uso efetivo desse paradigma. Tendo em vista que, a área de Engenharia de Software possui como objetivo principal o desenvolvimento de produtos de software com qualidade, é necessário também que estes modelos de processo de desenvolvimento envolvam cada vez mais abordagens de teste de software, com o intuito de realizá-los desde as fases
iniciais software, visando que os erros sejam identificados e corrigidos quanto mais cedo possível, agregando qualidade ao software. Uma abordagem que faz uso de modelos no teste
de software é o Model Driven Testing (MDT), a qual faz uso de práticas do MDD, através da geração automática de artefatos de teste de acordo com as regras de transformação prédefinidas
a partir de modelos de desenvolvimento. Desta forma, este trabalho apresenta o Qualitas, um modelo de processo para o desenvolvimento de software orientado a modelos, que possibilite tanto o uso de modelos quanto a efetiva integração do MDD e MDT. O modelo busca promover um maior controle das etapas e atividades do processo de desenvolvimento de software, como também agregar qualidade aos produtos de software desenvolvidos. Uma avaliação e um estudo experimental do Qualitas foi realizada através da implementação de funcionalidades relacionadas ao Sistema de Triagem Neonatal do Hospital Universitário (HU) da Universidade Federal de Sergipe (UFS), destacando as vantagens e mostrando as limitações do modelo.
|
420 |
Estudo do uso de vocabulários para analisar o impacto de relatórios de defeitos a código-fonte. / Study the use of vocabularies to analyze the impact of defect reports on source code.CAVALCANTI, Diego Tavares. 28 September 2018 (has links)
Submitted by Johnny Rodrigues (johnnyrodrigues@ufcg.edu.br) on 2018-09-28T14:01:43Z
No. of bitstreams: 1
DIEGO TAVARES CAVALCANTI - DISSERTAÇÃO PPGCC 2012..pdf: 11733349 bytes, checksum: 59909ce95d6ea71dea6e9686d3d20c33 (MD5) / Made available in DSpace on 2018-09-28T14:01:43Z (GMT). No. of bitstreams: 1
DIEGO TAVARES CAVALCANTI - DISSERTAÇÃO PPGCC 2012..pdf: 11733349 bytes, checksum: 59909ce95d6ea71dea6e9686d3d20c33 (MD5)
Previous issue date: 2012-11-26 / Localizar e corrigir defeitos são tarefas comuns no processo de manutenção de software.
Entretanto, a atividade de localizar entidades de código que são possivelmente defeituosas e que necessitam ser modificadas para a correção de um defeito, não é trivial. Geralmente, desenvolvedores realizam esta tarefa por meio de um processo manual de leitura e inspeção do código, bem como de informações cadastradas em relatórios de defeitos. De fato, é necessário que os desenvolvedores tenham um bom conhecimento da arquitetura e do design do software a fim de realizarem tal tarefa. Entretanto, este conhecimento fica espalhado por entre a equipe e requer tempo para ser adquirido por novatos. Assim, é necessário o desenvolvimento de técnicas que auxiliem na tarefa de análise de impacto de relatórios de defeitos no código, independente da experiência do desenvolvedor que irá executá-la. Neste trabalho, apresentamos resultados de um estudo empírico no qual avaliamos se a análise automática de vocabulários de relatórios de defeitos e de software pode ser útil na tarefa de localizar defeitos no código. Nele, analisamos similaridade de vocabulários como fator para sugerir classes que são prováveis de serem impactadas por um dado relatório de defeito. Realizamos
uma avaliação com oito projetos maduros de código aberto, desenvolvidos em Java, que
utilizam Bugzilla e JIRA como seus repositórios de defeitos. Nossos resultados indicam que a análise de ambos os vocabulários é, de fato, uma fonte valiosa de informação, que pode ser utilizada para agilizar a tarefa de localização de defeitos. Para todos os sistemas estudados, ao considerarmos apenas análise de vocabulário, vimos que, mesmo com um ranking contendo apenas 8% das classes de um projeto, foi possível encontrar classes relacionadas ao defeito buscado em até 75% dos casos. Portanto, podemos concluir que, mesmo que não possamos utilizar vocabulários de software e de relatórios de defeitos como únicas fontes de informação, eles certamente podem melhorar os resultados obtidos, ao serem combinados com técnicas complementares. / Locating and fixing bugs described in bug reports are routine tasks in software development processes. A major effort must be undertaken to successfully locate the (possibly faulty) entities in the code that must be worked on. Generally, developers map bug reports to code through manual reading and inspection of both bug reports and the code itself. In practice, they must rely on their knowledge about the software architecture and design to perform the mapping in an efficient and effective way. However, it is well known that architectural and design knowledge is spread out among developers. Hence, the success of such a task is directly depending on choosing the right developer. In this paper, we present results of an empirical study we performed to evaluate whether the automated analysis of bug reports and software vocabularies can be helpful in the task of locating bugs. We conducted our study on eight versions of six mature Java open-source projects that use Bugzilla and JIRA as bug tracking systems. In our study, we have used Information Retrieval techniques to assess the similarity of bug reports and code entities vocabularies. For each bug report, we ranked ali code entities according to the measured similarity. Our results indicate that vocabularies are indeed a valuable source of information that can be used to narrow down the bug-locating task. For ali the studied systems, considering vocabulary similarity only, a Top 8% list of entities has about 75% of the target entities. We conclude that while vocabularies cannot be the sole source of information, they can certainly improve results if combined with other techniques.
|
Page generated in 0.1097 seconds