Development Team Size Research Articles

WhoReview: A multi-objective search-based approach for code reviewers recommendation in modern code review

Contemporary software development is distributed and characterized by high dynamics with continuous and frequent changes to fix defects, add new user requirements or adapt to other environmental changes. To manage such changes and ensure software quality, modern code review is broadly adopted as a common and effective practice. Yet several open-source as well as commercial software projects have adopted peer code review as a crucial practice to ensure the quality of their software products using modern tool-based code review. Nevertheless, the selection of peer reviewers is still merely a manual and hard task especially with the growing size of distributed development teams. Indeed, it has been proven that inappropriate peer reviewers selection can consume more time and effort from both developers and reviewers and increase the development costs and time to market. To address this problem, we introduce a multi-objective search-based approach, named WhoReview, to find the optimal set of peer reviewers for code changes. We use the Indicator-Based Evolutionary Algorithm (IBEA) to find the best set of code reviewers that are (1) most experienced with the code change to be reviewed, while (2) considering their current workload, i.e., the number of open code reviews they are working on. We conduct an empirical study on 4 long-lived open source software projects to evaluate our approach. The obtained results show that WhoReview outperforms state-of-the-art approach by an average precision of 68% and recall of 77%. Moreover, we deployed our approach in an industrial context and evaluated it qualitatively from developers perspective. Results show the effectiveness of our approach with a high acceptance ratio in identifying relevant reviewers.

Strategies for reward based crowdfunding campaigns in video games: a context of indie game developers in the UK

The objective of the study was to define key success factors and challenges of a crowdfunding campaign for an indie games developer in the UK - We suggest that the key success factors identified can be separated into three categories- campaign factors, product factors, and human factors and propose a model including all three. A good campaign needs careful preparation prior to the launch, effective presentation, appropriate funding model with a realistic funding target for a short period, digital reward structure and well-planned marketing activities. Product characteristics appear to be a playable demo of the game which should be unique yet still having some familiar features. Human factors include having a pre-established audience reach, a relevant background in game development and appropriate team size. A main restraining factor was the stress and time cost of running the campaign, whilst intellectual property issues were found to be less important than expected.

Strategies for reward based crowdfunding campaigns in video games: a context of indie game developers in the UK

The objective of the study was to define key success factors and challenges of a crowdfunding campaign for an indie games developer in the UK – We suggest that the key success factors identified can be separated into three categories- campaign factors, product factors, and human factors and propose a model including all three. A good campaign needs careful preparation prior to the launch, effective presentation, appropriate funding model with a realistic funding target for a short period, digital reward structure and well-planned marketing activities. Product characteristics appear to be a playable demo of the game which should be unique yet still having some familiar features. Human factors include having a pre-established audience reach, a relevant background in game development and appropriate team size. A main restraining factor was the stress and time cost of running the campaign, whilst intellectual property issues were found to be less important than expected.

Using Remote Cache Service for Bazel

Remote cache service is a new development that significantly saves time in running builds and tests. It is particularly useful for a large code base and any size of development team. Bazel is an actively developed open-source build and test system that aims to increase productivity in software development. It has a growing number of optimizations to improve the performance of daily development tasks.

An Excursion to Software Development Life Cycle Models

Software Engineering provides a standard way to develop and maintain a complex software. Industry uses software development Life Cycles (SDLC) to develop a software. SDLC plays an important role as it helps to define the software requirements, model the software component, reduce development and maintenance cost and finally provides manageable software. There exist numerous SDLC models viz. Waterfall, Incremental, Rapid, Agile, Hybrid etc. After a comprehensive study and analysis of existing SDLC models, I observe all models are complementary, not competitive. I divide all models into three broad categories viz. Traditional models, Agile models and Hybrid models. The main objective of the paper is to give a quick review of SDLC models and an effective answer to the most confusing question arise in software engineering practice "how to select an efficient SDLC model for practice?" Many factors viz. nature of requirements, the size of software development team, project size, customer interaction etc. have an effect on selection criteria. This paper presents a brief insight into each model and its comparative analysis. The analysis helps to understand the basic characteristics of each model and its applicability. Furthermore, the analysis helps software manager to select the appropriate model for practice

From Aristotle to Ringelmann: a large-scale analysis of team productivity and coordination in Open Source Software projects

Complex software development projects rely on the contribution of teams of developers, who are required to collaborate and coordinate their efforts. The productivity of such development teams, i.e., how their size is related to the produced output, is an important consideration for project and schedule management as well as for cost estimation. The majority of studies in empirical software engineering suggest that - due to coordination overhead - teams of collaborating developers become less productive as they grow in size. This phenomenon is commonly paraphrased as Brooks' law of software project management, which states that "adding manpower to a software project makes it later". Outside software engineering, the non-additive scaling of productivity in teams is often referred to as the Ringelmann effect, which is studied extensively in social psychology and organizational theory. Conversely, a recent study suggested that in Open Source Software (OSS) projects, the productivity of developers increases as the team grows in size. Attributing it to collective synergetic effects, this surprising finding was linked to the Aristotelian quote that "the whole is more than the sum of its parts". Using a data set of 58 OSS projects with more than 580,000 commits contributed by more than 30,000 developers, in this article we provide a large-scale analysis of the relation between size and productivity of software development teams. Our findings confirm the negative relation between team size and productivity previously suggested by empirical software engineering research, thus providing quantitative evidence for the presence of a strong Ringelmann effect. Using fine-grained data on the association between developers and source code files, we investigate possible explanations for the observed relations between team size and productivity. In particular, we take a network perspective on developer-code associations in software development teams and show that the magnitude of the decrease in productivity is likely to be related to the growth dynamics of co-editing networks which can be interpreted as a first-order approximation of coordination requirements.

Get Fat Fast: Surviving Stage‐Gate® in NPD

Stage‐Gate® is a widely used product innovation process for managing portfolios of new product development projects. The process enables companies to minimize uncertainty by helping them identify—at various stages or gates—the “wrong” projects before too many resources are invested. The present research looks at the question of whether using Stage‐Gate® may lead companies also to jettison some “right” projects (i.e., those that could have become successful). The specific context of this research involves projects characterized by asymmetrical uncertainty: where workload is usually underestimated at the start (because new development tasks or new customer requirements are discovered after the project begins) and where the development team's size is often overestimated (because assembling a productive team takes more time than anticipated). Software development projects are a perfect example. In the context of an underestimated workload and an understaffed team, the Stage‐Gate® philosophy of low investment at the start may set off a negative dynamic: low investments in the beginning lead to massive schedule pressure, which increases turnover in an already understaffed team and results in the team missing schedules for the first stage. This delay cascades into the second stage and eventually leads management to conclude that the project is not viable and should be abandoned. However, this paper shows how, with slightly more flexible thinking (i.e., initial Stage‐Gate® investments that are slightly less lean), some of the ostensibly “wrong” projects can actually become the “right” projects to pursue. Principal conclusions of the analysis are as follows: (1) adhering strictly to the Stage‐Gate® philosophy may well kill off viable projects and damage the firm's bottom line; (2) slightly relaxing the initial investment constraint can improve the dynamics of project execution; and (3) during a project's first stages, managers should focus more on ramping up their project team than on containing project costs.

Probabilistic and analytical estimation of software development team size

Labor cost is one of the major contributors of software development cost. Among the variables that affects labor cost is the software development team size. There are very few methods available in literature to determine software development team siz

The relationship between software development team size and software development cost

The relationship between software development team size and software development cost

An approach to optimizing software development team size

This paper explores the relationship between software size, development effort and team size. We propose an approach aimed at finding the team size where the project effort has its minimum. The approach was applied to the ISBSG repository containing nearly 4000 software projects. Based on the results we provide our recommendation for the optimal or near-optimal team size in seven project groups defined by four project properties.

Modeling Coordination in Software Construction: An Analytical Approach

Software development projects are typically team efforts, wherein groups of specialists work toward the common goal of building a software system. The individual efforts of team members need to be coordinated to ensure product quality and effectiveness of the team. In this paper we model the process of coordination in the construction phase of incrementally developed, modular software systems. The analytical model proposed here supports macro-level decisions regarding the development team size and the coordination policy, based upon micro-level interactions between the modules in a system. The objective in this model is to minimize the effort spent on coordination activities subject to the requirement that the system must be completed within a specified period. Results from the model are used to examine coordination related trade-offs. We show that: (1) more complex systems need a higher level of coordination than simpler ones, (2) if the time available for construction reduces, it is optimal to reduce the level of coordination, and (3) marginal productive output is a diminishing function of team size. The sensitivity of the analytical model with respect to its assumptions is studied by constructing a set of simulation experiments where these assumptions are relaxed. The results of these experiments provide support in establishing the robustness of the analytical model.