Omission of quality software development practices : a systematic literature review

Software deficiencies are minimized by utilizing recommended software development and quality assurance practices. However, these recommended practices (i.e., quality practices) become ineffective if software professionals purposefully ignore them. Conducting a systematic literature review (n = 4,838), we discovered that only a small number of previous studies, within software engineering and information systems literature, have investigated the omission of quality practices. These studies explain the omission of quality practices mainly as a result of organizational decisions and trade-offs made under resource constraints or market pressure. However, our study indicates that different aspects of this phenomenon deserve further research. In particular, future research must investigate the conditions triggering the omission of quality practices and the processes through which this phenomenon occurs. Especially, since software development is a human-centric phenomenon, the psychological and behavioral aspects of this process deserve in-depth empirical investigation. In addition, futures research must clarify the social, organizational, and economical consequences of ignoring quality practices. Gaining in-depth theoretically sound and empirically grounded understandings about different aspects of this phenomenon enables research and practice to suggest interventions to overcome this issue.fi=vertaisarvioitu|en=peerReviewed

IT-enabled change into the structures of health information systems in Africa: A case study in Kenya

Agile software development methods have emerged in recent years and have become increasingly popular since the start of the century. While much research claims to study agile methods, the meaning of agility itself in software development is yet to be fully understood. Agility is viewed by some as the antithesis of plan, structure discipline and bureaucracy. This study aims to develop a better understanding of agility, using the key concepts of Complex Adaptive Systems as a theoretical lens. The study explores agility from several different angles, including autonomous team, stability and uncertainty, and team learning. A multiple case study research method was employed. The findings of the study emphasize that agility is manifested as stability and discipline, which are just as desirable as flexibility, and context sharing is of the same value and importance as knowledge sharing. In addition, the collective nature of learning is underlined

Cost estimation in agile development projects

One of the key measures of the resilience of a project is its ability to reach completion on time and on budget, regardless of the turbulent and uncertain environment it may operate within. Cost estimation and tracking are therefore paramount when developing a system. Cost estimation has long been a difficult task in systems development, and although much research has focused on traditional methods, little is known about estimation in the agile method arena. This is ironic given that the reduction of cost and development time is the driving force behind the emergence of the agile method paradigm. This study investigates the applicability of current estimation techniques to more agile development approaches by focusing on four case studies of agile method use across different organisations. The study revealed that estimation inaccuracy was a less frequent occurrence for these companies. The frequency with which estimates are required on agile projects, typically at the beginning of each iteration, meant that the companies found estimation easier than when traditional approaches were used. The main estimation techniques used were expert knowledge and analogy to past projects. A number of recommendations can be drawn from the research: estimation models are not a necessary component of the process; fixed price budgets can prove beneficial for both developers and customers; and experience and past project data should be documented and used to aid the estimation of subsequent projects

Are Delayed Issues Harder to Resolve? Revisiting Cost-to-Fix of Defects throughout the Lifecycle

Many practitioners and academics believe in a delayed issue effect (DIE); i.e. the longer an issue lingers in the system, the more effort it requires to resolve. This belief is often used to justify major investments in new development processes that promise to retire more issues sooner. This paper tests for the delayed issue effect in 171 software projects conducted around the world in the period from 2006--2014. To the best of our knowledge, this is the largest study yet published on this effect. We found no evidence for the delayed issue effect; i.e. the effort to resolve issues in a later phase was not consistently or substantially greater than when issues were resolved soon after their introduction. This paper documents the above study and explores reasons for this mismatch between this common rule of thumb and empirical data. In summary, DIE is not some constant across all projects. Rather, DIE might be an historical relic that occurs intermittently only in certain kinds of projects. This is a significant result since it predicts that new development processes that promise to faster retire more issues will not have a guaranteed return on investment (depending on the context where applied), and that a long-held truth in software engineering should not be considered a global truism.Comment: 31 pages. Accepted with minor revisions to Journal of Empirical Software Engineering. Keywords: software economics, phase delay, cost to fi

Quality life cycle of object oriented software development in extreme programming

Thesis (Master)--Izmir Institute of Technology, Computer Engineering, Izmir, 2008Includes bibliographical references (leaves: 53)Text in English; Abstract: Turkish and Englishviii, 53 leavesAlthough there are many teams using Extreme Programming, many people still think that applying its values, principles and practices will cause catastrophic results.However extreme programming is not only compatible with today.s software standards, technologies and most importantly with the changes at every phase of software development but also improves the quality of software. In my thesis I analyze its values, principles, and practices and how they increase the quality comparing to old software development methodologies

Analyzing the concept of technical debt in the context of agile software development: A systematic literature review

Technical debt (TD) is a metaphor that is used to communicate the consequences of poor software development practices to non-technical stakeholders. In recent years, it has gained significant attention in agile software development (ASD). The purpose of this study is to analyze and synthesize the state of the art of TD, and its causes, consequences, and management strategies in the context of ASD. Using a systematic literature review (SLR), 38 primary studies, out of 346 studies, were identified and analyzed. We found five research areas of interest related to the literature of TD in ASD. Among those areas, managing TD in ASD received the highest attention, followed by architecture in ASD and its relationship with TD. In addition, eight categories regarding the causes and five categories regarding the consequences of incurring TD in ASD were identified. Focus on quick delivery and architectural and design issues were the most popular causes of incurring TD in ASD. Reduced productivity, system degradation and increased maintenance cost were identified as significant consequences of incurring TD in ASD. Additionally, we found 12 strategies for managing TD in the context of ASD, out of which refactoring and enhancing the visibility of TD were the most significant. The results of this study provide a structured synthesis of TD and its management in the context of ASD as well as potential research areas for further investigation

Best Practices for Implementing Agile Methods: A Guide for Department of Defense Software Developers

Traditional plan-driven software development has been widely used in the government because it\u27s considered to be less risky, more consistent, and structured. But there has been a shift from this approach to Agile methods which are more flexible, resulting in fast releases by working in an incremental fashion to adapt to the reality of the changing or unclear requirements. This report describes the Agile software development philosophy, methods, and best practices in launching software design projects using the Agile approach. It is targeted to Defense Department software developers because they face broad challenges in creating enterprise-wide information systems, where Agile methods could be used most effectively. Though not a panacea, agile methods offer a solution to an important class of problems faced by organizations today. Technology and E-Government

Recognizing and responding to bad smells in extreme programming

The agile software development process called Extreme Programming (XP) is a set of best practices which, when used, promises swifter delivery of quality software than one finds with more traditional methodologies. In this paper, we describe a large software development project that used a modified XP approach, identifying several unproductive practices that we detected over its two-year life that threatened the swifter project completion we had grown to expect. We have identified areas of trouble in the entire life cycle, including analysis, design, development, and testing. For each practice we identify, we discuss the solution we implemented to correct it and, more importantly, examine the early symptoms of those poor practices (“bad smells”) that project managers, analysts, and developers need to look out for in order to keep an XP project on its swifter track