Agile Requirements Definition for Software Improvement and Maintenance in Open Source Software Development

Transcription

1 Agile Requirements Definition for Software Improvement and Maintenance in Open Source Software Development Stefan Dietze Fraunhofer Institute for Software and Systems Engineering (ISST), Mollstr. 1, 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 feedbackbased 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, Requirements Engineering, Software Development, Process Model, Virtual Organization, Virtual Community 1 Introduction Open Source Software (OSS) has reached a remarkably high popularity in many different 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 suggestion, 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 exclusively through the internet, OSS projects should be perceived as com-plex sociotechnical 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 software 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 formalized 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 used to support the whole development approach. The identification and formal pres- 176 Proceedings of SREP 05, Paris, France, August 29 30, 2005 Eds. Ralyté J, Ågerfalk PJ and Kraiem N

2 Stefan Dietze entation of a descriptive process model enable the further improvement of the identified processes and its software infrastructure and furthermore open the opportunity to consider the integration of these practices into traditional software development approaches. The following describes the results of this approach and focuses on the requirements definition processes in typical OSS environments. Section two provides background 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 requirements 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 definition 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 practices 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 Proceedings of SREP 05, Paris, France, August 29 30,

3 Agile Requirements Definition in Open Source Software Development 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 contrast 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 represents 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 distributed activities to improve the source code and to develop all projects artifacts, particularly the RE artifacts, the management and environment processes support the development 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 roles involved in this model in an UML-based use case view: 178 Proceedings of SREP 05, Paris, France, August 29 30, 2005

4 Stefan Dietze 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 associated 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 coordinate 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 modifications and interact very closely with the maintainer(s) of a project. Furthermore, the core developers are often responsible for activities which require enhanced quali- Proceedings of SREP 05, Paris, France, August 29 30,

5 Agile Requirements Definition in Open Source Software Development 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 following 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 presented for informal purposes in order to provide a brief overview on the central processes 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 community 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 project and are necessary to enable the collaborative RE processes and all further development processes by a distributed project community. For means of simplification, only the requirements definition and the patch development processes are visualized as explicit development processes since both represent 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 traditional SE approach and typical development practices within commercial environments. 180 Proceedings of SREP 05, Paris, France, August 29 30, 2005

6 Stefan Dietze For example, a developer who is going to develop and submit a patch acts absolutely independently from other developers and also from contributors who are contributing 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 development 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 products exhaustively. The requests which are developed in the RE processes by contributors of the distributed 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 request defines the extension of the OSS in terms of functionality or system compatibility. 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 based 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 1 as well as in the Mozilla 2 and the Apache 3 project Proceedings of SREP 05, Paris, France, August 29 30,

7 Agile Requirements Definition in Open Source Software Development RE processes in OSSD projects are performed autonomously and independently from other processes. This is another big difference to traditional RE processes as they can be identified in proprietary (software) industries, besides the aspect that the RE process in OSSD is aimed at the gradual improvement of an already released software product. The following figure presents the activities of the requirements definition process in an UML-based activity view: Fig. 3. Activity view of requirements definition process After the identification of a certain software modification need, this software misbehavior has to be verified by the user. This is generally done by ensuring that the latest release of the OSS was installed and by subsequently trying to reproduce the modification requirement in this software version. If the bug can be reproduced or if a need for a general software enhancement can be identified, the actor reviews the existing change request repository in order to verify that the request has not already been submitted. After ensuring the novelty of the requirement, the contributor can optional- 182 Proceedings of SREP 05, Paris, France, August 29 30, 2005

8 Stefan Dietze ly communicate the request via a dedicated mailing list to the community of the project. This enables the whole community to review and discuss the request and is aimed at ensuring that the misbehavior is not specific to the system or software installation of one single actor and that no developer is already working on the implementation of this requirement. After completing this process, the contributor creates an entry in the bug tracking system and describes the change request based on structured metadata. In most projects this process is described in a guideline document, which is typically called Bug Reporting Guideline and defines the process of developing and submitting a change request. This document ensures a common understanding of this process and is used by the community as a prescriptive guide to the process, thus supporting a higher level of quality assurance by creating a consensus about how the whole requirements definition process has to be performed and which information should be provided. 4.3 Metadata of a change request As mentioned above, the change requests are captured in a bug tracking system and described using certain attributes - the metadata of a requirements artifact. This metadata information may be specific for each OSS project, but contains some generalizable attributes which exemplarily are listed below: Summary Description Keywords Status Affected Software Version Attachments Comments Owner Severity Priority The Status attribute is of special importance because it is used to document the current state of the change request thus controlling the progress of the patch development activities. The severity attribute is typically used to separate enhancement requests from bug reports by assigning the value Enhancement. 4.4 Collaborative requirements review Processes for reviewing existing change requests supplement the requirements definition processes and are mostly executed independently from the process of requirements definition. In some OSS projects these processes are also known as Bug Triage (Mockus et al., 2000; Reis & Pontin de Mattos Fortes, 2002). They are aimed to ensure a consis- Proceedings of SREP 05, Paris, France, August 29 30,

9 Agile Requirements Definition in Open Source Software Development tent, redundancy-free and always up-to-date repository of change requests. During these review activities new and unconfirmed change requests are validated, and validated change requests which are currently not in development by a specific developer are assigned. If a change request is assigned to a developer or selected for implementation by a developer himself, an individual patch development cycle, aimed at implementing the described requirement, is started. The following figure represents the requirements review process and its activities: Fig. 4. Activity view of requirements review 184 Proceedings of SREP 05, Paris, France, August 29 30, 2005

10 Stefan Dietze It is important to emphasize that these review processes are implicit processes performed voluntarily by the distributed actors, as most typical OSSD processes are. Thus, the intensity these processes are performed with is not centrally planned and a defined level of quality assurance regarding the repository of requirements cannot be guaranteed for each point of time. 4.5 Lifecycle of a change request The attribute Status is used to document the current state of an individual request. Every actor performing an activity that is related to a particular change request can make this information available to the whole community by setting the Status attribute of the change request to a certain value which describes what he is going to do. Thus, this attribute provides a very important functionality for the documentation and coordination of the patch development cycle. The following figure describes the typical states of a change request and therefore illustrates the lifecycle of this artifact which is directly related to the lifecycle of the patch that implements this request. Fig. 5. Typical lifecycle of a change request Proceedings of SREP 05, Paris, France, August 29 30,

11 Agile Requirements Definition in Open Source Software Development This information can be supplemented by setting additional attributes (Attachments, Comments) which can contain supplementary information about ongoing development activities. 4.6 Conclusion This paper has presented certain aspects of the OSSD model and explained an alternative approach of requirements definition than can be observed in typical OSSD projects. The OSSD based approach for gradual software improvement based on collaborative requirements engineering can be perceived as a promising and valuable process for software development that has been developed by users and developers of OSS in an evolutionary process throughout the previous evolution of OSSD practices. It seems to be well suited to detect the requirements of globally distributed users of a software, once a software prototype has been released. Thus, the described requirements definition process, which has already proven its ability to produce successful products, possibly has the potential to be adopted to traditional software development projects aimed at producing proprietary, closed source software and maybe also to other industries. Besides the advantages of the OSSD approach for defining requirements, this methodology still exhibits several weak points and issues. Before implementing OSSD RE practices in conventional SW development projects, these weaknesses should be considered and minimated. Therefore, a higher level of quality regarding the entire OSSD process model should be approached, which could open the opportunity to utilize general OSSD methodologies and especially the described requirements definition practices in commercial software development domains as well as in other industries. This could be achieved by the assignment of supplementary roles and tasks to core developers of an OSSD project aimed at the introduction of formal quality assurance processes into the described requirements definition approach and to make it a reliable starting point for further implementation activities. The implementation of an appropriate software infrastructure that supports these distributed processes in all of their facets could enable process automation and a high level of process autonomy and parallelism. Thus, this could provide a big benefit to further OSSD projects and could support or supplement distributed organizational structures in general. References BOEHM B, GRÜNBACHER P & BRIGGS R O (2001) Developing Groupware for Requirements Negotiation: Lessons Learned. In IEEE Software (Vol. 18). No. 3, May/June IEEE Computer Society. CUBRANIC D (2002) Open Source Software Development. Retrieved March 26, 2002 from the Wold Wide Web: DIETZE S (2003) Improvement Opportunities for the Open Source Software Development Approach and how to utilize them. In Proceedings of the NetObjectDays NODe Transit GmbH. FOGEL K & BAR M (2002) Open Source-Projekte mit CVS. MITP. GACEK C, LAWRIE T & ARIEF B (2002) The many meanings of Open Source. Retrieved May 28, 2002 from the World Wide Web: Proceedings of SREP 05, Paris, France, August 29 30, 2005

12 Stefan Dietze HERLEA D (1998) Computer supported collaborative Requirements negotiation. Retrieved October 10, 2003 from MOCKUS A FIELDING R & HERBSLEB J (2000) A Case Study of Open Source Software Development: The Apache Server. In Proceedings of the 22nd International Conference on Software Engineering. IEEE Computer Society. OPEN SOURCE INITIATIVE (2002) Open Source Definition. Open Source Initiative. Retrieved December 12, 2003 from the World Wide Web: OPEN SOURCE INITIATIVE (2003) OSI certified software licenses. Retrieved January 15, 2003 from the World Wide Web: RAYMOND E S (2001) The Cathedral and the Bazaar. O Reilly UK. Proceedings of SREP 05, Paris, France, August 29 30,