Stefan Dietze
Fraunhofer Institute for Software and Systems Engineering (ISST), Mollstr. 1, 10178 Berlin, Germany
Abstract
This paper describes the agile requirements definition processes performed in open source software development (OSSD) projects. These should be considered as a reliable and viable approach to requirements definition in the area of software engineering (SE) and co-operative work in general. In the beginning, some important aspects of the entire OSSD approach are introduced in order to enable an understanding of the subsequent description of the feedback- based requirements definition processes. Therefore, important characteristics of OSS and OSSD are explained and typical roles, processes and an overall lifecycle model of typical OSSD projects is introduced. This leads to the description of the agile requirements definition processes as they are part of the software improvement process in OSSD projects. Thus, the typical requirements contribution and review processes are introduced and a typical lifecycle of the produced requirements artifact is explained.
Keywords: Agile RE processes, Open Source, Software Engineering, Software Requirements, Require- ments Engineering, Software Development, Process Model, Virtual Organization, Virtual Community
1 Introduction
Open Source Software (OSS) has reached a remarkably high popularity in many dif- ferent application domains throughout the last years. The success of famous OSS products, like the Linux Kernel or the Apache HTTPD Web Server, leads to the sug- gestion, that the development processes in general and especially the re-quirements definition processes are well suited to the demands of the users and the developers of OSS. Since the heterogeneous communities of established OSS projects typically consist of a large number of globally distributed actors who collaborate almost exclu- sively through the internet, OSS projects should be perceived as com-plex sociotech- nical systems. Whereas typical RE processes often are not designed to deal with an increasing level of complexity, heterogeneity and distribution of their organizational structures (Herlea, 1998), the collaborative OSS development methodologies seem to have overcome these issues. This suggests the hypothesis that the underlying OSS development model which obviously has the ability to produce successful software products should be considered as a reliable and viable approach in the areas of soft- ware engineering (SE) and of cooperative work in general.
This paper outlines and interprets some results of a comparative case study of OSS development processes within the Apache HTTPD, the Linux Kernel and the Mozilla project. These research activities were aimed at the identification and formal- ized specification of a descriptive process model for OSS development based on case studies which were performed by participating in the projects, analyzing the projects’
information sources, doing interviews and literature review. The research was focused
on the processes, roles, artifacts, and the deployed software infrastructure, which is
entation of a descriptive process model enable the further improvement of the identi- fied processes and its software infrastructure and furthermore open the opportunity to consider the integration of these practices into traditional software development ap- proaches.
The following describes the results of this approach and focuses on the require- ments definition processes in typical OSS environments. Section two provides back- ground information about typical characteristics of OSS and OSS development (OSSD) processes, whereas the third section introduces some important aspects of the identified OSSD process model. This leads to the explanation of the agile require- ments definition approach in OSS projects in section four. Finally, the core results of the chapter are summarized in section five.
2 Background
2.1 Open Source Software
An appropriate explanation of the open source term is provided by the Open Source Initiative (OSI), which has developed the Open Source Definition (OSD). This defini- tion contains a set of criteria that have to be considered in the software license models used for OSS in accordance with the OSD (Open Source Initiative, 2002):
• Free distribution and redistribution
• Publicly available source code
• Possibility of source code modification and redistribution
• No discrimination of certain users/groups or employment domains
All license models that follow the criteria defined in the OSD can be considered to be compatible to the understanding of OSS as defined by the OSI. In addition, the OSI provides a list of all certified software licenses (Open Source Initiative, 2003).
These characteristics have significantly determined the evolution of the entire OSS development model and especially the requirements definition processes.
2.2 Open Source Software Development
Although many existing OSS projects have successfully developed individual practi- ces and specific processes, it is possible to define some common characteristics that can be identified in most of the OSS Development projects (Cubranic, 2002; Fogel &
Bar, 2002; Gacek, Lawrie & Arief, 2002; Scacchi, 2001; Vixie, 1999).
• Collaborative development
• Globally distributed actors
• Voluntariness of participation
• High diversity of capabilities and qualifications of all actors
• Interaction exclusively through web-based technologies
• Individual development activities executed in parallel
• Dynamic publication of new software releases
• No central management authority
• Truly independent, community-based peer review
• ‘Bug driven’ development
According to Raymond (2001), these characteristics lead to the metaphor of a
‘bazaar’ that represents the characteristics of the OSS development practices in con- trast to a ‘cathedral’ representing the centralized and strictly controlled traditional software development. The OSS development processes are often characterized as
‘Bug-driven’. This results from the typical practice that every software modification is based on a specific bug report or more generally on a change request which repre- sents the central requirements artifact within the OSSD approach. This characteristic also clarifies the importance of the requirements definition processes within OSSD projects.
3 Identified OSSD process model
This section summarizes some of the key aspects of the process model which was identified during the preliminary research activities.
3.1 Key processes and roles
The initial release of the OSS prototype can be perceived as the starting point of the OSSD process as a gradual process of software improvement. The OSS approach can be divided in the following key processes:
• Management Processes
• Environment Processes
• Development Processes
Whereas the development processes describe the collaborative and highly distri- buted activities to improve the source code and to develop all projects artifacts, parti- cularly the RE artifacts, the management and environment processes support the de- velopment activities from a central position. These main development processes are executed in parallel and mainly independent from each other.
The following figure (Fig.1) represents these core process categories and the ro-
les involved in this model in an UML-based use case view:
Fig. 1. Identified key processes and roles
All collaborative development activities are performed by distributed actors who can be aggregated to the following roles:
• User
• Contributor
• Developer
• Reviewer
• Committer
These roles are not usually defined explicitly but describe a certain set of actors who fulfill a defined set of functions and tasks. A common set of characteristics can also be defined, e.g. user privileges which all actors fulfilling a certain role are asso- ciated with. Usually an actor is associated with more than one role. For example, the development of a source code as a developer implies the use of the OSS as a passive user and the submission of patches makes a developer also become a contributor.
3.2 Maintainers and Core Developers
The maintenance processes for maintaining the infrastructure and to support and co- ordinate all development activities are typically performed by a central maintainer or a maintenance committee. In fact, the initiator of the project is in most cases the same person as the primary maintainer. The maintenance actors provide central ser-vices which cannot be provided by distributed and global actors, e.g. a common software infrastructure which provides central access to all shared resources.
In many OSS projects a group of core developers could be identified (Dietze,
2003). These actors are typically responsible for the majority of source code modifi-
cations and interact very closely with the maintainer(s) of a project. Furthermore, the
core developers are often responsible for activities which require enhanced quali-
fications, skills, privileges or knowledge of the source code, e.g. the commit of source code (Mockus, Fielding & Herbsleb, 2000; Reis & Pontin de Mattos Fortes, 2002).
3.3 Overall Process Model
The overall process model at its highest level of abstraction is represented in the fol- lowing figure (Fig.2).
Fig. 2. Overall process model of the OSSD approach
The above figure contains the key processes of the OSSD process model and is pre- sented for informal purposes in order to provide a brief overview on the central pro- cesses and their relations.
After the initial development and release of the prototype, firstly, environmental and management activities have to be accomplished in order to establish a project com- munity and to setup an initial rudimentary software infrastructure, e.g. a website, a central source code repository (CVS) and a bug tracking system. These environmental and management processes are primarily executed by the maintainers of an OSS pro- ject and are necessary to enable the collaborative RE processes and all further deve- lopment processes by a distributed project community.
For means of simplification, only the requirements definition and the patch de-
velopment processes are visualized as explicit development processes since both rep-
resent the primary activities of OSS development. A very important aspect of the
distributed activities within the development processes is the fact that most processes
are performed continuously, in parallel, and mainly independent from each other by
autonomous and distributed actors. This separates the OSSD approach from any tradi-
tional SE approach and typical development practices within commercial environ-
ments.
For example, a developer who is going to develop and submit a patch acts abso- lutely independently from other developers and also from contributors who are con- tributing code change requests. The only relation between these two processes is the fact that the database of change requests is the starting point for every patch devel- opment cycle.
4 Agile Requirements Definition in OSSD
The typical process of requirements engineering in OSSD projects is based on the collaborative and iterative development of requirements artifacts within the process of gradual software improvement. These requirements artifacts (‘Change Requests’) are used to capture the requirements for all further development activities.
4.1 Scope of the OSSD requirements definition processes
As is shown in Fig. 2, the requirements definition processes are part of the process of gradual software improvement and always refer to an existing software version. The typical OSSD processes start after the release of a software prototype as OSS and are just aimed to improve and maintain this prototype. Thus, an already existing software prototype seems to be a prerequisite for the requirements definition processes which typically occur in OSSD projects. This indicates that these requirements artifacts are, in general, not appropriate to describe the requirements of entire new software pro- ducts exhaustively.
The requests which are developed in the RE processes by contributors of the dis- tributed community are aimed to describe requirements for improvement of the OSS, i.e. to remove bugs (‘Corrective Maintenance’) or to add new features to the software (‘Perfective Maintenance’). Therefore, the requirements artifacts can be divided into two categories:
• Bug Reports
• Enhancement Requests
Whereas a bug report describes an observed software bug, an enhancement re- quest defines the extension of the OSS in terms of functionality or system compatibi- lity.
4.2 Process of contributing requirements
The process of contributing requirements is performed by all actors of the community of an OSS-Project which then turn into the role of an active ‘Contributor’. Change requests are typically managed by a central bug tracking system which represents a central repository for all change requests and enables their structured description ba- sed on metadata. A popular bug tracking system is Bugzilla which was developed by the Mozilla community and is now used, e.g., for the management of change requests in the Linux Kernel
1as well as in the Mozilla
2and the Apache
3project.
1
http://bugzilla.kernel.org/
2
http://bugzilla.mozilla.org/
3