DevOps and continuous practices are increasingly popular development practices aiming at bridging the gap between software development and IT operations with the indented outcome of shorter development life cycles while maintaining a high software quality. A fundamental part of many DevOps systems is a CI/CD (continuous integration/deployment) pipeline allowing for automatic building, testing and deployment of software. The use of continuous practices have been shown to achieve the desired outcomes, whereas the adopting of such practices has been attributed with the challenges of lacking expertise and skill as well as lacking available tools and technology. Execution of commands in a CI/CD pipeline are handled by a runner application, which can be configured in different ways allowing for different levels of the quality attributes performance, response time, throughput, robustness, stability, resource constraints, cost and maintainability. Five different types of runner infrastructure were implemented and evaluated on the quality attributes. These were: one single-machine implementation, one serverless implementation and three autoscaling implementations. For robustness and stability autoscaling implementations achieved the best results. Performance and throughput were affected by resource constraints which in turn affected the cost. Similar results were found for response time for all but one of the three autoscaling implementations, and for the serverless implementation. Finally, all implementations had similar results for reliability.

No description available.

No description available.

Context. Global software development (GSD) gained huge recognition in today’s business world. Most of the software companies day by day are striving hard to evolve globally where software is developed in the context of different environmental settings that are distanced on various factors like geography, timezone, culture and language. Coordination is the factor that plays one of the prominent roles in such a setting for effective teamwork and project success. Although numerous efforts has been done in this research area, there has been no proper evidence from industry about the impact of these coordination challenges on the overall quality of the software when being developed in a distributed setting. Objectives. The purpose of this study is to examine and identify the coordination challenges and risks faced in global software development projects that has a negative impact on the quality of software from practitioner’s perspective. It also identify the tools, methods, and techniques that are used in industry to overcome these challenges and maintain quality standards. Methods. The aims and objectives of our study are fulfilled by conducting survey among practitioners working in GSD projects all around the globe. Further, 10 interviews are conducted with practitioners working in different companies and geographical locations in order to gain a detailed understanding of the impact of identified coordination challenges on the quality of software in GSD projects. Results. A total of 50 survey responses are recorded, out of which 48 respondents specify that coordination challenges has a negative impact on software quality in GSD context. By the ratings given by the participants, we identified the challenges and risks that had a major impact. Mixed results are obtained during interviews where most of them prioritized coordination as a major problem in GSD projects. It also included that use of some tools, methods and processes help them in overcoming this issue. The quality attributes that are mostly affected due to the challenges in GSD projects are also identified. Conclusions. After the analysis of survey results, the coordination challenges and associated risks in GSD projects are identified. They were found to havemostly negative impact on software quality. After thematic analysis of interview results, we observed that though the impact of coordination challenges is negative, its extent of implication is moderate in most cases.

The goal of this thesis is to create a proposal of framework which can be used to support software quality management in a small development company. Framework is composed of processes, methodologies and tools which together should improve the quality of software products of a company. Concrete implementation of the framework is shown as a case study. Data for the case study were collected in the company Cleverbee, where the author worked during the case study's creation. Personal contribution of the author of the thesis is firstly the creation of the framework concept based on author's experiences and commented list of concrete results of framework's implementation. The detailed goal setting for this thesis and the definition of the target reader can be found in the chapter 1. Introduction. The definition of main terms, which will appear in the rest of the thesis, is contained in the chapter 2. Terms. Chapter 3. Software quality and its definition is explains the term "software quality" and the nature of the small companies. Chapter 4. Software quality management forms the theoretical foundation of the thesis. In this chapter you find how the methodologies RUP and CMMI view the software quality. Chapter 5. Framework concept contains the concept of the software quality management framework. Framework is based upon relevant sources and also author's personal experience. The chapter 6. Case study describes the concrete example of the implementation of the proposed framework. The case study also contains descriptions of the used software tools. The chapter 7. Conclusion contains the brief resume of the findings of the thesis.

by Ling Ho-Wan Howard, Ryoo Byung-Hoon. / Thesis (M.B.A.)--Chinese University of Hong Kong, 2003. / Includes bibliographical references (leaves 72-74). / ABSTRACT --- p.ii / TABLE OF CONTENTS --- p.iii / LIST OF ILLUSTRATIONS --- p.vi / LIST OF TABLES --- p.vii / PREFACE --- p.viii / Chapter / Chapter I. --- IT PROFILE OF HONG KONG --- p.1 / IT Penetration in2002 --- p.1 / Government Initiatives --- p.2 / Software Industry of Hong Kong --- p.2 / Chapter II. --- IT STRATEGY --- p.5 / IT Strategy - 3 Check Points --- p.5 / Flexible Platform --- p.5 / Strategy vs. ROI --- p.8 / Outsourcing or Internal Development --- p.9 / Quality Management System ´ؤ Instituting Best Practices --- p.10 / Deming's 14 Points --- p.11 / The Juran Trilogy --- p.12 / Crosby's 14 Quality Steps --- p.13 / Chapter III. --- SOFTWARE QUALITY MANAGEMENT - CMM --- p.16 / Software Development Project --- p.16 / Software Project Process Model --- p.17 / Software Quality Management --- p.19 / Capability Maturity Model (CMM) --- p.20 / Bootstrap 3.2 --- p.23 / Trillium --- p.25 / ISO 9001/TickIT --- p.26 / SPICE --- p.27 / Chapter IV. --- CMM PRACTICES IN THE WORLD --- p.29 / The CMM Practices - Worldwide --- p.29 / Two studies on Software Process Management in Taiwan --- p.32 / Software Process Management in Taiwan: A Longitudinal Study of Top 1000 Companies --- p.32 / Software Project Process Management Maturity and Project Performance --- p.34 / Chapter V. --- SOFTWARE PROCESS MANAGEMENT IN HONG KONG --- p.36 / The CMM in Hong Kong --- p.37 / Case Studies on the SPM in Hong Kong --- p.41 / Case 1: Dow Chemical --- p.41 / Case 2: Oracle Hong Kong --- p.44 / Case 3: Bentley Systems Inc. (Hong Kong) --- p.48 / Case 4: i-Cable --- p.50 / Case 5: SinoPac Securities (Asia) Ltd --- p.53 / Implications of the Statistics --- p.55 / Factor comparison of mean value --- p.56 / Implications --- p.58 / Chapter VI. --- CONCLUSION --- p.60 / APPENDIX --- p.62 / BIBLOGRAPHY --- p.72

The advent of agile methodologies has brought about an illuminating debate in Software Engineering, particularly with regard to software quality. Some studies have reported that agile methodologies do improve software quality when compared to traditional methodologies; other studies have been inconclusive or contradictory, while others have argued that empirical evidence is limited. This study sought to investigate the correlation between agile methodologies when compared to traditional methodologies for selected software quality parameters. The research design was causal comparative, as well as correlational. The approach was quantitative, using a survey as the data collection method. SPSS was used to conduct descriptive and correlational analysis for 106 responses received. The main findings were that there was a statistically significant relation between traditional methodology use and ease of system testing (p=0.014); a statistically significant relation between traditional methodology use and timeliness (p=0.02); a statistically significant relation between software quality standards used and ease of system testing (p=0.017); a statistically significant relation between active stakeholder participation on projects and ease of system interactivity (p=0.047); and a statistically significant relation between mandatory workshop interactivity (p=0.047); and a statistically significant relation between mandatory workshop attendance or training and ease of system navigation (p=0.031).Claims that agile methodology use leads to improved software quality for selected quality parameters could not be empirically validated. The association between most of the selected software quality criteria in relation to methodology use in general was not apparent. Agile methodologies are suitable in small environments. Scrum was the most widely used agile methodology by far. The popularity and adoption state of XP showed a significantly decreasing trend. Traditional and agile methodologies combined are being used (47%) more than any other methodology. Agile methodology use (28%) surpassed traditional methodology use (19%). A suitable consensus definition for agile methodologies did not emerge from the data collected. The most suitable project life cycle model was evolutionary, incremental and iterative. ‘Other’ methodologies, meaning customised agile or SDLC, are suitable, as the environment becomes increasingly large and complex. Only 13% of organisations surveyed have an agile experience of six years and beyond. Based on these findings and gaps in the literature, implications and recommendations for further research areas are proposed, where the findings and contributions of this study are found to be relevant to practice for application and to academia for further research / College of Engineering, Science and Technology / M. Sc. (Computing)

Requirements Engineering and Software Quality Management is nowadays considered to be one of the important parts of the software development process. This thesis deals with connecting the theoretical concept of requirements engineering and usage of functions offered by Enterprise Architect tool, which should support the requirements engineering and software quality management processes. The main goal is to propose procedures of Enterprise Architect usage during the project in such a way, which will help to raise quality of the final product. The purpose is to offer a systematic and conscious way of implementation Enterprise Architect elements into software development processes, because this tool is able to support the whole cycle of the product. The methodology was designed as a result of theoretical concept, existing requirements engineering approaches and my own experience acquired during working on projects as a business and test analyst. The contribution of the designed methodology is in bringing recommendations, practices and procedures saying how to use Enterprise Architect during the software development process in order to gain the highest possible software quality. The thesis is structured in four sections describing the appropriate theory, analyzed requirement engineering approaches, critical mistakes during this process and the methodology design.

Context: There is an overwhelming prevalence of companies developing software in global software development (GSD) contexts. The existing body of knowledge, however, falls short of providing comprehensive empirical evidence on the implication of GSD contexts on software quality for evolving software systems. Therefore there is limited evidence to support practitioners that need to make informed decisions about ongoing or future GSD projects. Objective: This thesis work seeks to explore changes in quality, as well as to gather confounding factors that influence quality, for software systems that evolve in GSD contexts. Method: The research work in this thesis includes empirical work that was performed through exploratory case studies. This involved analysis of quantitative data consisting of defects as an indicator for quality, and measures that capture software evolution, and qualitative data from company documentations, interviews, focus group meetings, and questionnaires. An extensive literature review was also performed to gather information that was used to support the empirical investigations. Results: Offshoring software development work, to a location that has employees with limited or no prior experience with the software product, as observed in software transfers, can have a negative impact on quality. Engaging in long periods of distributed development with an offshore site and eventually handing over all responsibilities to the offshore site can be an alternative to software transfers. This approach can alleviate a negative effect on quality. Finally, the studies highlight the importance of taking into account the GSD context when investigating quality for software that is developed in globally distributed environments. This helps with making valid inferences about the development settings in GSD projects in relation to quality. Conclusion: The empirical work presented in this thesis can be useful input for practitioners that are planning to develop software in globally distributed environments. For example, the insights on confounding factors or mitigation practices that are linked to quality in the empirical studies can be used as input to support decision-making processes when planning similar GSD projects. Consequently, lessons learned from the empirical investigations were used to formulate a method, GSD-QuID, for investigating quality using defects for evolving systems. The method is expected to help researchers avoid making incorrect inferences about the implications of GSD contexts on quality for evolving software systems, when using defects as a quality indicator. This in turn will benefit practitioners that need the information to make informed decisions for software that is developed in similar circumstances.

Aspect-Oriented Software Development (AOSD) is a new approach that addresses limitations inherent in conventional programming, especially the principle of separation of concerns by emphasizing the encapsulation and modularization of crosscutting concerns through a new abstraction, the "aspect." Aspect-oriented programming is an emerging AOSD programming paradigm that focuses on the modularization of concerns as appropriate for the host language and providing a mechanism for describing concerns that crosscut each other by congealing into a single textual structure behavior that conventional programming would otherwise distribute throughout the code. AspectJ is the most widely used aspect-oriented programming language to date and provides an extension of the Java language that includes several new concepts and constructs that differ from those in procedural and object-oriented programs. These include join points, pointcuts, advice, inter-type declarations, introduction and aspects. In AspectJ, as well as other aspect-oriented programming languages, "aspects" package pointcuts and advice into functional units in much the same way that object-oriented programming uses classes to package fields and methods into cohesive units but they offer a unique set of problems. Software inspections are considered a software engineering "best practice" for ensuring quality, but the introduction of new aspect-oriented programming language mechanisms drives the need for them to be tailored in a similar manner to how they were tailored to support object-oriented programs and the procedural programs. The identification of faults unique to aspect-oriented programming allowed for the design of an aspect fault model and the associated software inspection checklists criteria that provide a description of the typical faults associated with aspects and the clues that aid in betraying their presence. The proposed methodology for this research entailed a mixed methods approach based on a combination of descriptive and exploratory research methodologies using a normative case study. The proposed methodology resulted in the development of an understanding of the AspectJ primitive pointcut construct, identification of the typical faults associated with this construct and the subsequent development of a fault model, a set of programming rules and tailored software inspection checklist. A case study was conducted comparing defects detected by an inspection checklist tailored for AspectJ with one that was not tailored. The results of the case study demonstrated using software inspection checklists not tailored would result in many faults unique to aspect-oriented programming going undetected.