On the central role of a programmer

Barry Boehm gives in his article A View of 20th and 21st Century Software Engineering a forecast of the software engineering, describing future developments and usage of technique and tools. The implication is, that although the usage of modern techniques and tools will arise, the programmer will continue to have a central role in software production. This role has to be addressed in all efforts to improve software quality. But here exist a significant lack of techniques and tools. Often a programmer is assessed based on personnel experiences rather than on evaluated data or metrics. For this purpose the file history flow visualization offers an abstract view on the always available data, the software. It supports the analysis of a programmers activities in the past and the assessment of the quality of a programmers software artifacts.

The aspects of awareness in programmers activities

Aspect Description and possible questions
Function Distinguish the programmers role in core developer and patch contributor. Is the programmer responsible for new software features?
Productivity Assess the programmers software artifacts. Are they prone to error, vulnerable to frequent modifications or developed in a unreasonable time?
Efficiency This is meant in terms of conformance to requirements. Are all requirements fulfilled? Is more done than the requirements demand?
Fluctuation Especially in open source development fluctuation is a noteworthy problem. When core developers quit work it is advantageous to know who has worked on the same software artifacts.
Coordination Concurrence in software modifications can lead to quality problems. To avoid these, modifications have to be coordinated. So, are there modifications in the history which let assume a lack of coordination?
Motivation Sometimes it is possible to have involved some developers with a bad faith. Are there periodic activities that impact the software quality or get fixed in later versions?

Available Information

Dependent on the project there are more or less data that could be analyzed.

Repository of a version control system
Version content and/or meta data (commit data).

Database of a bug tracking tool
Generally used to refine the repository analysis.

Communication (email etc.)
Also combined with other data like the meta data of the repository.

Since the focus of the file history flow visualization is on the software artifacts of the programmers, a detailed analysis of the content is necessary. Therefore, and because the Concurrent Version System (CVS) is very well integrated in Eclipse, the file history flow visualization is in the first instance developed to work with CVS. But this doesn't exclude other version systems. The visualization is based on the File History API of Eclipse. I.e. all repositories that supports this API can be used.