Search

Enterprise architecture is a growing trend that aims to help deal with the complexity of socio‐technical systems such as human organizations, as well as their information technology and systems areas. Nevertheless, the contribution of enterprise architecture to the field of software engineering remains unclear. The purpose of this systematic literature review is to see how enterprise architecture is used in software development and maintenance practice. To this end, we first carried out a search in the SCOPUS database and then organized the papers according to the Software Engineering Body of Knowledge to determine what areas of software engineering are covered by each research study. To understand how enterprise architecture is used, we established a classification based on ISO 42010 and TOGAF. From the systematic literature review, we noticed that the early stages of development are the most impacted by the enterprise architecture. On the other hand, we observed that enterprise architecture is of assistance in the areas of engineering management, engineering processes, and engineering models and methods; these tasks are carried out by teams or managers using different, often agile, development methods or standards. In turn, we found that the most common categories are architecture descriptions; these are often used to facilitate communication and information‐sharing between different stakeholders, in addition to frameworks, which will help to establish common practices in the organization related to the joint use of enterprise architecture and software development. [ABSTRACT FROM AUTHOR]

Summary: The importance of the team, its internal dynamics, and its performance are widely recognized within the software engineering community. While popular frameworks identify wholeness, stability over time, and smallness as important factors, they offer little guidance on how to form teams that achieve these three characteristics. The objective of this study is to investigate how these team characteristics interact in large‐scale software development contexts, particularly focusing on the impact of stable and dynamic teaming approaches. This was done through a multivocal study of literature, followed by individual semi‐structured interviews with 19 engineers from two companies and validation workshops with an additional two companies from unrelated industry segments. The study results show that the question of stable versus dynamic approaches to forming software engineering teams is largely unaddressed in industry, with stable teams representing a habitual default option. Meanwhile, both stable and dynamic teams clearly have respective strengths and weaknesses, calling for careful consideration of the most suitable approach in any given situation. To support such consideration, this paper presents a model of how team stability, wholeness, and smallness interact. This model is found relevant, accurate, generalizable, and useful by practitioners. [ABSTRACT FROM AUTHOR]

The term agile is frequently used in IT especially in the area of software engineering. The broad pervasiveness of the term agile is astonishing, because it is not well defined in the area of software engineering. The fuzziness of the term agile comes with the danger of ill‐founded decisions and ideological discussions. Both slow down the gain in knowledge in the domain of software engineering. The term agile should therefore not be used either in science nor in the industry. This article provides a critical discussion of the term agile. By using a three‐layered abstraction concept for software development processes, the use of the term agile can be avoided. [ABSTRACT FROM AUTHOR]

By adopting agile and lean practices, DevOps aims to achieve rapid value delivery by speeding up development and deployment cycles, which however lead to more security concerns that cannot be fully addressed by an isolated security role only in the final stage of development. DevSecOps promotes security as a shared responsibility integrated into the DevOps process that seamlessly intertwines development, operations, and security from the start throughout to the end of cycles. While some companies have already begun to embrace this new strategy, both industry and academia are still seeking a common understanding of the DevSecOps movement. The goal of this study is to report the state‐of‐the‐practice of DevSecOps, including the impact of DevOps on security, practitioners' understanding of DevSecOps, and the practices associated with DevSecOps as well as the challenges of implementing DevSecOps. The authors used a mixed‐methods approach for this research. The authors carried out a grey literature review on DevSecOps, and surveyed the practitioners of DevSecOps in industry of China. The status quo of DevSecOps in industry is summarized. Three major software security risks are identified with DevOps, where the establishment of DevOps pipeline provides opportunities for security‐related activities. The authors classify the interpretations of DevSecOps into three core aspects of DevSecOps capabilities, cultural enablers, and technological enablers. To materialise the interpretations into daily software production activities, the recommended DevSecOps practices from three perspectives—people, process, and technology. Although a preliminary consensus is that DevSecOps is regarded as an extension of DevOps, there is a debate on whether DevSecOps is a superfluous term. While DevSecOps is attracting an increasing attention by industry, it is still in its infancy and more effort needs to be invested to promote it in both research and industry communities. [ABSTRACT FROM AUTHOR]

With years of frantic development, when release fast and release often was the mandatory rule for web technologies and services, the open source paradigm and online distribution repositories have imposed de facto standards for quality assessment in fast‐paced innovation processes. Nowadays, however, in pursuit of productivity, security, and user satisfaction, the industry is beginning, through the introduction of new standards such as ECMAScript 6 or web components, to consider software engineering mandates for web technologies. This article reports a quality model aligned with international standard ISO/IEC 25010, covering web components technology, which ultimately aims to improve adoption by the software engineering industry, traditionally wary of agile Internet practices, the open source paradigm, and public repositories. Our research also presents an experimentation platform on which end users have validated the quality properties, highlighting the implicit connection with the perceived quality. The key result of our research convinces us that user ratings are suitable as a testing mechanism for product quality and quality‐in‐use metrics in order to define an absolute scale of comparison for web component quality. [ABSTRACT FROM AUTHOR]

Agile software development in construction projects – a report summarizing the DigitalTWIN research project Project management in the construction sector is characterized by manifold and numerous interdependencies, high project volumes with variable constraints and long project durations. It requires structured and defined planning principles as well as flexibility, as criteria, assessments, and opinions change or only become clear during the course of a project. Digital tools for project management are consequently an important focus in the DigitalTWIN research project. The implementation of agile software development in the project course of grid shell structures and cable net facades show the advantages of a close collaboration between project stakeholders and specialists in data science and software engineering. Real project progress can be evaluated faster and more precisely, process designs can be developed based on data, and proven workflows can be adjusted to specific situations without losing the relation to a growing database. The paper gives an introduction to management methods and shows how knowledge and recommended actions for construction projects can be obtained faster from relevant data using individual software development. The required cloud infrastructures, platform technologies and methods are developed step by step in demonstrators and provide an outlook how collaboration can be structured, fast, comprehensive, digital and trustworthy using distributed IT systems. [ABSTRACT FROM AUTHOR]

Non‐functional requirements define qualities of the software system that ensure effectiveness while embedding any constraints and restrictions on the design. A challenge rises with agile implementation in handling non‐function requirements in regulated environments. Thus, a practitioner's perceptions of agile method tailoring are described in relation to inter‐team boundaries and non‐functional requirements. The research comprises 18 practitioner interviews from two multinational agile software development companies. Interviews were recorded, transcribed, and analysed using an approach informed by grounded theory and information flow models were used to compare and contrast interactions of processes. It was discovered that one of the case study companies managed non‐functional requirements as artefacts in their agile methodology, while the other company reverts to conventional plan‐based software development practices of documentation, timeline estimations, and safety critical requirements. This research creates a detailed comparison of these contrasting approaches. The main contribution of this study is a set of proposed recommendations to deal with non‐functional requirements in a regulated environment using agile techniques. The introduction of two new artefacts, Documentation Work Item and Safety Critical Work Item, is recommended and it is accompanied with an illustrative example, to transform the handling of documentation and safety critical requirements in a more agile way. [ABSTRACT FROM AUTHOR]

Knowledge management systems (KMS) are computer‐based systems highly valued in business organizations because they support knowledge management (KM) processes. Most KMS have been developed using non‐intelligent computer technology—that is, DMS, CMS, DBMS, and CIS—, and thus, they cannot provide advanced capabilities. Consequently, enhanced KMS using intelligent technologies of ontologies with inference engines—called ontology‐based knowledge management systems (OKMS)—have been proposed in the last three decades. Nowadays, however, the implementation of OKMS in real‐world settings is still scarce. Lack of comprehensive and systematic development methodologies including Project Management and Technical Systems Engineering processes—as the Systems and Software Systems Engineering standards propose—have been suggested as a factor that inhibits OKMS implementations. In this study, we review the OKMS literature (1990–2021 period)—from six seminal studies located using a research search engine—to assess OKMS development methodologies that can be considered comprehensive and systematic. Five methodologies were identified and assessed using an evaluation subset from the ISO/IEC/IEEE 15288:2015 Systems and Software Engineering standard. Two of them—CommonKADS and NeON—were found with a high comprehensive and systematic level and both are suggested for organizations interested in OKMS implementations, but none of them qualified as agile, which is a current development approach for systems and software systems. Hence, further empirical research toward the realization of comprehensive and systematic OKMSs development methodologies, including agile versions, is suggested for fostering the implementation of OKMS in real‐world settings. [ABSTRACT FROM AUTHOR]

Software requirement engineering (SRE) is the initial stage of the software engineering process and entails several challenges relating to the identification, implementation, evolution, and management of requirements for the development of software systems that meet the desired functionality quality standards. Agile software development (ASD) is a well‐known software development process that follows a lightweight and adaptive methodology to support the incremental development of software systems. Since the ASD follows an adaptive procedure (ie, a flexible, nanostructured, and dynamic approach) of software development, it becomes challenging to perform SRE that follows a structured approach for managing software requirements throughout the life cycle of software development. The primary challenges for SRE, while pursuing an ASD, include, but are not limited to, identification of incomplete requirements, implementation of vague requirements, prioritization of secondary functional requirements, and compromise on users' involvement that negatively impacts the software system's functionality and quality. To overcome these challenges, some of the recent research efforts have focused on managing different phases of SRE during software development using the ASD. However, there is a lack of solutions that provide software engineers/practitioners with a solution. Besides, frameworks to effectively manage all the phases of SRE as per the needs of the ASD are needed. We propose a framework that unifies joint requirements document (JRD) and SCRUM to incrementally (a) identify, (b) implement, (c) evolve, and (d) manage system requirements throughout the software development cycle. We have used the action research method to qualitatively validate the proposed framework based on data and user requirements collected from a product‐focused (multinational) Norway‐based software company. The results of the validation are based on statistical analysis that reflects the usefulness of the proposed framework for SRE in ASD‐based software engineering and development. Future research is the possible application of a machine learning approach (es) in the intended context for agile requirements elicitations. [ABSTRACT FROM AUTHOR]

Software Development is a complex process, in which every software product is a knowledge representation of all the involved people. In agile software development, knowledge is prone to vaporise, because documentation is not a priority as indicated in the agile manifesto. This condition generates problems such as poor understanding of the requirements, knowledge transfer deficiency among developers, time wasted by developers while searching for knowledge. The objective of this work is to reduce architectural knowledge vaporisation by means of knowledge condensation to support expertise location (high‐level knowledge at a given time). This through an ontology that will condensate the knowledge in the code phase. This study presents the description of an ontology development process following the Methontology Framework. Results show that the proposed ontology does not present incongruence or inconsistency and answers the competency questions correctly. The main contribution of this study is the ontology which brings several benefits such as a shared concept of the knowledge in the code phase and a way to link the artefacts (resources used by developers in the project) and the experts (artefacts provider). [ABSTRACT FROM AUTHOR]

Nowadays computer games are applied beyond entertainment. Gamification, the application of game elements in non-game environments supports behavioural studies in different disciplines including software engineering, the area in which collaborative work has become a fundamental key. The most used gamification elements in software development environments were analysed from two perspectives: (i) team building or reinforcement activities; and (ii) regarding a set of people's interactive styles. Then, interactive styles with software engineering roles were related in order to be able to identify scenarios that conform a model to build highly effective teams. The three analyses together allow identifying proper gamification elements for modelling scenarios to support the creation of highly effective teams in the software development domain. [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: Software developing organizations strive to achieve flexibility to maintain a competitive advantage. There is no common understanding of what characterize flexibility for a software organization beyond the scope of the software product. Without a common understanding, it is difficult to evaluate the degrees of flexibility of software development approaches. The aim of this literature review is to collect attributes that characterize flexibility. The collected attributes are consolidated into a flexibility framework with 3 main attributes: properties of change, flexibility perspectives, and flexibility enablers. The resulting flexibility framework is then used to evaluate Agile and Lean practices. The evaluation shows that Agile and Lean practices address many flexibility attributes. However, some attributes are not addressed, such as infrastructure flexibility and strategic flexibility. On the basis of our evaluation, the classifications of flexibility attributes that we present in this paper could be used to aid software organization flexibility evaluation. [ABSTRACT FROM AUTHOR]

Abstract: Over the last decade, the use of agile methods has grown dramatically for software development. Agile methods guarantee to accelerate the delivery of remarkable software with increased user satisfaction and reduced cost. However, in recent years, due to the emergence of green software engineering, software developers are compelled to focus more on green and sustainable aspects of software. Green software engineering aims to design, develop, and use the software with confined energy and computing resources. Recently, software engineers in global software development have adapted agile methods for quick, interactive, and environment‐friendly software development. In this study, we have identified 16 success factors, through systematic literature review (SLR) and applied contrived search criteria derived from the research questions; 80 relevant papers were identified and reviewed. Findings of the SLR study were then empirically validated through questionnaire survey in global software development industry, in which 106 experts from 25 different countries participated. The findings of our industrial survey are mostly in coherence with the SLR findings. However, there is a difference in ranks of the various success factors across the 2 data sets (SLR and industrial survey). [ABSTRACT FROM AUTHOR]

From its earliest days, software development has been beset with challenges in relation to timely delivery, appropriateness of features, and quality of deliverables. Many advances in software development processes have helped to address these concerns. For example, agile software development has helped to deliver working software more frequently, and capability maturity frameworks have brought about improved consistency in quality levels. However, the age-old challenge of better, cheaper, faster software has continued to beguile developers. In this paper, we discuss an emerging approach to software development, continuous software engineering (CSE), wherein software of operational quality may be delivered on a very frequent basis, up to many times in a given day. This approach uses a complex set of independent tools that together reduce the lead time in delivering commercial-grade software. Having examined the situational context of one industrial organization applying CSE, we conclude that the approach may not presently be appropriate to all manners of software development. Nonetheless, the authors are of the view that CSE represents a significant progression in software engineering and that software development settings of all types stand to gain from aspects of the CSE approach. [ABSTRACT FROM AUTHOR]

Software product lines (SPL) and Agile practices have emerged as new paradigms for developing software. Both approaches share common goals; such as improving productivity, reducing time to market, decreasing development costs and increasing customer satisfaction. These common goals provide the motivation for this research. We believe that integrating Agile practices into SPL can bring a balance between agility and formalism. However, there has been a little research on such integration. We have been researching the potential of integrating Agile approaches in one of the key SPL process areas, product derivation (PD). In this paper, we present an outline of our Agile process model for PD that was developed through industry-based case study research. [ABSTRACT FROM AUTHOR]

The Agile Software Development paradigm has become increasingly popular in the last few years, since it claims lower costs, better productivity, better quality and better business satisfaction. Supply chain management (SCM) is a complex software development project. Owing to its scope and uncertain, complex and unstable requirements, it is not possible to develop it with predictable software development process models. Agile methodologies are targeted toward such kinds of problems that involve change and uncertainty, and are adaptive rather than predictive. How an agile process is introduced will significantly impact the implementation success of the process change. The objective of this paper is to analyze the agile development methodologies and management approach used in developing a complex software project. This further demonstrates how to overcome risks and barriers in each development phase of such complex inventive software projects. It also provides a set of guidelines regarding how the agile methodologies can be adopted, combined and used in these kinds of complex software projects. These findings have implications for software engineers and managers developing software by agile methods. Copyright © 2011 John Wiley & Sons, Ltd. [ABSTRACT FROM AUTHOR]

For the last 4 years, we have been experimenting with the parallel agile (PA) approach. PA achieves significant schedule compression by leveraging parallelism; large teams of developers can independently and concurrently develop scenarios from initial concept through code. This paper summarizes our experience in defining and evolving PA by applying it to four representative emergent‐technology applications: location‐based advertising, picture sharing, bad driver reporting, and a VR/AR game project. In comparison with the mainstream architected agile process that we had been using on similar systems, the PA process has consistently achieved significant speedups in system development while simultaneously reducing defects. PA uses storyboards and prototypes to define both sunny‐day and rainy‐day scenarios, defines requirements for each use case, and decomposes each use case into a conceptual model‐view‐controller (MVC) pattern. PA also uses code generation from UML models to rapidly construct a domain‐driven microservice architecture at the inception of a project. This microservice architecture is then used to enable prototype code to interact with a live database during requirements definition. PA then uses automatic test case generation from the same UML model. The paper summarizes the overall challenge of software schedule compression, identifies managed parallel development as generally the most powerful but least‐practiced strategy for schedule compression, and summarizes the key elements required to support parallelism. It then summarizes the key techniques for scaling up PA, using a previous million‐line command and control project as an example. We have used MS‐degree graduate student projects to gather productivity data because the university environment has afforded us the opportunity to explore massively parallel development over an extended time period. We are now working with a large company to modernize their main legacy system using the PA methods. The prospective looks good as many of the techniques used (eg, domain models, use case analysis, and MVC decomposition) have been proven to be effective in industry on a wide range of projects for multiple decades. The new techniques (eg, executable domain models, and visual modeling of sprint plans) should also serve to make integration and project management work better on large development efforts. [ABSTRACT FROM AUTHOR]

Continuous software engineering (CSE) emerged as a process that is increasingly applied by practitioners. However, different perceptions impede its adoption in industry. Furthermore, opportunities through utilizing usage and decision knowledge remain unexploited. We conducted a semi‐structured interview study with 24 practitioners from 17 companies to study how practitioners apply CSE during software evolution and how usage and decision knowledge can support CSE. Regarding the application of CSE, we identified five perspectives on CSE with tool‐ and methodology‐driven definitions most prevalent. Automated tests, involved users, and shared rulesets are perceived as most relevant for CSE. Practitioners report more positive than negative experiences; however, more than half of their responses were neutral. Practitioners' future plans for CSE focus on enhancement, expansion, and on‐demand adaption. Regarding the integration of usage and decision knowledge into CSE, practitioners perceive accountability and traceability as major benefits, while raising concerns about its feasibility and user groups. As short‐term extensions, practitioners expect improvements regarding automation and role aspects, while long‐term additions to integration and experimentation capabilities are demanded. We conclude that CSE remains partially difficult to capture for practitioners, while their attitude toward integrating usage and decision knowledge into CSE is positive. [ABSTRACT FROM AUTHOR]

Almost all companies struggle with software systems that are getting increasingly complex. Therefore, in particular large companies often use software product lines, which provide an efficient way to manage software reuse as well as the high complexity. However, software product lines seem to be too slow to react to changes. Agile development approaches promise to meet this demand. At the same time, integrating an agile approach is not always easy. Consequently, there is a need for a transformation model that supports the agile transformation without harming the benefits of software product lines. In this paper, we present the results of a literature review regarding agile transformation in large software companies. Our results summarize the insights from 85 papers and present a list of 20 tasks and tasks that are recommended by several researchers to be considered during the transformation. On the basis of these results, we create an agile transformation model—the so‐called "agile hamburger"—that contains these tasks and preserves software product lines. Since the model is rather coarse grained and generic, we also support the adaption to different teams by presenting an assessment model tailored to the demands of the automotive domain. [ABSTRACT FROM AUTHOR]

Many smaller companies cannot afford the time and effort to change their development processes all at once. In some cases, companies are not aware of the fact that many aspects of agile development are already in place. The aim of this work was to evaluate if an evolutionary transition to agile software development is suitable for small companies. We conducted a case study with a small company to start their step‐by‐step agile transition. Initially, three agile software development practices were introduced. Based on the assessment of improvements, the transition continued with three Kanban practices. Experiences with the improvement process and the selected practices were elicited by means of qualitative interviews for data collection. Our case study reports details on the implementation of the first practices as well as the way the resulting agile transition has taken so far. The positive experiences reported by all employees during the agile transition indicate that an evolutionary transition is suitable for small companies. The experiences concerning the transition process and the positive effects of the selected practices motivate practitioners to start their own agile transition. [ABSTRACT FROM AUTHOR]

The values of software organizations are crucial for achieving high performance; in particular, agile development approaches emphasize their importance. Researchers have thus far often assumed that a specific set of values, compatible with the development methodologies, must be adopted homogeneously throughout the company. It is not clear, however, to what extent such assumptions are accurate. Preliminary findings have highlighted the misalignment of values between groups as a source of problems when engineers discuss their challenges. Therefore, in this study, we examine how discrepancies in values between groups affect software companies' performance. To meet our objectives, we chose a mixed method research design. First, we collected qualitative data by interviewing fourteen (N  =  14) employees working in four different organizations and processed it using thematic analysis. We then surveyed seven organizations (N  =  184). Our analysis indicated that value misalignment between groups is related to organizational performance. The aligned companies were more effective, more satisfied, had higher trust, and fewer conflicts. Our efforts provide encouraging findings in a critical software engineering research area. They can help to explain why some companies are more efficient than others and, thus, point the way to interventions to address organizational challenges. [ABSTRACT FROM AUTHOR]