Large-scale Software Development Projects Research Articles

Identifying and Categorizing Challenges in Large-Scale Agile Software Development Projects: Insights from Two Swedish Companies

We conducted a case study to examine the challenges encountered in large-scale agile development (LSAD) within two Swedish software companies. While agile methodologies have proven successful in small and medium-sized projects, their implementation in large-scale software development projects can be problematic. To identify these challenges, we employed thematic analysis, which revealed a total of 26 distinct challenges. These challenges were categorized into three main themes: Processes and practices, Teams, and Organizational-level challenges in LSAD. By recognizing and addressing these challenges, projects operating in similar contexts can synchronize their activities and harness the advantages of agile methodologies at a large scale. The article delves into comprehensive discussions on these challenges, offering valuable insights and directions for future research endeavors.

Identifying and Categorizing Challenges in Large-Scale Agile Software Development Projects: Insights from Two Swedish Companies

We conducted a case study to examine the challenges encountered in large-scale agile development (LSAD) within two Swedish software companies. While agile methodologies have proven successful in small and medium-sized projects, their implementation in large-scale software development projects can be problematic. To identify these challenges, we employed thematic analysis, which revealed a total of 26 distinct challenges. These challenges were categorized into three main themes: Processes and practices, Teams, and Organizational-level challenges in LSAD. By recognizing and addressing these challenges, projects operating in similar contexts can synchronize their activities and harness the advantages of agile methodologies at a large scale. The article delves into comprehensive discussions on these challenges, offering valuable insights and directions for future research endeavors.

Implementing Agility in Large Software Development Projects

The present paper focuses on providing an in-depth understanding of the concept of agility and its uses in the software development projects. The paper also explains the key issues experienced by large companies while implementing agility practices and frameworks in the large-scale software development projects. The paper also develops key ideas about the procedure involved in implementing agility practices through extensive study of previous literature in this context. It also recommends certain methods in which the issues experienced during the implementation of agility in large scale software development projects can be minimized. The findings provide insights about the various challenges and reasons behinds such issues that are common in such large-scale software development projects drawing instances of international companies providing software development services.

Herding cats in a FOSS ecosystem: a tale of communication and coordination for release management

Release management in large-scale software development projects requires significant communication and coordination. It is particularly challenging in Free and Open Source Software (FOSS) ecosystems, in which hundreds of loosely connected developers and their projects are coordinated to release software to a schedule. To better understand this process and its challenges, we analyzed over two and half years of communication in the GNOME ecosystem and studied developers’ interactions. Through a case study, we cataloged communication channels, determined the main channel from which we categorized high level communication and coordination activities spanning five releases, and triangulated our results by interviewing ten key developers. We found that a release schedule, influence (instead of direct control), and diversity are the main factors that positively impact the release process in the GNOME ecosystem. We report a set of lessons learned that encapsulates our understanding of how the Release Management process function in a FOSS ecosystem, we learned that: (1) ensure that the release team follows the main communication channels used by developers, (2) provide a common place for coordination for an ecosystem, (3) consider including both good technical and social skills in a release team, (4) aim for a diverse release team, (5) based on lack of power, lobbying and consensus based management must be followed, (6) help the release team in the coordination process with a well defined schedule, and (7) release team work is different from regular software work. Our results can help organizations build better large-scale teams and show that research focused on individual projects might miss important parts of the picture.

1306 大規模プロジェクトの継続的な対応による改善について(一般セッション)

1306 大規模プロジェクトの継続的な対応による改善について(一般セッション)

Software teams and their knowledge networks in large-scale software development

ContextLarge software development projects involve multiple interconnected teams, often spread around the world, developing complex products for a growing number of customers and users. Succeeding with large-scale software development requires access to an enormous amount of knowledge and skills. Since neither individuals nor teams can possibly possess all the needed expertise, the resource availability in a team's knowledge network, also known as social capital, and effective knowledge coordination become paramount. ObjectiveIn this paper, we explore the role of social capital in terms of knowledge networks and networking behavior in large-scale software development projects. MethodWe conducted a multi-case study in two organizations, Ericsson and ABB, with software development teams as embedded units of analysis. We organized focus groups with ten software teams and surveyed 61 members from these teams to characterize and visualize the teams’ knowledge networks. To complement the team perspective, we conducted individual interviews with representatives of supporting and coordination roles. Based on survey data, data obtained from focus groups, and individual interviews, we compared the different network characteristics and mechanisms that support knowledge networks. We used social network analysis to construct the team networks, thematic coding to identify network characteristics and context factors, and tabular summaries to identify the trends. ResultsOur findings indicate that social capital and networking are essential for both novice and mature teams when solving complex, unfamiliar, or interdependent tasks. Network size and networking behavior depend on company experience, employee turnover, team culture, need for networking, and organizational support. A number of mechanisms can support the development of knowledge networks and social capital, for example, introduction of formal technical experts, facilitation of communities of practice and adequate communication infrastructure. ConclusionsOur study emphasizes the importance of social capital and knowledge networks. Therefore, we suggest that, along with investments into training programs, software companies should also cultivate a networking culture to strengthen their social capital, a known driver of better performance.

Ensuring Success in a Large Scale Software Project: An Examination of the Learning Styles and Characteristics of the Potential End Users

Many software development projects face a high rate of failure, which prevents them from achieving the intended outcome. One of the reasons for this might be due to ignoring the end users during the development of the software. To counter this, well-organized training programs can be devised to show end users how to use the software. This training has a crucial role in the success and dissemination of the software development projects. The aim of this study was to examine the correlation between personality traits and learning styles of the end users in a large-scale software development project. The results of the study revealed that there was a distinct relationship between the learning styles and personal attitudes of the users. Personality traits such as extraversion and openness were found to be associated with the learning preferences of individuals. In Kolb’s terms, the converger learners were more open than the diverger learners. Furthermore, the end users were mostly satisfied with the training program, which can be attributed to the efficiency of the curriculum design, sufficiency of the provided facilities and competence of the trainers.

SW개발 프로젝트 관리시스템 도입 및 적용사례에 대한 연구

In this paper, we introduce PMS’s main function and main effect which implemented medium and large scale software development project site, and we propose importance and improvement nacessity of PMS implementation. PMS’s main functions are developed based on best practices which CMMI model and PMBOK. Also, each PMS has specialized unique function according to it’s target industry area or related I.T solutions which has infra dependency. The effectiveness of PMS implementation on project site is seperated two types, one is qualitative effect, the other quantitative effect. Representative qualitative effects are improvement of enterprise’s image and competency. Also representative quantitative effect is ∙제1저자 : 전형권 ∙교신저자 : 박구락 ∙투고일 : 2013. 8. 2, 심사일 : 2014. 1. 7, 게재확정일 : 2015. 5. 27. * 공주대학교 멀티미디어공학과(Dept. of Multimedia Engineering Computer Science, Kongju national University) ** 공주대학교 컴퓨터공학부(Dept. of Computer Science & Engineering, Kongju national University) *** 대전보건대학교 바이오정보과(Dept. of Bio Information, DaeJeon Health Sciences College) 92 Journal of The Korea Society of Computer and Information May 2015 reduction of project management cost as a financial effect. As far as project size is increase, PMS’s needs and necessariness will be increase, so we need to improve PMS;s function according to project management’s global trend and software customer’s requisition. ▸

Formalizing the transition from requirements’ change to design change using an evolutionary traceability model

The ideal outcome when responding to changes in the functional requirements of a system is that we can quickly determine (1) where to make the change, (2) how the change affects the architecture of the existing system, (3) which components of the system are affected by the change, and (4) what behavioral changes will need to be made to the components (and their interfaces) that are affected by the change of requirements. If these facts are known, the impact of the change is entirely understood and therefore manageable. Moreover, a system is likely to undergo multiple changes over the course of its service life, so there is also a need to make a comprehensive record of these changes thus preserving the integrity of the system and potentially extending its service life. To this worthy end, a traceability model using Behavior Trees as a formal notation to represent functional requirements is proposed. This will address the issues cited above, revealing change impacts on different types of design constructs (documents) caused by the changes to the requirements. The proposed model introduces the concept of evolutionary design documents that record the change history of the designs. From these documents, any version of a design document as well as the difference between any two versions can be reviewed, thus affording the desirable condition of full traceability. An important advantage of this model is that the major part of the procedure to generate these evolutionary design documents can be supported by automated tools making the method accessible for use in large-scale software and systems development projects.

Empirical research in software architecture: opportunities, challenges, and approaches

Software architecture has become an important area of research and practice since the late 1980s (Shaw and Clements 2006). The term “software architecture” started gaining acceptance by the software engineering community in early 1990s but the foundations of this field were laid by the seminal work of Edsger Dijkstra, David Parnas, and others between 1960s and 1980s (Clements 2000). The increasing size and complexity of software systems and demand for high quality are some of the most important factors that have driven the increased interest in this sub-discipline of software engineering. It has generally been realized that a high-level design description can play an important role in successfully understanding and managing large and complex software systems (Clements et al. 2002; Lung and Kalaichelvan 2000). The high-level design decisions regarding the software architecture of a system are not only the hardest and most expensive to change but also play a fundamental role in setting the boundaries for the required quality attributes such as maintainability, reliability, usability, performance, and flexibility of a system (Bass et al. 2003; Clement and Northorp 1996). As a result of increasing realization of the important role of software architecture in large-scale software development and evolution projects, the software architecture community has developed several methods, techniques, and tools to support the software Empir Software Eng (2011) 16:539–543 DOI 10.1007/s10664-011-9168-6

External sponsored projects

Although student experience with large-scale software development projects contributes significantly to their education, the burden of managing projects for external sponsors can be equally significant for the faculty. While sponsored projects provide more real-world experiences, can the additional demands on the faculty be too much? This paper explores the lessons we have learned over six years of faculty experience with sponsored projects.

JWARS: A Case Study

This paper is a management-oriented review of a large-scale government software development project. The product is the Joint Warfare System (JWARS), a theater-level warfare simulation intended to support U.S. Department of Defense decision-making. This paper discusses all aspects of the JWARS development project from 1995 until 2002. Unique features included object-oriented development, an integrated government-contractor environment, and involvement of users and subject matter experts in development and testing.

A student-enacted simulation approach to software engineering education

In some cases, real-world application of software engineering concepts does not effectively map with current undergraduate curriculums. Typically, a student's first "hands-on" experience working on large-scale software development projects is via an intern position or his/her first full-time position. However, prior exposure to the corporate project environment would greatly improve a student's performance in industry. In order to develop students for successful careers in software engineering, specifically for software development, they must be immersed not only in the software development lifecycle and paradigms, but also in the workings of large project teams. Currently, most undergraduate software engineering courses are taught by presenting the concepts and methodologies and assigning fragmented three-to-four person group projects. In the Department of Computer Science, Georgetown University, Washington, DC, a two-course approach to undergraduate software engineering education has been developed that incorporates the practical application of coursework in a large team setting. The first course presents a firm software design basis, while the second course demonstrates corporate-level software engineering concepts with a semester-long software development simulation where the entire class is the development team. This paper presents the experiences from offering this software engineering simulation approach.

Making inconsistency respectable in software development

The development of software systems inevitably involves the detection and handling of inconsistencies. These inconsistencies can arise in system requirements, design specifications and, quite often, in the descriptions that form the final implemented software product. A large proportion of software engineering research has been devoted to consistency maintenance, or geared towards eradicating inconsistencies as soon as they are detected. Software practitioners, on the other hand, live with inconsistency as a matter of course. Depending on the nature of an inconsistency, its causes and its impact, they sometimes choose to tolerate its presence, rather than resolve it immediately, if at all. This paper argues for “making inconsistency respectable” [A phrase first used by D. Gabbay and A. Hunter (in: Proceedings of Fundamentals of Artificial Intelligence Research'91, Springer, Berlin, p. 19; in: Symbolic and Quantitative Approaches to Reasoning and Uncertainty, Lecture Notes in Computer Science, Springer, Berlin, 1992, p. 129) to describe the same sentiments that motivated our work.] – sometimes avoided or ignored, but more often used as a focus for learning and as a trigger for further (constructive) development actions. The paper presents a characterization of inconsistency in software development and a framework for managing it in this context. It draws upon practical experiences of dealing with inconsistency in large-scale software development projects and relates some lessons learned from these experiences.

SIMD machines

I volunteered to write this report during the SIMD panel session held on 2/9/95 at Frontiers '95. All panelists cooperated by sending me their transparency masters. A draft report was prepared based on these transparency masters, position statements published in the Frontiers '95 proceedings on pp. 466-469, and my own notes. The draft was e-mailed on 3/17/95 to the panel organizer/moderator and the panelists for their comments. This final version of the report is based on comments and markups received through 3/31/95. I have drawn from the panelists' ideas freely, using quotation marks only when including their statements verbatim.The panel consisted of both academic and industry experts in the field of massively parallel systems (see the table below). All but Tim Bridges, who is currently involved in a large-scale software development project for the MasPar MP-2 SIMD architecture, have built working SIMD machines. The vast practical experience of the panel was quite evident in the insightful presentations and interactions. It is indeed a privilege for me to have worked on this report.

PM-Net: a software project management representation model

A model called PM-Net for representing and monitoring the software development process is presented. This model provides information for progress management, as well as information of project status at different levels of detail, for the benefit of project managers. The model emphasizes bottom-up data collection and top-down information inquiry functions. The Data Flow Diagram (DFD) and Work Breakdown Structure (WBS) techniques are utilized for construction of a hierarchical structure of the software development process. This process can be viewed as a set of activities; each activity can be viewed as a set of subactivities, and each subactivity can be viewed as a set of tasks. Managers can make an inquiry regarding project progress information at process level, activity level, subactivity level or task level, depending on the degree of details they require. The manager can also change the control state operators at the lowest level of activity which will enable a transition for a change of process status at the upper-level activity. This ensures that any large-scale software development project based on PM-Net will be able to represent the most recent project progress status at any time in the project's running duration, so that managers can monitor the project progress more effectively.

"Some criteria for classification and evaluation of discrete event simulation languages"

In order to describe (model) a given system in a more or less disciplined way, some kind of formal or informal "system description language", providing a "world view" for concept articulation and communication will be explicitely or implicitely used. To appreciate the importance of an "appropriate" frame of reference, it should be considered, that a system description methodology will necessarily be used as a device for structuring the thinking of its users. The severe problems encountered by large-scale software development projects have recently led to widespread recognition of the importance of structuring and levels of abstraction as a method supporting reliable engineering of systems; /DENNING74/.