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

CISC 323, winter 2003, software quality 1

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 2

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 3

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 4

Cathedral vs. Bazaar

Cathedral: carefully planned by small group, plans carried

• ut under strict supervision

Bazaar: very informal, minimum of management and central planning

CISC 323, winter 2003, software quality 5

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 6

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 7

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 8

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 9

Raymond's Lessons: 2

Good programmers know what to write. Great ones know what to rewrite (and reuse).

CISC 323, winter 2003, software quality 10

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 11

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 12

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 13

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

• ne.

CISC 323, winter 2003, software quality 14

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!