Hardware Reference
In-Depth Information
maturity models started in the 1980s by Humphrey's Capability Maturity Model
(CMM). CMMI-DEV covers 22 process areas, ranging from process improvement prac-
tices to specific development practices. Each process area is subdivided into a number
of goals, which, in turn, are structured as sets of practices. Goals and practices are asso-
ciated to process maturity levels (also called
capability levels
when they are related to a
single process area). In order to be classified at a particular maturity level, an organiza-
tion must have implemented all practices required by that level.
Given how comprehensive CMMI-DEV is, reaching its highest capability levels
represents a serious challenge for any software development organization. Clearly,
OSS communities are not an exception in this respect, and, in addition, the vast ma-
jority of them are not involved in any explicit process improvement efforts. Conse-
quently, most, if not all, OSS communities are still quite far from reaching the levels
of process discipline required by the higher levels of CMMI-DEV.
This last fact notwithstanding, there is evidence of good practices being applied in
an established and disciplined fashion by a variety of OSS communities and with re-
gard to different areas of the software development process. We think that many of
these practices correspond to the spirit, if not directly to the letter, of the practices and
goals specified by CMMI-DEV.
Some examples of such disciplined good practices, observed in prominent OSS
communities, are:
−
Version/Configuration Management:
Many OSS projects rely on advanced ver-
sioning tools for managing their source code. In most cases, access to such systems
will be carefully regulated, and the processes for creating new versions are well es-
tablished and enforced.
−
Release Management:
The GNOME Desktop project, as well as the popular
GNU/Linux distribution Ubuntu, both have strict 6-month release cycles that have
been successfully operating for years. The complex coordination process required
for each such cycle is well documented and carefully supervised and enforced by
an established release board.
−
Requirements Management:
The community behind the Python programming lan-
guage has a well-documented requirements elicitation and management process as
represented by the so-called
Python Improvement Proposals
(PIPs). Proposals for
language enhancements are presented by community members and thoroughly re-
fined through feedback from the community until they are considered ready for
implementation. The process is conducted in the open and actively enforced by the
community.
Many other similar examples can be found by directly observing the dynamics of OSS
communities. This led us to believe that, despite the inviability of applying a full-
fledged process maturity model to OSS, a process evaluation model for OSS is not
only viable, but potentially very useful in order to gauge the ability of OSS communi-
ties to consistently deliver software of appropriate quality. This belief constitutes the
main motivation for the QualOSS process evaluation framework described here.
4.2 The Generic QualOSS Process Evaluation
In its current form, our Open Source process evaluation framework covers a number
of basic software development tasks (described in more detail in the next subsection).
