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.

The poor quality of the documentation of some reused components can jeopardize the success of a project. This paper aims to assess the impact of reused components documentation quality on the effort required to complete a software evolution project and to propose a process practice to reduce the risk associated to the integration of reused components. A case study is based on data gathered from a capstone project requiring a total effort of roughly 1800 person-hours. Participant activities are self-recorded on an hourly basis. The main issues are related to imprecise and inaccurate documentation of the reused open-source components and the extra effort required dealing with these flaws. To maximize components reuse benefits, it is recommended to add a process practice enforcing early reusable components validation. This new practice would provide feedback to the software architect regarding the quality of the selected reused components.

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.

This paper presents a new automated approach to software process modeling, called DSL4SPM. It implements the Software & Systems Process Engineering Meta-model (SPEM 2.0) specification, and is characterized by: (1) a conceptual framework for designing processes in an abstract way; and (2) multi-view-oriented process modeling, which acknowledges the relevance of a multitude of issues in a process model. The conceptual framework is based on syntax provided by SPEM 2.0. The multi-view, which is defined by new semantics, focuses on the relationships among the SPEM elements. The usefulness of the approach is demonstrated with a maintenance process.

MOTIVATION: Cellular signaling networks are dynamic systems that propagate and process information, and, ultimately, cause phenotypical responses. Understanding the circuitry of the information flow in cells is one of the keys to understanding complex cellular processes. The development of computational quantitative models is a promising avenue for attaining this goal. Not only does the analysis of the simulation data based on the concentration variations of biological compounds yields information about systemic state changes, but it is also very helpful for obtaining information about the dynamics of signal propagation. RESULTS: This article introduces a new method for analyzing the dynamics of signal propagation in signaling pathways using Petri net theory. The method is demonstrated with the Ca(2+)/calmodulin-dependent protein kinase II (CaMKII) regulation network. The results constitute temporal information about signal propagation in the network, a simplified graphical representation of the network and of the signal propagation dynamics and a characterization of some signaling routes as regulation motifs.

Software processes are being increasingly taught to software engineering students. Previous studies have however shown that actual activities performed in the course of student projects differ widely from what students had been taught. This study defines a new cognitive activity classification scheme that has been used to record effort spent by six student teams producing parallel implementations of the same software requirements specification. Three of the teams used a process based on the UPEDU, a teaching-oriented process derived from the Rational Unified Process. The other three teams used a process built around the principles of the extreme programming (XP) methodology. Results show that coding-related activities dominate the effort distribution for all the teams. Also, variations in the relative emphasis put on each activity between processes are low and limited to a small number of activities. The study provides lessons that may be useful when evaluating the importance of specific software processes.

The software engineering process is a growing concern for many software development organizations. The need for well-educated software engineers is bringing new software engineering programs to universities. In many programs, software process education adds up to a few hours of lectures in an introductory software engineering course. This paper presents the structure and the content for a full, one-semester course on software processes, which has been designed in close collaboration with industry. The course is based on a software process called UPEDU (Unified Process for EDUcation), pronounced Yoopeedoo, and has been customized from the Rational Unified Process (RUP) for the educational environment. Many artifacts derived from a project case study are used as examples or templates. The content of the course is oriented towards the cognitive skills needed to perform the various activities required in the software process.

Disciplines like software engineering evolve over time by studying some practices and feeding back those results to improve the practice. The empirical approach presented in the paper is used to analyze the nature of the information shared during peer review meetings (PRMs) held in an industrial software engineering project. The results obtained show that although a PRM is categorized as a verification practice, it is also a golden opportunity for project personnel to share information about technical solutions, a decision's rationale or quality guidelines. The contribution of PRMs is not restricted to the rapid detection of anomalies; they also provide the opportunity for project team members to share implicit information. PRM efficiency cannot solely be measured through an anomaly detection rate.

The paper describes a software process that enables the measurements of team activities in a software engineering project course. Observed measurements are presented for three types of team behaviors: full team, sub team and individual. A software process is needed to guide team activities. The generic software process presented is based on IEEE standards and is derived from observing professionals and downsizing their process. It proposes some guidelines and specifies the content of five basic documents. Student team members are required to follow this process and record the time spent on each activity. Observations from these time logs are presented. Student behaviors are analyzed in terms of the time spent on various team activities and on various process activities. The concluding remarks outline salient features of a team oriented project course. This process is designed for teams of six students and can be studied in a regular, one semester session.

This paper presents an approach to the study of cognitive activities in collaborative software development. This approach has been developed by a multidisciplinary team made up of software engineers and cognitive psychologists. The basis of this approach is to improve our understanding of software development by observing professionals at work. The goal is to derive lines of conduct or good practices based on observations and analyses of the processes that are naturally used by software engineers. The strategy involved is derived from a standard approach in cognitive science. It is based on the videotaping of the activities of software engineers, transcription of the videos, coding of the transcription, defining categories from the coded episodes and defining cognitive behaviors or dialogs from the categories. This project presents two original contributions that make this approach generic in software engineering. The first contribution is the introduction of a formal hierarchical coding scheme, which will enable comparison of various types of observations. The second is the merging of psychological and statistical analysis approaches to build a cognitive model. The details of this new approach are illustrated with the initial data obtained from the analysis of technical review meetings.

Function point analysis (FPA) was initially designed on the basis of expert judgments, without explicit reference to any theoretical foundation. From the point of view of the measurement scales used in its measurement process, FPA constitutes a potpourri of scales not admissible without the transformations imbedded in the implicit models of expert judgments. The results of this empirical study demonstrate that in a homogeneous environment not burdened with major differences in productivity factors there is a clear relationship between FPA's primary components and work-effort. This empirical study also indicates that there is such a relationship for each step of the FPA measurement process prior to the mixing of scales and the assignments of weights. Comparisons with FPA productivity models based on weights confirm, on the one hand, that the weights do not add information and, on the other, that the weights are fairly robust and can be used when little historical data is available. The full data set is provided for future studies.

The use of productivity models for enhancement projects is illustrated, and the reliability of function points-based models is reported. The results of a field study at a major Canadian financial institution indicate that function points-based productivity models are within the range of the recommended criteria for good models in software engineering: a mean relative error of /spl plusmn/25% in 75% of cases.>

Abstract This paper presents a new representation of control flow graphs which is readable and concise, keeping all pertinent information as it appears in the source code. The iconic control graph provides an exact transformation of the source code. It is a basis for control flow visualization, unstructuredness identification, path crossing and path computation. The representation is programming‐language independent. The iconic control flow construction is automated.

Recent research results in software engineering have shown that the process of formalizing and automating software specification activity is moving towards knowledge-based specification systems. A modeling approach and a knowledge-based system that assist in the requirement acquisition, development, and maintenance of such software system specifications are presented.>

A new control flow graph construction is described. This control flow representation is rigorous and can be fully automated. It works for any procedural language and can be used on unstructured programs. It is designed to compute number of paths, to identify breaches of structure and to define test coverage. All existing control flow metrics can be computed from this representation and new metrics could be developed from it.>

Abstract This paper presents an approach to software assessment using a new software tool that integrates most of the known static metrics. A six‐step method shows how to use metrics to obtain a picture of the software project. The method is visual and each step provides graphical representations of the data. Successive integration of data results in normality profiles. Examples illustrate each step. The method is adaptable to various environments and specific applications.

The analysis of a distributed loop switching system with multirank buffers is based on the Markov process. The mergeability of the process is proved for a system of single-rank buffers, and generalized to systems of multirank buffers. The results for single-rank buffers are found to be in agreement with already established results. The solution for double-rank buffers, the only multirank buffer system studied in detail, is compared to the results obtained from simulation. A complete agreement is found within 5 percent, over the full dynamic range. General and normalized curves are obtained that enable us to predict the performances of double-rank buffer systems.

By studying the algebraic structure of the parity check matrix of a linear code we show that the weight distribution is a function only of the quantitiesN_{\upsilon}^{u}, the number of\upsiloncolumns of the parity check matrix with ranku. We apply this to obtain a new formula for the weight distribution of the distance3 s-ary Hamming code and for the distance4 s-ary conic code. We give the definition of a conic code and some of its properties.

Some known results on the nonexistence of linear optimal codes can be very easily proved using results on the weight distribution of such codes.