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]

The practices of lean and agile methods are important to manage and guide projects development in different situations. However, selecting the appropriate practices of lean and agile methods is a daunting task, owing to the availability of hundreds of practices. This wide variety of available practices bewilders potential users, in terms of the best practices that may yield satisfactory solution when applied to the project development. Lean and agile practices selection model is necessary to guide both academic and industrial experts to choose the appropriate practices for a specific project development. Thus, this study aimed to develop lean and agile practices selection (LAPS) model that presents a clear picture of how developers can use LAPS model to select and adopt different practices from various lean and agile methods. Qualitative research method (e.g., grounded theory) was used to interview 18 software developers across 13 countries. The validated qualitative analysis results showed that the proposed LAPS model consists of two main components, which are (1) lean and agile practices that include 41 best practices related to lean and agile methods and (2) factors that affect the process of lean and agile practices selection including five main factors and 17 subfactors associated with the five main factors. The two case studies conducted assured the validity and applicability of the lean and agile practices selection model. [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.)

Purpose: This discourse aims to examine the categorisation of Project Management Software (PMS) with focused attention on those devised and integrated within the framework of Agile methodologies. The discourse highlights the functionalities of PMS that are most beneficial in Agile projects. It provides an overview of the underlying motives for their adoption and the potential advantages they can offer to project teams, Agile Project Managers, and their stakeholders. Design/methodology/approach: A comparative analysis of existing tools supporting project management based on an agile approach was applied. Existing software features were analysed to identify similarities and differences, mainly in basic software functionality. Findings: Effective communication within the project team through IT tools can be a basis for building a competitive advantage in the market. It increases the quality of project outputs through continuous monitoring of project implementation and quick interaction to improve the efficiency of project work. Research limitations/implications: The number of existing tools and improvements to existing IT tools make it necessary to analyse the IT market situation cyclically. Practical implications: The present article endeavours to serve as a comprehensive overview that draws upon relevant literature and existing market offerings of PMS to illustrate the discussed functionalities. The article is aimed both at practitioners deciding on the right tool and at software developers bringing newer versions of tools to market. Social implications: The results of the comparative analysis have an indirect social impact. The agile approach relies heavily on continuous and direct communication between project stakeholders. The study results can help project teams choose the best tool to support project communication. Originality/value: The literature search indicated a research gap in the comprehensive analysis of existing IT tools currently used in business practice. [ABSTRACT FROM AUTHOR]

Nigeria is ranked second worldwide, after India, in reported incidences of cyberattacks. Attackers usually exploit vulnerabilities in software which may not have adequately considered security features during the development process. Agile methods have the potential to increase productivity and ensure faster delivery of software, although they tend to neglect non‐functional requirements such as security. The implementation of government policies, such as the Nigeria Data Protection Regulation (NDPR) Act 2019, impacts the security activities carried out by agile teams. Despite its significance, there is a paucity of research on security issues especially in the Agile Software Development (ASD) domain. To address this gap, a grounded theory study was conducted with 15 agile software practitioners in Nigeria. Based on our analysis of the interview transcripts, we developed a grounded theory of the security challenges confronting agile practitioners. The four challenges identified were (a) a lack of collaboration between security and agile teams; (b) the tendency to use foreign software hosting companies; (c) a poor cybersecurity culture; and (d) the high cost of building secure agile software. We used these challenges to identify gaps within the existing secure ASD and found a lack of indigenous software hosting companies in Nigeria. Our study also revealed tensions between the Nigerian regulatory environment and agile software developers' compliance. While practitioners acknowledged the government's efforts, there were concerns about the practicality of implementing such legislation. We recommend government action to increase awareness of local software hosting companies' capabilities, and closer collaboration between agile and security teams. Thus, the novel contribution of this article is the development of the policy adherence challenges (PAC) model. [ABSTRACT FROM AUTHOR]

Prior work on leadership in information systems development (ISD) teams has assumed that all developers are treated equally by their team leader and ignored the possibility that differentiated leader-member exchange (LMX) may be an important instrument for team leaders to influence self-organizing, agile ISD teams. We conducted a concurrent mixed methods inquiry to understand how LMX differentiation is associated with developer satisfaction in agile ISD teams and through which team processes agile ISD teams address LMX differentiation. We ran a multilevel, multistage survey of 1,894 software developers in 217 teams and an embedded case study of five ISD teams drawing on qualitative data from 40 interviews of developers and team leaders. Two focus groups (one with 10 developers and one with 10 team leaders) helped to substantiate the meta-inferences from the quantitative and qualitative studies. The results showed that LMX differentiation was positively associated with developer satisfaction, especially in teams with high-quality team-member exchange (TMX). We identify three team processes (i.e., collectivization of resources, visible appreciation of privileges, and freeing up leader capacities) that are enacted through agile ISD practices and allow ISD teams to leverage benefits from LMX differentiation for all their members. [ABSTRACT FROM AUTHOR]

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: Traditional software teams that implement agile methodologies frequently experience difficulty working efficiently as agile teams. While agile methodologies support and promote social activities and behaviors, the understanding of the social phenomena and challenges that arise during the transformation of traditional teams into agile teams is limited. We conducted an extensive 10‐month case study in a software enterprise to analyze the changes in the communication and social interactions of employees during the transformation process, and to delineate the social challenges that arise during this process. Using social interaction registers, we collected data on the communication and social interactions of employees, first when they worked as a traditional team and then as an agile team. Then, we processed the data using social network analysis methods to identify the differences between these 2 types of teams and to create graphs of communication and social interaction networks. We identified that the transformation process influences formal, informal, oral, and written communication and increases conjunctive and disjunctive social interactions. Further, from the results of interviews conducted with all the enterprise members, we identified 5 social challenges to transforming a traditional team into an agile one. The results of this research suggest that the transformation process requires broad changes in the relationships and interactions among employees. [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]

Agile methods in general and the Scrum method in particular are gaining more and more trust from the software developer community. When it comes to writing a functional requirement, user stories become more and more usable by the community. Furthermore, a considerable effort has already been made by the community in relation to the use of the use case tool when drafting requirements and in terms of model transformation. We have reached a certain stage of maturity at this level. The idea of our paper is to profit from these richness and to invest it in the drafting of user stories. In this paper, we propose a process of transforming user stories into use cases and we will be able to benefit from all the work done in the transformation of the models according to the MDA approach. To do this, we used natural language processing (NLP) techniques, by applying TreeTagger parser. Our work was validated by a case study where we were able to obtain very positive precisions between 87% and 98%. [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]

The lack of user engagement, the absence of user feedback, incomplete and continuously changing user requirements are among the critical concerns that cause projects to fail. User-centered design (UCD) and agile software development are two iterative approaches that have been proposed to overcome such concerns. UCD is a design process focusing on user research, user interface design and usability evaluation. Introduced by software engineering practitioners, agile refers to a number of iterative and incremental software development practices that emphasize people's needs, communication between developers and stakeholders and the ability to adapt to change. In both the agile and UCD communities, however, a full understanding of user requirements is often seen as incompatible with early and quick development iterations. We performed a literature review aiming to identify how agile teams have integrated UCD tools into their agile software development process to a better understanding of the user requirements without losing sight of the agile values and principles. UCD tools adaptations and minimal-up-front design applied in agile development are among the approaches discovered in this study. The findings could lead to a comprehensive user-centric software engineering that will overcome inherent problems faced by agile teams to understand user needs, priorities and goals. [ABSTRACT FROM AUTHOR]

Agile methods are gaining widespread use in industry. Although management is keen on adopting agile, not all developers exhibit preference for agile methods. The literature is sparse in regard to why developers may show preference for agile. Understanding the factors informing the preference for agile can lead to more effective formation of teams, better training approaches, and optimizing software development efforts by focusing on key desirable components of agile. This study, using a grounded theory methodology, finds a variety of categories of factors that influence software developer preference for agile methods including self-efficacy, affective response, interpersonal response, external contingencies, and personality contingencies. Each of these categories contains multiple dimensions. Preference rationalization for agile methods is the core category that emerges from the data. It informs that while the very essence of agile methods overwhelmingly and positively resonates with software developers, the preference is contingent on external and personality factors as well. [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]

The demand for quick delivery of quality software is becoming high among software clients due to the fast changing technology in the dynamic world. Agile software development meets this demand and has gained appropriate and wide acceptance among software practitioners. However, the quality of such software is greatly impacted by its maintainability. Unfortunately, existing works focused only on the flexibility aspect of maintainability without paying attention to timely delivery. In this work, maintainability as a function of time to correct codes was examined among various categories of software developers. Deliberate errors, ranging from two to nine, were introduced into sets of agile codes written in python programming language and given to 100 programmers, each in the groups of individual junior, individual expert, random, expert pairs, junior pairs and junior expert pairs. The results revealed that random pair programmers spent the highest time of 21.88 min/bug on the average, while individual experts spent the least time of 16.26 min/bug. [ABSTRACT FROM AUTHOR]

Software process standards (e.g. ISO/IEC 12207, ISO/IEC 15504) and models (e.g. CMMI) provide a set of best practices and guidelines for improving the quality of the software process and products resulting from that process. However, they do not prescribe a particular software development methodology (i.e. RUP, MSF), and thus software development teams face a compliance problem between the selected development methodology and a pursued particular standard or model. In this research, the particular issue of compliance of Agile Software Development Methodologies (SCRUM, XP, and UPEDU) and the new ISO/IEC 29110 standard is studied. Because the new standard is focused on the software process in very small software development companies or small software project teams in the range from 1 to 25 people, and the Agile Software Development Methodologies (ASDMs) are primarily for same targets, this study is important. The ISO/IEC 29110 standard contains two processes: Project Management and Software Implementation. This study is focused on the first process. The main findings indicate that the UPEDU and SCRUM methodologies present and high compliance level with the ISO/IEC 29110 Project Management process, while XP has a moderate level. Thus, software developer teams interested in achieving compliance with the ISO/IEC 29110 Project Management process can count with two ASDMs. However, a full compliance study (with both Project Management and Software Implementation) is still missing. [ABSTRACT FROM AUTHOR]

Software development teams in large scale offshore enterprise development programmes are often under intense pressure to deliver high quality software within challenging time contraints. Project failures can attract adverse publicity and damage corporate reputations. Agile methods have been advocated to reduce project risks, improving both productivity and product quality. This article uses practitioner descriptions of agile method tailoring to explore large scale offshore enterprise development programmes with a focus on product owner role tailoring, where the product owner identifies and prioritises customer requirements. In globalised projects, the product owner must reconcile competing business interests, whilst generating and then prioritising large numbers of requirements for numerous development teams. The study comprises eight international companies, based in London, Bangalore and Delhi. Interviews with 46 practitioners were conducted between February 2010 and May 2012. Grounded theory was used to identify that product owners form into teams. The main contribution of this research is to describe the nine product owner team functions identified: groom, prioritiser, release master, technical architect, governor, communicator, traveller, intermediary and risk assessor. These product owner functions arbitrate between conflicting customer requirements, approve release schedules, disseminate architectural design decisions, provide technical governance and propogate information across teams. The functions identified in this research are mapped to a scrum of scrums process, and a taxonomy of the functions shows how focusing on either decision-making or information dissemination in each helps to tailor agile methods to large scale offshore enterprise development programmes. [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]

The article discusses research on identifying agile methods and practices, along with ranking them and their usage trends, and mentions that adoption of agile methods and practices as a complex process that needs to be customisable for a particular organization or a team.