1 Understanding the Requirements for Developing and Designing Open Source Software Walt Scacchi Institute for Software Research University of California, Irvine Irvine, CA 92697-3425 [email protected]ISR-NSF Workshop on Continuous Design of Open Source Software 8 October 2003 http://www.ics.uci.edu/~wscacchi/Presentations/Workshop2003/OSS-Req-Design-Process
33
Embed
Understanding the Requirements for Open Source …isr.uci.edu/events/ContinuousDesign/UIUC/data/OSS-Req...1 Understanding the Requirements for Developing and Designing Open Source
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
1
Understanding the Requirementsfor Developing and Designing
Open Source SoftwareWalt Scacchi
Institute for Software ResearchUniversity of California, Irvine
server– Reis and Fortes, 2002, Mozilla Web browser– Schach et al., 2002; Holt et al., 2000, Linux Kernel– Koch and Schneider 2001; German 2002, GNOME User
Interface– Jorgensen, 2001, FreeBSD operating system– Garg et al., 2002, OSSD (“progressive open source”)
within HP
4
Research methodology• Individual case studies: significant details,
but limited (and premature) generalization,little/no comparative analysis
• No studies that examine multiple OSSDprojects in multiple domains– Such studies would offer higher degree of
comparative analyses and generalization ofresults
5
6
Research methodology• Comparative case studies
– Multiple open software development projects• Within communities, across multiple communities
• Qualitative (“grounded theory”) techniques• Analyzing and modeling
– development processes– work practices and roles– development artifacts and tools– community structures and process dynamics
7
OSS processes for Requirements• Post-hoc assertion of requirements+design
after implementation• Reading, sense-making, accountability• Continually emerging webs of discourse• Condensing and hardening discourse• Global access to this discourse
8
OSS processes for Requirements/Design
• OSS Requirements/Designs are– not explicit– not based on engineering formalisms– products of socially constructed formalities
• OSS Requirements/Designs are embeddedwithin “informalisms”
• Example OSS informalisms follow
9
10
11
12
13
14
15
Traditional vs. OSS processes forRequirements
• Elicitation• Analysis
• Specification andmodeling
• Validation
• Communicating andmanaging
• Post-hoc assertion• Reading, sense-
making, accountability• Continually emerging
webs of discourse• Condensing and
hardening discourse• Global access to
discourse
16
Software Informalisms
• Community communications– Threaded discussion forums– Email (list servers)– Newsgroups– IRChat/Instant messages– Community digests (“Kernel Cousins”)
17
Software Informalisms• Scenarios of Usage as linked Web pages
18
Software Informalisms
• How-To guides, To-Do lists, FAQs• Traditional software user documentation
– Unix/Linux man pages• External publications
– trade articles– scholarly research papers– books (cf. O’Reilly Books)
19
Software Informalisms
• Open Software Web Sites– Community Web sites– Community Software Web sites– Project Web sites– Source code Webs/Directories
20
21
22
23
Software Informalisms
• Software bug reports– Ad hoc report Web– Bugzilla (database tracking)
• Free/OSS licenses and work practices –institutionalize F/OSS culture (values,norms, and beliefs)– GNU Public License (GPL)– and more than 35 others (http://opensource.org)– “Creative Commons” Project at Stanford Law
School developing public license framework
27
28
Implications
• Software informalisms are the media ofsoftware requirements/design processes
• Software informalisms are the subject ofsoftware requirements/design processes
• OSS requirements/design processes areimplied activities or capabilities
• (Re)reading, reviewing, and reinterpretinginformalisms is a prerequisite to writing OSS.
29
Implications• Developing open software requirements and
designs is a community building process– not just a technical development process– OSS peer review creates a community of peers
• OSSD processes often iterate daily versusinfrequent singular (milestone) SLC events– frequent, rapid cycle time (easier to discover and
improve) vs.infrequent, slow cycle time (harderto discover and improve)
30
Implications
• Determining the quality of OSSrequirements/designs:– not targeted to consistency, completeness,
correctness– instead focusing attention to community
• Developing OSS requirements/design isdifferent than requirements engineering andcurrent software design techniques– not better, not worse, but different and new– more social, more accessible, more convivial
• OSS systems don’t need and probablywon’t benefit from classic softwarerequirements/design engineering.
32
Acknowledgements• Project collaborators:
– Mark Ackerman, UMichigan, Ann Arbor– Margaret Ellliot, Chris Jensen, UCI-ISR– Les Gasser, UIUC– John Noll, Santa Clara University– Julia Watson, The Ohio State University
• Funding support (no endorsement implied):– National Science Foundation, IIS#-0083075, ITR#-
#0205679, ITR#-0205724, and IIS#-0350754.
33
References• M. Elliott and W. Scacchi, Free Software Development: Cooperation and
Conflict in A Virtual Organizational Culture, to appear in S. Koch (ed.),Free/Open Source Software Development, Idea Publishing, 2004.
• C. Jensen and W. Scacchi, Simulating an Automated Approach toDiscovery and Modeling of Open Source Software DevelopmentProcesses, Proc. ProSim'03 Workshop on Software Process Simulationand Modeling, Portland, OR May 2003.
• W. Scacchi, Understanding the Requirements for Developing OpenSource Software, IEE Proceedings--Software, 149(1), 24-39, 2002.
• W. Scacchi, Free/Open Source Software Development Practices in theComputer Game Community, IEEE Software, (to appear, 2004).
• W. Scacchi, Understanding Free/Open Source Software Evolution:Applying, Breaking and Rethinking the Laws of Software Evolution,revised version to appear in N.H. Madhavji, M.M. Lehman, J.F. Ramiland D. Perry (eds.), Software Evolution, John Wiley and Sons Inc, NewYork, 2004.