Search

A system that will have major and dire repercussions in the event of a failure or malfunction is considered a critical system. Therefore, Software developers usually apply strict standards, testing, and regulatory compliance while developing, operating, and maintaining critical systems to ensure their reliability, security, and resilience due to the high risks involved. Software developers and large organizations try to apply the best methodologies to develop critical systems. The PMBOK framework and Agile methodologies have gained wide acceptance by software developers. These frameworks became more popular because they applied best practices and made them suitable for working in the management of critical systems development processes. The main objective of the research is to review the characteristics associated with the failure of critical systems and analyze how to reduce the failure of critical systems through the use of appropriate software development frameworks. This is done through a literature review, where published studies and research on the failure of critical systems and their critical characteristics will be reviewed. Along with emphasizing Agile Software Development Methods (ASDM) like Scrum, LeSS, and SAFe, this analysis also contrasts them with PMBOK’s best project management practices and recommendations. [ABSTRACT FROM AUTHOR]

One of the main obstacles in software development projects is requirement volatility (RV), which is defined as uncertainty or changes in software requirements during the development process. Therefore, this research tries to understand the underlying factors behind the RV and the best practices to reduce it. The methodology used for this research is based upon qualitative research using interviews with 12 participants with experience in agile software development projects. The participants hailed from Austria, Nigeria, the USA, the Philippines, Armenia, Sri Lanka, Germany, Egypt, Canada, and Turkey and held roles such as project managers, software developers, Scrum Masters, testers, business analysts, and product owners. Our findings based on our empirical data revealed six primary factors that cause RV and three main agile practices that help to mitigate it. Theoretically, this study contributes to the body of knowledge relating to RV management. Practically, this research is expected to aid software development teams in comprehending the reasons behind RV and the best practices to effectively minimize it. [ABSTRACT FROM AUTHOR]

Copyright of Investigación e Innovación en Ingenierías is the property of Universidad Simon Bolivar and its content may not be copied or emailed to multiple sites or posted to a listserv without the copyright holder's express written permission. However, users may print, download, or email articles for individual use. This abstract may be abridged. No warranty is given about the accuracy of the copy. Users should refer to the original published version of the material for the full abstract. (Copyright applies to all Abstracts.)

The competition in the software market demands that the time required for any software product to reach the market be reduced if the product is to survive competition from other developers. The pursuit of this goal has led to the adoption of agile software development methodologies. While other agile methodologies provide guidelines as to the software engineering (SE) practices to be used during the development lifecycle, Scrum does not. The purpose of this study is twofold: first, to identify the usage and level of importance of software engineering practices in the Scrum development environment; and second, to investigate how Scrum teams adopt an appropriate set of SE techniques and whether a hybrid Scrum/Extreme Programming (XP) methodology is an appropriate approach to take. This research was conducted by examining sample data from five organizations using the Scrum methodology. The sample included a range of industries including communications and embedded systems, financial asset management, software development houses and consulting firms in South Africa. The study employed a mixed method approach. A key finding was that, regardless of the fact that Scrum does not explicitly recommend engineering practices, there was extensive use of these practices by all of the participating organizations. The study also found that the lack of software engineering practices in Scrum does not constitute a barrier to a successful adoption of Scrum, provided the 'inspect and adapt' principle inherent in Scrum is properly followed. The study discusses the findings, explains the implications and suggests future research. [ABSTRACT FROM AUTHOR]

Continuous integration is an agile software development practice. Instead of integrating features right before a release, they are constantly being integrated into an automated build process. This shortens the release cycle, improves software quality, and reduces time to market. However, the whole process will come to a halt when a commit breaks the build, which can happen for several reasons, e.g., compilation errors or test failures, and fixing the build suddenly becomes a top priority. Developers not only have to find the cause of the build break and fix it, but they have to be quick in all of it to avoid a delay for others. Unfortunately, these steps require deep knowledge and are often time-consuming. To support developers in fixing a build break, we propose Bart, a tool that summarizes the reasons for Maven build failures and suggests possible solutions found on the internet. We will show in a case study with 17 participants that developers find Bart useful to understand build breaks and that using Bart substantially reduces the time to fix a build break, on average by 37%. We have also conducted a qualitative study to better understand the workflows and information needs when fixing builds. We found that typical workflows differ substantially between various error categories, and that several uncommon build errors are both very hard to investigate and to fix. These findings will be useful to inform future research in this area. [ABSTRACT FROM AUTHOR]

Frustration in software development is defined as an obstacle in the persuasion of an expected and defined goal. It was observed specifically, when working on agile methodology in which changes are welcomed on every step and customer demand has the highest priority. The purpose of conducting this research is to highlight the frustration identified in software developers at different levels and from different industries. For this purpose, the approach that has been followed is comprehending response from the industry against the major limitation of extreme programming model based on agile methodology. Methodology consists of a survey paper, 150 software developers have filled the survey paper and the results are analyzed by using Correlation analysis and Regression analysis. The questionnaire have divided in the scheme category due to which a developer can frustrate. This calculate the impact of each frustration factor to other. The result shows that working in Extreme Programming Agile Methodology develops frustration among the developer. The variables are significant and moderate to each other. [ABSTRACT FROM AUTHOR]

Abstract: This article addresses the relationships between agile development and entrepreneurship. The objective of the study is to verify that the adoption of agile practices can promote entrepreneurial skills in software developers. In this study, agile practices were related to entrepreneurial skills, and developers of the software industry and academia professors were invited to contribute. Questionnaires were sent to the participants to obtain their opinion regarding this research. Participants also opined about the possibility of entrepreneurial skills being an observable behavior in agile culture, ie, if they are visible artifacts of agile culture. As a result, the study found a set of agile practices that promote entrepreneurial skills in software developers. That is, it was found that agile practices promote entrepreneurial behavior in these professionals. These entrepreneurial skills are sustained by the same basic values and assumptions that were learned by developers to resolve internal integration and external adaptation issues during the adoption of agile practices. In this article, an integration model has been adapted from other areas, thereby opening a new field of study involving the relationships between academic research and professional practice on entrepreneurship in the software area and agile development. [ABSTRACT FROM AUTHOR]

A known problem in large software companies is to balance the prioritization of short-term and long-term business goals. As an example, architecture suboptimality (Architectural Technical Debt), incurred to deliver fast, might hinder future feature development. However, some technical debt generates more interest to be paid than other. We conducted a multi-phase, multiple-case embedded case study comprehending 9 sites at 6 large international software companies. We have investigated which architectural technical debt items generate more interest , how the interest occurs during software development and which costly extra-activities are triggered as a result. We presented a taxonomy of the most dangerous items identified during the qualitative investigation and a model of their effects that can be used for prioritization, for further investigation and as a quality model for extracting more precise and context-specific metrics. We found that some architectural technical debt items are contagious, causing the interest to be not only fixed, but potentially compound, which leads to the hidden growth of interest (possibly exponential). We found important factors to be monitored to refactor the debt before it becomes too costly. Instances of these phenomena need to be identified and stopped before the development reaches a crises. [ABSTRACT FROM AUTHOR]

In this article, we report from a case study of an agile software development organization and we study in particular the developers' and product managers' attitudes towards integrating usability work into software development. We offer explanations based on system justification theory illuminating what would-be integrators might be up against. The analysis shows how the developers only pay lip service to usability work and how they treat users superficially. It further shows how that leads to stereotyping of usability designers and users in order to preserve status quo, and how internalization of inequality between the developers and usability designers rationalizes the preservation of status quo. These findings will have significant implications for managers of software development. [ABSTRACT FROM AUTHOR]

Agile methods have different practices that ultimately foster intra-team knowledge sharing (KS). However, they do not provide recommendations about coping with inter-team KS. Supporting inter-team KS is fundamental in scaling agility across the entire organization, and is regarded as the new horizon for agile software development. This study seeks to understand inter-team knowledge sharing effectiveness in agile software development organizations. Using grounded theory, we analyzed data from four Brazilian organizations and also from an expert in agile methods implementation. We observed that the companies employ different work practices that allow knowledge sharing to occur across team boundaries. Our main contribution is a conceptual model that explains how effective knowledge sharing across agile teams depends on applying purposeful practices, along with organizational conditions and stimuli. This understanding represents an innovative focus within the context of agile methods and suggests what one needs to take into account when striving on this path. Yet, it yields opportunities for further studies in refining and extending the model to other organizational contexts. Inter-team knowledge sharing reflects the way agile software development organizations are coping with enterprise agility and the way they consider knowledge as a resource for competitiveness. [ABSTRACT FROM AUTHOR]

SUMMARY Non-safety critical software developers have been reaping the benefits of adopting agile practices for a number of years. However, developers of safety critical software often have concerns about adopting agile practices. Through performing a literature review, this research has identified the perceived barriers to following agile practices when developing medical device software. A questionnaire-based survey was also conducted with medical device software developers in Ireland to determine the barriers to adopting agile practices. The survey revealed that half of the respondents develop software in accordance with a plan-driven software development lifecycle and that they believe that there are a number of perceived barriers to adopting agile practices when developing regulatory compliant software such as being contradictory to regulatory requirements, insufficient coverage of risk management activities and the lack of up-front planning. In addition, a comparison is performed between the perceived and actual barriers. Based upon the findings of the literature review and survey, it emerged that no external barriers exist to adopting agile practices when developing medical device software and the barriers that do exists are internal barriers such as getting stakeholder buy in. Copyright © 2013 John Wiley & Sons, Ltd. [ABSTRACT FROM AUTHOR]

The article discusses a study which investigated a mature Scrum team in a large organization and their interactions with the User Experience (UX) designers working on the same project. Particular focus is given to the difference between agile development and UX design methods for software development. Results of the study showed that ongoing articulation work by developers have led to cooperation between Agile developers and UX designers. Findings also revealed the themes which centre around the types of activities allowing the transformation of paper-based UX designs into working software.

We conducted a quasi-experiment comparing novice pair programmers to expert pair programmers. The expert pairs wrote tests with a higher instruction, line, and method coverage than the novice pairs and changed the given program skeleton to a larger extent. However, the expert pairs were also slower than the novice pairs. The pairs within both groups switched keyboard and mouse possession frequently. Furthermore, most pairs did not share the input devices equally but rather had one partner who is more active than the other. [ABSTRACT FROM AUTHOR]

The authors comment on the condition of the agile system development research. They cite the growing popularity of agile system development methods in handling rapid changes of the environment, as well as its dedication to several journal issues, conferences, and workshops are cited. However, they point out that research has been lagged behind practice and stresses the need for developers to understand its methods and to improve the level of its research.

The article discusses the foundations of adapting agile development methodologies in software development. It explores the growing popularity of Extreme Programming due to its focus on managing time to market constraints, however, the method needs to be adapted to suit the needs of different contexts. It examines the use of adaptive structuration theory to analyze data from multisite case study and describes several sources of structure that affects the appropriation of agile practices.

The article discusses the proposed Method for Method Configuration (MMC) in tailoring information systems development. It explores how the method has been used during the development of three software projects to manage method tailoring and to promote agile goals and values. It explores the content examples of the method configurations which determine the significance of MMC and its conceptual framework on eXtreme Programming.

This article introduces a methodology for developing applications incorporating components of Agile development methods with the traditional software development life cycle (SDLC), a.k.a. the ''waterfall'' model of software development. We look at the causes for failure of software development projects and propose steps in the development process to address many of the root causes of these failures (it would be implausible to state that any development methodology could eliminate the risk of failure). We also provide a critical review of Agile principles and the traditional SDLC. The steps of the new methodology are then described with rationalization for their necessity. [ABSTRACT FROM AUTHOR]

Press releases, scientific publications and anecdotal evidence demonstrate that organisations worldwide are adopting agile software development methods at increasing speed. Little is still known about the current usefulness of agile methods in the complex environment of the embedded software development industry. Embedded devices are already commonplace in regular households. The goal of this survey is to provide first-hand knowledge of the adoption and experience of two of the most known agile methods, namely Extreme Programming and Scrum, in a number of European organisations of embedded software known to be interested and active in experimenting with agile software development methods. The survey involved 13 industrial organisations in eight European countries and 35 individual software development projects. The focus of the questionnaire was to enquire into the level of use as well as the experienced usefulness – or expected usefulness if there was no experience available – of the two agile methods and their individual practices. The results show that the embedded industry has been able to apply agile methods in its development processes. The results also indicate that the appreciation of the agile methods and their individual practices appears to increase once adopted and applied in practice. [ABSTRACT FROM AUTHOR]

The article examines an empirical study which focuses on the requirements engineering (RE) practices employed by agile software developers and the benefits and challenges posed by these practices. It discusses an analysis of data from 16 software development organizations which reveals seven agile RE methodologies. The study has two phases including the carrying of case studies in 10 organizations involved in high-speed software development and the taking of data from six organizations which used Extreme Programming and Scrum. The study analyzes the difference between agile RE and traditional RE and suggests that the intensive communication between the developers and customers is the most important RE practice.

Agile software development of short iterative cycles offers an opportunity for rapid, visible and motivating software process improvement (SPI). The agile principles suggest the regular reflections of agile project teams for improving the efficiency and adaptation of the process. However, current literature provides little support or empirical evidence for conducting such improvement efficiently, systematically and in a validated manner. Thus, this article proposes an Iterative Improvement Process for conducting SPI within individual agile project teams, which aims at increasing the ability of software developers to improve the development process based on their experiences and context knowledge. The approach has been trialed within a multiple case study of five consecutive case projects where both qualitative and quantitative research data has been systematically collected. The empirical data confirms the positive effects of the Iterative Improvement Process on the software development projects and reveals the willingness of software developers to participate in the Iterative Improvement activities due to the rapid and visible changes in their working practices. Copyright © 2006 John Wiley & Sons, Ltd. [ABSTRACT FROM AUTHOR]

The article focuses on the reasons why software developers are not following agile or formal methods as traditionally conceptualized. It cites the challenges faced by organizations in switching to a purely formal approach and a purely agile one. It mentions the increasing demand for the so-called agile tools to meet the needs of top management. According to emerging empirical evidence, most agile teams utilize some upfront design while most formal methods are iterative.