*   International Standards Organization (ISO)
    suggests that software QUALITY comprises 6 main
    attributes:
    *   functionality
    *   reliability
    *   usability
    *   efficiency
    *   maintainability
    *   portability

    *   there isn't likely to be a single number
        for quality --

	SOMETIMES people consider reliability
	a "main" attribute of quality,
   
        and try to use failure rates of various
	types to measure reliability and
	thus in one sense quality;

        *   e.g., one approach to measure quality
	    is, after delivery,
	    log the defects found for 6 months/1 year/etc.
	    and define quality with respect to that
	    data

        *   so, sure, there are MANY confounding issues
            with this -- what's a defect? how many initial
	    users were there? etc.

	    BUT, a goal of reducing the defects
	    per KLOC (1000 lines of code) can be
	    an interesting objective;
     
    *   (and note: maintenance costs tend, over the life
        of a software system, to FAR EXCEED the cost
	of original development)
        *   variously suggested as 80:20, 70:30, 60:40

*   Chapter 2 --

    we are especially interested in some classic
    software development process models:
    *   waterfall
    *   prototyping
    *   iterative
    *   RUP (Rational Unified Process)
    *   timeboxing
    *   agile/extreme programming/etc.

    *   a process model is essentially a compilation
        of best practices into a "recipe" for
	success in a project;

	BUT!! one often adapts, even combines, pieces
	from different models to come up with the
	process actually used in a given project;

    *   a process model specifies a general process,
        usually as a set of STAGES into which a project
	   should be divided,
        the ORDER in which the stages should be executed, and
	any other CONSTRAINTS or CONDITIONS on the
	stages of execution;

*   going over these "classic" models a bit:

*   WATERFALL
    *   conceptually the simplest
    *   roughly a linear progression --
        requirements -> design -> coding -> testing -> delivery

    *   ...with specific ARTIFACTS resulting from
        each stage;

    *   very widely used -- and derided;

        (but it IS suitable for well-understood problems)

*   PROTOTYPING
    *   one or more NOT-FINAL-DELIVERABLE prototypes
        are built to help DETERMINE/IMPROVE the
	requirements --
	...THEN you proceed in  waterfall-like
	approach from there