CSE350 Software Design and Engineering

1. CSE350 Software Design and Engineering University of Pennsylvania http://www.cis.upenn.edu/~jms Office: 254 Moore GRW, Phone: 8-9509 April 2nd, 2002

2. Administrative: Lectures • Today: Development methods wrap-up • 4/9: Engineering Trustworthy Software • 4/16: Wrap-up of semester (summary)

3. Classical Software Engineering • Carefully scoped out requirements • Performed within a single organization • Goal: deliver a “software product” • May use hierarchy (such as “Chief Programmer Teams” of Brooks) • Steps: %effort %life • Design 33.3% 3.3% • Implement (Code) 16.7% 1.7% • Test 50% 5% • Deploy • Maintain 90%

4. Strengths of Classical Software Engineering • Process resembles other engineered systems • Can apply formal methods: program correctness • Can make (very rough) resource estimates • Clear interfaces to management; clear lines of responsibility • Can define many specialized models to achieve these steps: spiral, cleanroom, waterfall, etc. • Considerable industrial experience, e.g. at pre-breakup AT&T

5. Weaknesses of Classical S.E. • Communications cost avoidance (specialization + hierarchy) means best ideas may not come out • Management often at fault for failed projects • Managers either not chosen with technical expertise, or • Chosen for technical expertise, not management • Too slow to correct big errors • Like many industrial processes, workers may not be interested, motivated or competent • In software, this really matters: most productive people are multiplicatively (5-100?) times more productive

6. Distributed Development with Open Source: Unix + Hackers + Networks • Source code allows deep understanding • Read good code -> write good code • Importantly, it allows tinkering • uucp – Unix to Unix copy • Powerful overlay of telephone network • Used to architect the “USENET” / netnews: on-line communities • BSD variant of Unix funded by DARPA • ARPAnet connectivity for Universities • Good networking support • BSD distribution under agnostic (non-GPL) terms

7. “Open Source” methodology • Available source code plus a common code base meant that modifications could be shared – just recompile • Subset of on-line community in addition to academics and foodies: hackers • Networked hackers share all sorts of source code • Broadcast changes – the interested react • Programmer skills differences exploited (top 5%?) • Parallel debugging and testing (auditing) • Add WWW to net, get a new O.S.: Linux

8. The Open Source Community at Present All working roughly the same problem Level of maturity is high Well established community Open source development model works - the “products” actually run and run well Security awareness in very high The base technology is relatively stable, but moldable (for now) Community is motivated by success Constraints of market share and ROI are secondary motivators (at best – love not money?)

9. Open Source is not a “silver bullet” • “… As an experiment I also planted a comment which should raise eyebrows in some code I released years ago and which is fairly widely used just to see if I’d get any reaction from anyone (the comment says, in effect, ”Something really suspicious could happen here”, although that’s not the real text so you can’t just grep for it to find it :-). Noone has ever asked me about this, from which I assume that noone’s ever looked at the code they’re using. That’s kind of scary, because the comment isn’t in there just to annoy people, you really could build a rather nasty backdoor in there. There may actually be products out there which are released in binary-only form where the vendor has built in a backdoor at that point, although I saw a posting from foo@anon.org in alt.2600 saying he’d looked at the product and it was fine, so it must be OK.” – Peter Gutmann, on Peter Neumann’s “Robust Open Source” mail exploder

10. An interesting quandary regarding “Love vs. Money” • How do programmers get paid? • Should companies produce open source software? • What about notions of “intellectual property” • Should software be an industry or should it just be an auxiliary activity to systems that use software? • Will there be a commercial marketplace?

11. A prediction (sure to be wrong!) • There *is* a software marketplace • The market is a distributed decision-making mechanism that uses price as a signalling technique • The main role of open source software is to provide diversity and police commercial vendors into providing a better quality/$ product • Microsoft is already doing this, with recent announcements by Bill Gates that “Security is Job #1” 