New version page

Understanding the Requirements for Developing and Designing Open Source Software

Upgrade to remove ads

This preview shows page 1-2-17-18-19-36-37 out of 37 pages.

Save
View Full Document
Premium Document
Do you want full access? Go Premium and unlock all 37 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 37 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 37 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 37 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 37 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 37 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 37 pages.
Access to all documents
Download any document
Ad free experience

Upgrade to remove ads
Unformatted text preview:

Understanding the Requirements for Developing and Designing Open Source SoftwarePowerPoint PresentationSlide 3Slide 4Slide 5OverviewResearch methodologySlide 8Slide 9Slide 10OSS processes for RequirementsOSS processes for Requirements/DesignSlide 13Slide 14Slide 15Slide 16Slide 17Slide 18Traditional vs. OSS processes for RequirementsSoftware InformalismsSlide 21Slide 22Slide 23Slide 24Slide 25Slide 26Slide 27Slide 28Slide 29Slide 30Slide 31ImplicationsSlide 33Slide 34ConclusionsAcknowledgementsReferences1Understanding the Requirements for Developing and Designing Open Source Software Walt ScacchiInstitute for Software ResearchandLaboratory for Computer Game Culture and Technology University of California, IrvineIrvine, CA 92697-3425 [email protected]://www.ics.uci.edu/~wscacchi/Presentations/Workshop2003/OSS-Req-Design-Process23456Overview•Research methodology•Open source processes for Requirements•Software development informalisms•Implications •Conclusions7Research 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 HP8Research 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 results910Research 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 dynamics11OSS 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 discourse12OSS processes for Requirements/Design•OSS Requirements/Designs are –not explicit–not formal•OSS Requirements/Designs are embedded within “informalisms”•Example OSS informalisms follow13141516171819Traditional 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 discourse20Software Informalisms•Community communications–Threaded discussion forums–Email (list servers)–Newsgroups–IRChat/Instant messages–Community digests (“Kernel Cousins”)21Software Informalisms•Scenarios of Usage as linked Web pages22Software 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)23Software Informalisms•Open Software Web Sites –Community Web sites–Community Software Web sites–Project Web sites–Source code Webs/Directories24252627Software Informalisms•Software bug reports –Ad hoc report Web–Bugzilla (database tracking)•Issue tracking–Issuezilla2829Software 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 architecture30Software 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 framework3132Implications•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.33Implications•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)34Implications•Determining the quality of OSS requirements/designs:–not targeted to consistency, completeness, correctness–instead focusing attention to community building, freedom of expression, ease of informalism navigation (traceability), implicit vs. explicit informalism structuring35Conclusions•Developing OSS requirements is different than requirements engineering–not better, not worse, but different and new–more social, more accessible, more convivial•OSS systems don’t need and probably won’t benefit from classic software requirements engineering.36Acknowledgements•Project collaborators: –Mark Ackerman, UMichigan, Ann Arbor –Les Gasser, UIllinois, Urbana-Champaign–John Noll, Santa Clara University–Margaret Ellliot, Chris Jensen, UCI-ISR–Julia Watson, The Ohio State University•Funding support:–National Science Foundation, ITR#0083075, ITR#0205679, ITR#0205724, and ITR#0350754.37References•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, January-February, 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,


Download Understanding the Requirements for Developing and Designing Open Source Software
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Understanding the Requirements for Developing and Designing Open Source Software and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Understanding the Requirements for Developing and Designing Open Source Software 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?