|April 1, 2012||Donated by Audris Mockus|
|April 1, 2012||AudrisMockus am1 ported to repo v4|
Audris Mockus. Software support tools and experimental work. In Empirical Software Engineering Issues: Critical Assessments and Future Directions, pages 91-99. Springer LNCS, 2007
There a common type of dataset generated by virtually any software project. Better understanding of software projects can lead to actual improvements on how software is created, presenting the state and history of projects can improve project management by preventing the lest rational, but, unfortunately, too common management decisions.
Data description contains three parts: # Files and formats # Explanation of individual fields # Domain background
The data has a number of features and dependencies that are too numerous to describe.
|mrs||header and records all semicolon separated|
|mrs.xml||data in the ggobi XML format|
|mrs.txt||header and records all tab separated. Character strings were converted to integers (see mrs.xml for the mapping between integers and strings they represent.) Some stat/vis packages prefer only numeric data, so this file was created to facilitate analysis.|
Please note that MRs that are submitted to several software releases appear several times in the table below, with all attributes repeated except for the release name.
Problem tracking (PR) and version control systems (VCS) are used by virtually all software projects to coordinate the work of the project participants and to allow parallel work on several releases and patches. This dataset is a typical example of the data that is usually available from VSC and PR systems.
A slightly simplified version of an MR process follows. The developers are assigned a new feature or a defect to work on. In case of defects, they investigate the problem, make necessary changes and submit an MR for integration. In case of new features, additional tasks such as low level design and design review are performed prior to coding. After coding is complete the MR is submitted for integration by the developer. The code inspection is done afterward and any issues are resolved with additional MRs. If an MR is opened by a tester, it may take some time until someone is assigned to work on it and eventually starts working on it. In this case the MR open time may significantly precede the time when the work started. Often developers will find an issue to work on in the regular course of their activities. They may investigate the issue, complete the necessary changes in their private workspaces, and then open and immediately submit an MR for integration. In this case opening an MR does not precede the start of work.
There are three basic questions in software projects:
More specifically, how to show and summarize the quality, the current state, and the effort that went into a software release, or a build, or a system.
What is the relationship (over time, because there is no direct relationship data) between MRs.