Mathieu Lavallée

The impacts of software process improvement on developers: a systematic review

This paper presents the results of a systematic review on the impacts of Software Process Improvement (SPI) on developers. This review selected 26 studies from the highest quality journals, conferences, and workshop in the field. The results were compiled and organized following the grounded theory approach. Results from the grounded theory were further categorized using the Ishikawa (or fishbone) diagram. The Ishikawa Diagram models all the factors potentially impacting software developers, and shows both the positive and negative impacts. Positive impacts include a reduction in the number of crises, and an increase in team communications and morale, as well as better requirements and documentation. Negative impacts include increased overhead on developers through the need to collect data and compile documentation, an undue focus on technical approaches, and the fact that SPI is oriented toward management and process quality, and not towards developers and product quality. This systematic review should support future practice through the identification of important obstacles and opportunities for achieving SPI success. Future research should also benefit from the problems and advantages of SPI identified by developers.

Why good developers write bad code: an observational case study of the impacts of organizational factors on software quality

How can organizational factors such as structure and culture have an impact on the working conditions of developers? This study is based on ten months of observation of an in-house software development project within a large telecommunications company. The observation was conducted during mandatory weekly status meetings, where technical and managerial issues were raised and discussed. Preliminary results show that many decisions made under the pressure of certain organizational factors negatively affected software quality. This paper describes cases depicting the complexity of organizational factors and reports on ten issues that have had a negative impact on quality, followed by suggested avenues for corrective action.

Performing Systematic Literature Reviews With Novices: An Iterative Approach

Reviewers performing systematic literature reviews require understanding of the review process and of the knowledge domain. This paper presents an iterative approach for conducting systematic literature reviews that addresses the problems faced by reviewers who are novices in one or both levels of understanding. This approach is derived from traditional systematic literature reviews and based on observations from four systematic reviews performed in an academic setting. These reviews demonstrated the importance of defining iterations for the eight tasks of the review process. The iterative approach enables experiential learning from the two levels of understanding: the process level and the domain level.

Software team processes: a taxonomy

A software development team must integrate many process perspectives imposed by the client, the organization, team management, and team dynamics. All these perspectives intermingle at the team process level. We propose a taxonomy to define the various episodes observed at this level and a useful vocabulary for reporting the observations made. Our taxonomy is based on a previous literature review performed in the business management field and adapted in this paper for the software engineering field. It was applied on existing data obtained from a real project carried out with an industrial partner. The vocabulary defined can accurately present team interactions, and may help diagnose communication breakdowns leading to project failures. The benefit of this approach is that it enables team process activities to be measured without reference to specific concepts related to perspectives other than that of the team process.

Planning for the unknown: lessons learned from ten months of non-participant exploratory observations in the industry

Convincing industrial partners to support an exploratory study can be difficult, as benefits are often fuzzy at the beginning. The objective of this paper is to present recommendations for industrial exploratory studies based on our experience. The recommendations are based on ten months of observations during a non-participant, exploratory study with a single industrial partner. This study confirms a number of methodological challenges already identified in the software engineering literature. Based on recommendations from the literature and our own experience, we propose a process for future observational exploratory studies.

A Knowledge-Based Perspective for Software Process Modeling

As the acquisition and sharing of knowledge form the backbone of the software development process, it is important to identify knowledge discrepancies between the process elements. Explicit representation of the knowledge components within a software process model can provide a means to expose these discrepancies. This paper presents an extension of the Software and System Process Engineering Metamodel (SPEM), to be used as a new knowledge modeling layer. The approach, which is based on ontologies for knowledge representation, constitutes an explicit method for representing knowledge within process models. A concept matching indicator shows the state of the process model in terms of the concept gaps for each task within the process. This indicator could lead to more informed decision making and better management of the associated risks, in terms of team competency, documentation quality, and the training required to mitigate them.

Causes of premature aging during software development: an observational study

Much work has been done on the subject of what happens to software architecture during maintenance activities. There seems to be a consensus that it degrades during the evolution of the software. More recent work shows that this degradation occurs even during development activities: design decisions are either adjusted or forgotten. Some studies have looked into the causes of this degradation, but these have mostly done so at a very high level. This study examines three projects at code level. Three architectural pre-implementation designs are compared with their post-implementation design counterparts, with special attention paid to the causes of the changes. We found many negative changes causing anti-patterns, at the package, class, and method levels. After analysis of the code, we were able to find the specific reasons for the poor design decisions. Although the underlying causes are varied, they can be grouped into three basic categories: knowledge problems, artifact problems, and management problems. This categorization shows that anti-pattern causes are varied and are not all due to the developers. The main conclusion is that promoting awareness of anti-patterns to developers is insufficient to prevent them since some of the causes escape their grasp.

Episode measurement method: a data collection technique for observing team processes

Team effectiveness is crucial to the success of a project. It is important to measure the processes that teams perform, in order to evaluate and improve new practices. Results from a mapping study categorizing the measurement methods applied to these processes identify the most popular approaches and the need for first degree observational methods. This paper describes a data collection technique for observing team processes. A case study performed with senior students is set up to validate the method. A questionnaire was submitted to participants to identify issues related to data accuracy. Illustrative analyses demonstrate that the episode measurement method can be used to observe team process patterns. The data from the questionnaire indicate that the method does not pose as a significant threat to the internal validity of a study, and that it is useful for observing the dynamic processes in which teams engage to resolve task demands.

Are We Working Well with Others? How the Multi Team Systems Impact Software Quality.

Background: There are many studies on software development teams, but few about the interactions between teams. Current findings suggest that these multi-team systems may have a significant impact on software development projects. Aim: The objective of this exploratory study is to provide more evidence on multi-team systems in software engineering and identify challenges with a potential impact on software quality. Method: A non-participatory approach was used to collect data on one development project within a large telecommunication organization. Verbal interactions between team members were analyzed using a coding scheme following the Grounded Theory approach. Results: The results show that the interactions between teams are often technical in nature, outlining technical dependencies between departments, external providers, and even clients. Conclusion: This article hypothesizes that managers of large software project should (1) identify external teams most likely to interfere with their development work, to (2) appoint brokers to redirect external requests to the appropriate resource, and to (3) ensure that there are opportunities to discuss technical issues at the multi-team level. Failure to do so could results in delays and the persistence of codebase-wide issues.

Taxonomy for software teamwork measurement

Despite the fact that software is mostly a team endeavor, the software engineering (SE) literature has not tapped into organizational psychologys conceptual and empirical writings on teams. This paper presents a model of team dynamics adapted to the specificities of SE project teams. The taxonomy is composed of nine episodes that are likely to be found in any software team process. Each episode is described in terms of the input‐process‐output cycle and illustrated with examples. The measurability of the episodes is validated on a capstone student project carried out with an industrial partner. The team activities are recorded by each developer, throughout the projects duration, in the form of work tokens. These work tokens are then associated with episodes by two independent coders. The results show that all the episodes of the proposed taxonomy are measurable, and very few (less than 5% in this field study) remain ambiguous. Most of the ambiguities arise from short episodes that alternate during team process activities. This papers contribution to software team process research is to synthesize the team literature and draw up a theoretically driven taxonomy of team dynamics specific to SE teams and to provide initial evidence of measurability of the taxonomy. Copyright