Topics For Final (1) � everything from before the midterm • outline posted in midterm review slides � Architectural Styles • 5 styles discussed: • pipe & filter • layered • implicit invocation (event based) • repository & blackboard • object-oriented • be able to explain each, give examples of use • compare & contrast • given problem, choose appropriate style & justify CISC 323, winter 2003, software quality 1
Topics For Final (2) � Software Quality • dimensions of qualty • inspection • how it works in general, not picky details • advantages • how it fits into software processes • testing • black box, white box • white box: statement, branch, path coverage • unit, integration, system testing • regression testing • other kinds: performance, usability, stress, etc. CISC 323, winter 2003, software quality 2
Notes About Open-Source Software � taken from "The Cathedral and the Bazaar" � author: Eric Steven Raymond � http://www.catb.org/~esr/writings/cathedral-bazaar/ � also published as a book with other essays CISC 323, winter 2003, software quality 3
Cathedral vs. Bazaar � Cathedral: carefully planned by small group, plans carried out under strict supervision � Bazaar: very informal, minimum of management and central planning CISC 323, winter 2003, software quality 4
How Open-Source Software Starts � Small number of "core developers" (often 1) � Need to start with an initial version / prototype � May be an adaptation of another system � May be buggy and incomplete � It must have some basic functionality working � Needs to be enough to get others interested in participating � Important to have a coordinator with good people skills � Internet is crucial CISC 323, winter 2003, software quality 5
How It Works � advertise the program, recruit participants � encourage users to become contributors � works best when many users are software developers � uses version-control system: • central library of source code – multiple modules • contributors can "check out" code independently • user makes a change to a module: checks changed version back in – identified as new version, old version is still there • key safeguard: you can always go back to older version if a contributor breaks something CISC 323, winter 2003, software quality 6
Raymond's Experience � had worked on small open-source projects � believed that large, complicated systems needed the cathedral style � encountered Linux: large, complex system (operating system and much other associated software) – all very loosely managed – and it worked! � managed a project to develop new Linux e-mail program � used this project partly as a study of Linux style of development CISC 323, winter 2003, software quality 7
Raymond's Lessons: 1 Every good work of software starts by scratching a developer’s personal itch. � Restated later as Lesson 18: To solve an interesting problem, start by finding a problem that is interesting to you. CISC 323, winter 2003, software quality 8
Raymond's Lessons: 2 Good programmers know what to write. Great ones know what to rewrite (and reuse). CISC 323, winter 2003, software quality 9
Raymond's Lessons: 6 6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging. "The power of this effect is easy to underestimate. In fact, pretty well all of us in the open-source world drastically underestimated how well it would scale up with number of users and against system complexity, until Linus Torvalds [creator of Linux] showed us differently." CISC 323, winter 2003, software quality 10
Raymond's Lessons: 7 & 8 7. Release early. Release often. And listen to your customers. 8. Given enough eyeballs, all bugs are shallow In other words, “Debugging is parallelizable”. CISC 323, winter 2003, software quality 11
Raymond's Lessons: 10 & 11 10. If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource. 11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better. CISC 323, winter 2003, software quality 12
Raymond's Lessons: 19 Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one. CISC 323, winter 2003, software quality 13
Netscape/Mozilla � a major use of the open-source methodology � Raymond's reasons why it wasn't more of a success: • not easy for potential contributors to compile & run source (needed license for Motif library) • not well-defined goals • basic software engineering problems: open-source approach doesn't fix these magically! CISC 323, winter 2003, software quality 14
Recommend
More recommend
