A single development task such as solving a bug or implementing a new feature often involves changing a number of entities, also known together as a change set. Change sets can be approximated from the version control system. They are then used by the architects and developers to take important decisions. So change sets need to be approximated carefully. It is common to assume that two entities checked-in less than a small time interval from each other, and having the same meta- data associated with them, belong to the same transaction. A typically applied value for the time interval is 200 seconds. Transactions may be good approximations of change sets if developers commit change sets in one go and if the required meta-data is available. This is however not the case in the industrial environment we study. In this paper we investigate how change sets can be approximated in such an environment by varying the time interval to determine a good combination of precision and recall. We found that, dependent on the commit practices used, an interval different from the standard of 200 seconds may yield better results.

Software deployment, including both clean installs and updates, is a crucial activity for all software vendors. It starts with a customer’s order of a new release and incorporates all steps taken until the customer is satisfied with the deployed product. Using interviews as the main data collection method, we did a case study of four companies to discover their software deployment activities and challenges. The study did not include COTS products but more complicated ones related to software product deployment. We noticed three product characteristics that make deployment more challenging: 1) the product is tightly integrated to other customer systems, 2) the product offers various configuration options to support different ways of working, and 3) the product requires a pre-created, complex, real-world data mode to be usable. We also noticed that software deployment is multifaceted, involving activities related to customer interaction; making integrations; and configuring, installing and testing the products.

It is now understood that software metrics alone are not enough to characterize software quality. To cope with this problem, most of advanced and/or industrially validated quality models aggregate software metrics: for example, cyclomatic complexity is combined with test coverage to stress the fact that it is more important to cover complex methods than accessors. Aggregating and weighting metrics to produce quality indexes is a difficult task. Indeed certain weighting approaches may lead to abnormal situations where a developer increasing the quality of a software component sees the overall quality degrade. Finally, mapping combinations of metric values to quality indexes may be a problem when using thresholds. In this paper, we present the problems we faced when designing the Squale quality model, then we present an empirical solution based on weighted aggregations and on continuous functions. The solution has been termed the Squale quality model and validated over 4 years with two large multinational companies: Air France-KLM and PSA Peugeot-Citroën.Ï