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.

The current empirical literature suggests that discrepancies between software design artifacts and implementation seems inevitable. The goal of this empirical study is to understand the nature and impact of these discrepancies by a detailed analysis of the design and code artifacts. The case study is based on an object-oriented software development project based on a traditional plan-driven software development process and proposed by an industrial collaborator. Case study results show that the code written is based on different sources. Software components can be created from scratch, added after design, adapted from the redesign of a reused component or implemented from the modification of an existing component. It is found that code components based on design artifacts are indeed victims of erosion once implementation begins. This erosion can be linked to the evolution of the team members' project understanding during implementation. However, the study concludes that this evolution is mostly opportunistic and does not necessarily warrant an evolution toward amelioration. This study proposes a quality control practice based on the category of the implemented components.

ABSTRACT Despite the fact that software is mostly a team endeavor, the software engineering (SE) literature has not tapped into organizational psychology's 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 project's 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 paper's 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 © 2014 John Wiley & Sons, Ltd.

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.

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.

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.