Submitted by Fernanda Rodrigues de Lima (fernanda.rlima@ufpe.br) on 2018-08-17T22:02:46Z No. of bitstreams: 2 license_rdf: 811 bytes, checksum: e39d27027a6cc9cb039ad269a5db8e34 (MD5) DISSERTAÇÃO Fernando Benbassat.pdf: 3406584 bytes, checksum: 1784ed46d77c6f487559c2ceb21b516f (MD5) / Approved for entry into archive by Alice Araujo (alice.caraujo@ufpe.br) on 2018-08-24T21:05:42Z (GMT) No. of bitstreams: 2 license_rdf: 811 bytes, checksum: e39d27027a6cc9cb039ad269a5db8e34 (MD5) DISSERTAÇÃO Fernando Benbassat.pdf: 3406584 bytes, checksum: 1784ed46d77c6f487559c2ceb21b516f (MD5) / Made available in DSpace on 2018-08-24T21:05:42Z (GMT). No. of bitstreams: 2 license_rdf: 811 bytes, checksum: e39d27027a6cc9cb039ad269a5db8e34 (MD5) DISSERTAÇÃO Fernando Benbassat.pdf: 3406584 bytes, checksum: 1784ed46d77c6f487559c2ceb21b516f (MD5) Previous issue date: 2017-02-20 / Linhas de Produtos de Software (LPS) são conjuntos de produtos de software reutilizáveis que compartilham funcionalidades ou comportamento. Reusar um conjunto específico de produtos pode melhorar a produtividade e qualidade dos produtos oferecidos por uma empresa, no sentido de que novos produtos podem ser criados combinando de forma sistemática os artefatos existentes. Porém manter LPS não é tão simples, uma vez que uma única mudança em um artefato pode afetar vários produtos. Em muitas situações, é desejável proporcionar algum tipo de garantia para alterar uma LPS de forma segura, no sentido de que o comportamento dos produtos existentes é preservado após a alteração. Os desenvolvedores podem contar com noções de evolução segura propostas anteriormente e por meio de templates de transformação para assegurar a evolução segura. No entanto, os templates existentes focam apenas em situações em que LPS é expandida com o desenvolvimento de novas features, e não foram avaliadas no contexto da extração de features a partir do código existente. Por isso, para descobrir mais templates que se adequam à situações não previstas em estudos anteriores de evolução segura de Linhas de Produtos de Software (LPS), foi realizado um estudo utilizando um sistema industrial desenvolvido em Java, com aproximadamente 400 KLOC, com demanda para extração de features e transformação em LPS. Esse estudo revelou a necessidade de novos templates para lidar com cenários de extração de features, bem como melhorar a notação de templates existentes para tratar mapeamentos (Configuration Knowledge) mais expressivos entre expressões de features e artefatos de código. Como resultado deste estudo, nós propomos templates novos e que não podem ser derivados dos existentes, extraímos com sucesso LPS a partir do sistema existente usando os templates propostos, e também encontramos evidência de que os novos templates podem ajudar a prevenir defeitos durante a evolução de uma LPS. / Software Product Lines (LPS) are set of reusable software products that share functionality or behavior. Reusing a specific set of products can improve productivity and product quality offered by a company in the sense that new products can be created by systematically combining existing artifacts. But SPL maintenance is not simple, since a single change on asset can impact several products. In many situations, it is desirable to provide some assurance that we can safely change a SPL in the sense that the behaviour of existing products is preserved after the change. Developers can rely on previously proposed safe evolution notions and by means of transformation templates to ensure safe evolution. However, the existing templates focus only in scenarios where a SPL is expanded with the development of new features, and have not been evaluated in the context of extracting features from existing code. Therefore, to find out more templates that fit situations not foreseen in previous studies of the safe evolution of SPL, we conducted a study using an industrial system developed in Java, with roughly 400 KLOC, with demand for features extraction and transform into an SPL. This study revealed the need for new templates to address feature extraction scenarios, as well as improving the existing templates notation to address more expressive mappings (Configuration Knowledge) between feature expressions and code assets. As a result of this study, we propose new templates that can not be derived from existing ones, we successfully extracted a SPL from this existing system using the proposed templates, and also found evidence that the new templates can help to prevent defects during SPL evolution.

Orientador : Ana Cervigni Guerra / Dissertação (mestrado profissional) - Universidade Estadual de Campinas, Faculdade de Engenharia Mecanica / Made available in DSpace on 2018-08-03T09:10:03Z (GMT). No. of bitstreams: 1 Alves_AngelaMaria_M.pdf: 20770619 bytes, checksum: 600785cc9fa819534511325399eaeab0 (MD5) Previous issue date: 2002 / Resumo: Considerando que a Contratação de Produtos e Serviços de Software é atualmente não mais uma opção, mas sim uma ferramenta de gestão obrigatória a ser utilizada em organizações de natureza pública ou privada; considerando a necessidade de tais organizações se mostrarem competitivas no mercado local ou global, com produtos de boa qualidade e preços adequados; considerando a constante evolução das tecnologias para o desenvolvimento da Tecnologia da Informação e Sistemas de Informação, este trabalho tem como objetivo apresentar um ciclo de vida para o processo de contratação adequado para as empresas brasileiras e propor sugestões teóricas para dois dos processos desse ciclo: gestão de processos de contratação e seleção de contratados. O controle e o acompanhamento, com vistas à melhoria continua dos mencionados processos, aumentam as chances de obter projetos de contratação de produtos e serviços de software bem-sucedidos, com beneficios para todos os envolvidos no processo / Abstract: Considering that the Acquisition of Software Products and Services is not an option nowadays, but a rnandatory rnanagement tool to be used both in public and private organizations; considering the necessity of these organizations to be competitive in local and global markets, with products ofhigh quality and low prices; considering the constant evolution of technologies for the development of Information Technology and Information Systems, this work presents a life cyc1e for the acquisition processes which best :fit Brazilian companies and proposes theoretical suggestions for two of such processes: management and selection. Strict control and competent supervision, which are important to ensure the continuous improvement of the mentioned processes, increase the possibilities of getting successful projects of software products and services acquisition, with benefits for all those involved in the process / Mestrado / Mestre em Engenharia Mecânica

Orientadores: Paulo Licio de Geus, Thelma Chiossi / Dissertação (mestrado) - Universidade Estadual de Campinas, Instituto de Computação / Made available in DSpace on 2018-08-03T22:41:17Z (GMT). No. of bitstreams: 1 Macedo_MarcusViniciusLaRocca_M.pdf: 842436 bytes, checksum: 27c553ffbf6a5e8dd848ac57e803bdf8 (MD5) Previous issue date: 2003 / Resumo: Este trabalho apresenta uma proposta de contagem de pontos de função para aplicações de dispositivos portáteis (telefones celulares) tomando como base técnicas de contagem para aplicações de interface gráfica (GUI). A obtenção da contagem de pontos de função a partir de especificações funcionais e de layout fornecidas no início do projeto de desenvolvimento do produto de software abre a possibilidade de se estabelecer estimativas de custo (esforço) e duração mais precisas, beneficiando significativamente o planejamento do projeto. Nesse sentido são apresentadas algumas técnicas de estimativas de esforço. Também são apresentadas e comparadas algumas métricas de software com ênfase na métrica de pontos de função. Finalmente são apresentados os conceitos básicos de aplicações gráficas de telefones celulares e é estabelecido um paralelo na contagem de pontos de função para então se mostrar um exemplo prático de contagem utilizando este paralelo / Abstract: This dissertation presents a proposal of function point account for portable device (wireless phone) applications based on normal graphical user interface (GUI) application accounting techniques. The function point accounting done with functional and layout specification provided in the beginning of the software development project allows the establishment of cost (effort) estimation more precise, significantly improving the project planning. This way some effort estimation techniques are presented. Software metrics are also presented and compared with emphasis on function point metric. Finally, the basic concepts of graphical user interface wireless phone applications are presented and it is established a parallel in the function point accounting that is applied in a practical example / Mestrado / Engenharia de Computação / Mestre em Computação

In my thesis I focus on providing a foundation of data on whichdecision makers can base refactoring decisions. For this, I examine therelationship between software complexity and maintenance eort. Tomake the data a stronger basis for refactoring decisions, I present anew approach of correlating le metrics to maintenance eort, whereI look at the relation between changes in le metrics over multiplereleases and changes in the maintenance eort spent on these les. Ido this using a broadened and, more complete notion of maintenanceeort. I measure maintenance eort in 4 ways: the amount of lines ofcode that had to be changed to resolve tasks, the amount of discus-sion that tasks generated, the amount of atomic changes to a le thatwere required to resolve a task, and the amount of bugs per month.To test this framework, I extracted data from 3 open source projects,where I measured the variation of both complexity and maintenanceeort, using this new notion of eort, over multiple releases, and in-vestigated their correlation. I found that 21 of the tested metrics weresignicantly correlated to the eort measures, where complexity basedmetrics and incoming propagation cost show the highest correlation.Of the proposed measures for maintenance eort, the amount of dis-cussion to resolve an issue shows the highest correlation to the chosenmetrics.

No description available.

M.Sc. / The following questions led to this study: Why are there still so many approaches to the software generation process without one single approach taking the lead? Not only are there several methodologies available for the software generation process, but a methodology is not in use for long before it is replaced by an improved version or even another methodology. This is as a result of continuing further development and research. Sometimes the new methodology is not necessarily an improvement, but a paradigm shift. An example of this is object-orientation which followed shortly after the introduction of CASE as an alternative to software generation. Why are users to a large extent still dissatisfied and disillusioned with the software generation process even though they are more involved with it than before? User are more involved in the software generation process as a result of the availability of sophisticated tools, as well as joint sessions with the developer during the analysis and design stages of the software generation process. Yet, despite this, software systems in most cases still do not perform according to users' expectations. Why did the use of formal methodologies, based on successful techniques of the engineering field, only result in a limited improvement of the quality, control and operationalization of the software system? The cost of maintenance is still very high in relation to the total cost of generating a software system. The same degree of success attained in, say, the engineering field, could not be achieved [AND I]. Why is there a simultaneous movement towards incremental approaches and formal methods although these approaches are really moving in opposite directions? The incremental approach is based on obtaining quick results through prototyping without necessarily following a formal methodology [AND2]. Formal methods, on the other hand, attempt to formalize the software generation process through mathematical transformations. The advantage of using these mathematical transformations is that automation and verification of processes can be achieved [McC1]. Both these approaches show promising results, but the incremental approach might suit the developer better and is already used widely by practitioners. Why is it so difficult to find the correct methodology for generating a software system? The selection of an appropriate methodology is extremely difficult because of the variety of methodologies, technologies and hardware available. Some methodologies are also used for only a limited period because of rapid advances in technology. Why do sophisticated and user-friendly tools not succeed in simplifying the software generation process? Despite sophisticated tools such as CASE, where the user of these tools is guided through the different steps of the methodology, these tools have not succeeded in delivering the results expected by industry. The problems experienced during the software generation process are investigated. In order to distinguish between different approaches to software generation, is it necessary to place different approaches in relation to one another by considering the different elements of each. The characteristics and constraints of the software generation process must also be considered. All the issues pertaining to the software generation process will be discussed in terms of the problem statement.

The concept of software craftsmanship has roots in the earliest days of computing but has received comparably little attention from the research community.As a reaction to how Agile methods were practiced and taught in industry, in 2009, the Manifesto for Software Craftsmanship was formulated and published, drawing attention to the concept. Subsequent books and research papers have also elaborated on the concept. With this dissertation, we aim to study the software craftsmanship phenomenon using empirical software engineering methods.We developed an anatomy of software craftsmanship through a systematic literature study and a longitudinal case study, following a project consisting of multiple teams over several years.We also illustrate some consequences of not following through on the espoused craftsmanship practice of managing and account for technical debt. We find that some areas exhibited high growth in technical debt, while others remained comparably idle. This indicates that it is important to keep track of existing technical debt, but repayment should consider the distribution of each kind of technical debt in the codebase. Our studies are empirical, using mixed methods, analyzing quantitative as well as qualitative data.We used thematic coding to structure the qualitative data into themes, principles, and practices. We provide our systematically derived anatomy of the principles and practices of software craftsmanship and discuss how these relate to other principles within software engineering in general.

Embedded computer systems are all around us. We find them in everything, from dishwashers to cars and airplanes. They must always work correctly and moreover, often within certain time constraints. The software of such a system can be very large and complex, e.g. in the case of a car or a train. Hence, we develop the software for embedded systems in smaller, manageable, parts. These parts can be successively integrated, until they form the complete software for the embedded system, possibly at different levels. This phase of the development process is called the system integration phase and is one of the most critical phases in the development of embedded systems. In this phase, substantial effort is spent on testing activities. Studies have found that a considerable amount of test effort is wasteful due to people, unknowingly or by necessity, performing similar (or even overlapping) test activities. Consequently, test cases may end up to be similar, partially or wholly. We identified such test similarities in a case study of 2500 test cases, written in natural language, from four different projects in the embedded vehicular domain. Such information can be used for reducing effort when maintaining or automating similar test cases. In another case study in the same domain, we investigated several approaches for prioritizing test cases to automate with the objective to reduce manual test effort as quick as possible given that similar automated tests could be reused (similarity-based reuse). We analyzed how the automation order affects the test effort for four projects with a total of 3919 integration test cases, written in natural language. The results showed that similarity-based reuse of automated test case script code, and the best-performing automation order can reduce the expected manual test effort with 20 percentage points. Another way of reducing test effort is to reuse test artifacts from one level of integration to another, instead of duplicating them. We studied such reuse methods, that we denote vertical reuse, in a systematic mapping study. While the results from of our systematic mapping study showed the viability of vertical test reuse methods, our industrial case studies showed that keeping track of similarities and test overlaps is both possible and feasible for test effort reduction. We further conclude that the test case automation order affects the manual test execution effort when there exist similar steps that cannot be removed, but are possible to reuse with respect to test script code. / Inbyggda datorsystem finns överallt omkring oss idag; i allt från diskmaskiner till bilar och flygplan. Ofta finns det stränga krav på såväl korrekt funktion som svarstider. Eftersom programvaran i det inbyggda systemet i till exempel en bil är väldigt stor och komplex, utvecklar man programvaran i mindre delar som sedan successivt integreras till det färdiga datorsystemet. Denna del av utvecklingsprocessen kallas systemintegrationsfasen och är en av de största och mest kritiska faserna när man utvecklar inbyggda system. Integrationen kan utföras i ett antal nivåer med utförliga tester av mjukvaran på varje nivå. Detta innebär att det krävs ett avsevärt arbete för att testa mjukvaran. Om man kan minska detta arbete, givetvis utan att ge avkall på testningens kvalitet, förväntas det få en stor effekt på det totala utvecklingsarbetet. Studier har visat att en icke försumbar del av testarbetet är slöseri på grund av att människor, omedvetet eller av nödvändighet, utför likartade (eller till och med överlappande) testaktiviteter. En konsekvens är att testfall riskerar att bli helt eller delvis lika. Vi identifierade sådana likheter i en fallstudie med 2500 manuella testfall, skrivna på vanligt språk, från fyra projekt inom fordonsindustrin. Information om likheter och överlapp kan användas för att, till exempel, minska arbetsåtgången vid underhåll eller när man översätter testfall till kod så att de kan utföras automatiskt av en dator (automatisering). I en annan studie inom samma domän, undersökte vi flera metoder för att prioritera arbetsordningen vid automatisering av testfall där liknande testfall kunde återanvändas. I studien analyserade vi hur denna ordning påverkar arbetsmängden för fyra industriprojekt med totalt 3919 integrationstestfall skrivna på vanligt språk. Resultaten visar att den bästa ordningen kan minska testarbetet avsevärt. En förutsättning för detta är att redan översatta delar av testfall kan återanvändas för att slippa översätta liknande testfall igen. En annan väg för att minska testarbetet är att återanvända testfall och information mellan integrationsnivåer. Vi har kartlagt metoder och motiv kring sådan återanvändning i en systematisk mappningsstudie. Våra fallstudier visar vidare att det både är genomförbart och lönsamt att hålla reda på likheter i testfallen. Slutligen konstaterar vi att arbetsinsatsen för manuell testning påverkas av automationsordningen när det är möjligt att återanvända redan översatta delar av liknande testfall. / IMPRINT

A research report submitted to the Faculty of Engineering and The Built Environment of the University of Witwatersrand, Johannesburg In partial fulfilment of the requirements for the Degree of Master of Science in Engineering September 2015 / In recent years, software has become the cornerstone of banking and new business products are directly dependant on software. The delivery cycles for new features is now related to market share. This drive to use software as a vehicle for competitive advantage has created an environment in which software development of new business systems are increasingly on the critical path of many projects. An organisation’s portfolio of software intensive projects is situated within this complexity and organisations attempt to mitigate the risks associated with these complexities by implementing software development processes and practices. A key problem facing the modern bank is how to define and build a software development process that caters for both the traditional and increasingly agile genres of software development characteristics in a consistent and manageable way. The banks attempt to address this problem through continuous methodology and process improvements. Comparing and assessing non-standardised software engineering lifecycle models without a common framework is a complex and subjective task. A standardised language is important for simplifying the task for developing new methods and practices or for analysing and documenting existing practices. The Software Engineering Methods and Theory (SEMAT) initiative has developed a standardised kernel of essential concepts, together with a language that describes the essence of software engineering. This kernel, called the Essence, has recently become an Object Management Group (OMG) standard. The Essence kernel, together with its language, can be used as the underpinning theory to analyse an existing method and help provide insights that can drive method enhancements. The research report proposes a simple, actionable analysis framework to assist organisations to assess, review and develop their software engineering methods. The core concepts of the methodology are identified and mapped to the Essence concepts. The governance model of the Essence is mapped to the governance model of the industry model and a set of practices is identified and documented in the Essence language. The mapping and resulting analysis can be used to test the validity of the Essence theory in practice and identify areas for improvement in both the method and the Essence standard. The analysis framework has been applied to an operational software development lifecycle of a large South African bank. A mapping of the Essence concepts to the governance model and method documented in the lifecycle was completed. This mapping revealed that the Essence is a valid tool and can be used to describe a method in practice. Furthermore it is useful as an analysis framework to assess the governance model that manages and measures the progress of an endeavour in the Bank. The case study and resulting analysis demonstrate that the Essence standard can be used to analyse a methodology and identify areas for improvement. The analysis also identified areas for improvement in the Essence specification.

Verification is a process that checks whether a program G, implemented by a devel- oper, correctly complies with the corresponding requirement specifications. A verifier, whose interests may be different from the developer, will conduct such verification on G. However, as the developer and the verifier distrust each other probably, either of them may exhibit harmful behavior and take advantage of the verification. Generally, the developer hopes to protect the content privacy of the program, while the verifier wants to conduct effective verification to detect the possible errors. Therefore, a ques- tion inevitably arises: How to conduct an effective and efficient kind of verification, without breaking the security requirements of the two parties? We treat verification as a process akin to testing, i.e. verifying the design with test cases and checking the results. In order to make the verification more effective, we get rid of the limitations in traditional testing approaches, like black-box and white-box testing, and propose the “partial white-box verification”. Taking circuits as the description means, we regard the program as a circuit graph. Making the structure of the graph public, we manage to make the verification process in such a graph partially white-box. Via garbled circuits, commitment schemes and other techniques, the security requirements in such verification are guaranteed. / Thesis / Master of Science (MSc)