Topics For Final (1) Topics For Final (2) everything from before - PowerPoint PPT Presentation

Topics For Final (1) Topics For Final (2) � everything from before the midterm � Software Quality • outline posted in midterm review slides • dimensions of qualty � Architectural Styles • inspection • 5 styles discussed: • how it works in general, not picky details • pipe & filter • advantages • layered • how it fits into software processes • implicit invocation (event based) • testing • repository & blackboard • black box, white box • object-oriented • white box: statement, branch, path coverage • be able to explain each, give examples of use • unit, integration, system testing • compare & contrast • regression testing • given problem, choose appropriate style & justify • other kinds: performance, usability, stress, etc. CISC 323, winter 2003, software quality 1 CISC 323, winter 2003, software quality 2 Notes About Open-Source Software Cathedral vs. Bazaar � taken from "The Cathedral and the Bazaar" � Cathedral: carefully planned by small group, plans carried out under strict supervision � author: Eric Steven Raymond � Bazaar: very informal, minimum of management and central � http://www.catb.org/~esr/writings/cathedral-bazaar/ planning � also published as a book with other essays CISC 323, winter 2003, software quality 3 CISC 323, winter 2003, software quality 4

How Open-Source Software Starts How It Works � Small number of "core developers" (often 1) � advertise the program, recruit participants � Need to start with an initial version / prototype � encourage users to become contributors � May be an adaptation of another system � works best when many users are software developers � May be buggy and incomplete � uses version-control system: � It must have some basic functionality working • central library of source code – multiple modules � Needs to be enough to get others interested in participating • contributors can "check out" code independently � Important to have a coordinator with good people skills • user makes a change to a module: checks changed version back in – identified as new version, old version � Internet is crucial is still there • key safeguard: you can always go back to older version if a contributor breaks something CISC 323, winter 2003, software quality 5 CISC 323, winter 2003, software quality 6 Raymond's Experience Raymond's Lessons: 1 � had worked on small open-source projects Every good work of software starts by scratching a developer’s personal itch. � believed that large, complicated systems needed the cathedral style � encountered Linux: large, complex system (operating � Restated later as Lesson 18: To solve an interesting system and much other associated software) – all very problem, start by finding a problem that is interesting to loosely managed – and it worked! you. � 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 CISC 323, winter 2003, software quality 8

Raymond's Lessons: 2 Raymond's Lessons: 6 Good programmers know what to write. Great ones know 6. Treating your users as co-developers is your least-hassle what to rewrite (and reuse). 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 9 CISC 323, winter 2003, software quality 10 Raymond's Lessons: 7 & 8 Raymond's Lessons: 10 & 11 7. Release early. Release often. And listen to your customers. 10. If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource. 8. Given enough eyeballs, all bugs are shallow 11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better. In other words, “Debugging is parallelizable”. CISC 323, winter 2003, software quality 11 CISC 323, winter 2003, software quality 12

Raymond's Lessons: 19 Netscape/Mozilla Provided the development coordinator has a communications � a major use of the open-source methodology medium at least as good as the Internet, and knows how to � Raymond's reasons why it wasn't more of a success: lead without coercion, many heads are inevitably better than • not easy for potential contributors to compile & run one. 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 13 CISC 323, winter 2003, software quality 14