Understanding the Requirements for Developing and Designing Open Source Software - PowerPoint PPT Presentation

Loading...

PPT – Understanding the Requirements for Developing and Designing Open Source Software PowerPoint presentation | free to view - id: 7d6c9e-MzE2M



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Understanding the Requirements for Developing and Designing Open Source Software

Description:

Understanding the Requirements for Developing and Designing Open Source Software Walt Scacchi Institute for Software Research University of California, Irvine – PowerPoint PPT presentation

Number of Views:155
Avg rating:3.0/5.0
Slides: 34
Provided by: christ1102
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Understanding the Requirements for Developing and Designing Open Source Software


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
  • Wscacchi_at_ics.uci.edu
  • UCI ISR-NSF Workshop on Continuous Design of Open
    Source Software
  • 23 September 2003
  • http//www.ics.uci.edu/wscacchi/Presentations/Wor
    kshop2003/OSS-Req-Design-Process

2
Overview
  • Research methodology
  • Open source processes for Requirements
  • Software development informalisms
  • Implications
  • Conclusions

3
Research methodology
  • Prior empirical (case) studies of Open Source
    Software Development (OSSD) Projects
  • Mockus, Fielding, Herbsleb, 2000, 2002, Apache
    httpd 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 OSSD projects in
    multiple domains
  • Such studies would offer higher degree of
    comparative analyses and generalization of results

5
(No Transcript)
6
Research methodology
  • Comparative case studies
  • Multiple open software development projects
  • Within and 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 requirementsdesign 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 formal
  • OSS Requirements/Designs are embedded within
    informalisms
  • Example OSS informalisms follow

9
(No Transcript)
10
(No Transcript)
11
(No Transcript)
12
(No Transcript)
13
(No Transcript)
14
(No Transcript)
15
Traditional vs. OSS processes for Requirements
  • Elicitation
  • Analysis
  • Specification and modeling
  • Validation
  • Communicating and managing
  • 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. OReilly Books)

19
Software Informalisms
  • Open Software Web Sites
  • Community Web sites
  • Community Software Web sites
  • Project Web sites
  • Source code Webs/Directories

20
(No Transcript)
21
(No Transcript)
22
(No Transcript)
23
Software Informalisms
  • Software bug reports
  • Ad hoc report Web
  • Bugzilla (database tracking)
  • Issue tracking
  • Issuezilla

24
(No Transcript)
25
Software Informalisms
  • Software extension mechanisms
  • Inter-application scripting
  • Csh, Perl, Python, Tcl, scripting
  • Pipelines (cf. CXCDS)
  • Intra-application scripting (e.g., UnrealScript)
  • Plug-in architectures
  • Apache server architecture

26
Software Informalisms
  • Free/OSS licenses institutionalizing F/OSS
    culture (values, norms, and beliefs)
  • GNU Public License (GPL)
  • and 35 more (http//opensource.org)
  • Creative Commons Project at Stanford Law School
    developing public license framework

27
(No Transcript)
28
Implications
  • Software informalisms are the media of software
    requirements/design
  • Software informalisms are the subject of software
    requirements/design
  • OSS requirements/design tasks are implied
    activities or capabilities
  • (Re)reading, reviewing, and reinterpreting
    informalisms is a prerequisite to writing OSS.

29
Implications
  • Developing open software requirements is a
    community building process
  • not just a technical development process
  • OSS peer review creates a community of peers
  • OSSD processes often iterate daily versus
    infrequent singular (milestone) SLC events
  • frequent, rapid cycle time (easier to improve)
    vs. infrequent, slow cycle time
    (hard to improve)

30
Implications
  • Determining the quality of OSS requirements/design
    s
  • not targeted to consistency, completeness,
    correctness
  • instead focusing attention to community building,
    freedom of expression, ease of informalism
    navigation (traceability), implicit vs. explicit
    informalism structuring

31
Conclusions
  • Developing OSS requirements is different than
    requirements engineering
  • not better, not worse, but different and new
  • more social, more accessible, more convivial
  • OSS systems dont need and probably wont benefit
    from classic software requirements engineering.

32
Acknowledgements
  • Project collaborators
  • Mark Ackerman, UMichigan, Ann Arbor
  • Les Gasser, UIUC
  • John Noll, Santa Clara University
  • Margaret Ellliot, Chris Jensen, UCI-ISR
  • Julia Watson, The Ohio State University
  • Funding support
  • National Science Foundation, IIS-0083075,
    ITR-0205679, ITR-0205724, and IIS-0350754.

33
References
  • W. Scacchi, Understanding the Requirements for
    Developing Open Source Software, IEE
    Proceedings--Software, 149(1), 24-39, 2002.
  • W. Scacchi, Open EC/B A Case Study in Electronic
    Commerce and Open Source Software Development,
    Final Report, July 2002.
  • W. Scacchi, Free/Open Source Software Development
    Practices in the Computer Game Community, IEEE
    Software, Special Issue on Open Source 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. Ramil and D. Perry (eds.), Software
    Evolution, John Wiley and Sons Inc, New York,
    2004.
About PowerShow.com