Introduction [Lewis Section 1, Part 1]
•	Definition
•	Quality assurance
•	Quality control
•	Software configuration management
•	Lewis's sample software quality assurance plan
What is Quality?
•	Producer (software developer)'s view
•	Meeting requirements
•	Want to be able to measure whether requirements are satisfied or not
•	Nonfunctional requirements: system availability, ease of modifying/maintaining
•	How would you feel if you got an assignment where you could not determine if you had done the job correctly?
•	Are we building the product correctly? -- verification
Customer's view of quality
•	Does it meets our needs?
•	Should include quality attributes
•	Nonfunctional requirements?
•	Did the developer build the correct product? -- validation
Example
•	Your younger sister asks you for a copy of the latest Harry Potter book
•	You buy and deliver the book
•	You have met the (producer) requirements
•	She reads first 10 pages, decides the book is too long
•	You have not satisfied the customer requirements
Consequences
•	Need feedback from actual users
•	Potential problems not limited to code
•	If requirements are wrong ...
Cost of quality
•	Commitment from producer (esp. management)
•	Not accepting inferior product
•	Counter-example: Dot-com era emphasis on getting online first (see "Startup.com")
•	Standards to follow
•	Ex: standard software process, standardized mechanisms for improving process
Quality assurance
•	Plan before testing starts
•	quality assurance: prevent problems
•	Ex: train developers, define project schedule, define tests
•	Includes testing, quality control, software configuration management
Quality control
•	Prevents problems like incorrect requirements, outdated manual pages
•	Monitoring process: quality control 
•	review material produced by process
•	detect and remove defects
Examples of reviewing: Reading is fundamental
•	School example: Reviewing documents for CS 4310
•	Did the group read the document all the way through before submitting it?
•	Did the group's design document cover all the requirements from the Requirements document?
•	Baseball example: autobiographies of David Wells and Sparky Lyle
Rationale for Software configuration management
•	One possible source of defects: inconsistent versions of products
•	Ex: different versions of the same class definition, of the requirements document
•	Changes often introduce new problems
•	Software configuration management : manage the different versions
Software configuration management activities
•	Component identification
•	Version control
•	Configuration building
•	Change control
Component identification
•	Need to consistently name different components and their versions
•	Ex: version 4.3 -- 4 for 4th external release, 3 is for 3rd internal version
•	Often need to place component within larger module
•	Ex: java.lang is package of basic Java classes, java.io is for input/output, java.util is for things that don't fit elsewhere
Version control
•	Record who did what to the component and why
•	Need to be able to recover earlier version
•	Any number of people can inspect component at same time
•	Only one can edit a component -- no one should be inspecting
•	[Compare with similar problems in operating systems and database management]
Configuration buildinng
•	Configuration -- "collection of software elements that comprise a major business function"
•	Need to include all necessary components
•	Determine what needs to be recompiled when one component is modified
•	Need to know relationships of components
Change control
•	Individual developers often cannot make changes on their own
•	May affect other components
•	Changes often affect multiple components -- need to group all modifications to allow proper undo if necessary
•	A frozen component cannot be changed, at least for this release
Lewis's sample software quality assurance plan (p. 15)
•	A man, a plan, a canal, Panama
•	Note wording: "defines", "identifies", "states", "details"
Sample SQA Plan document
•	Purpose: what does the plan cover?
•	What does the software do?
•	Lists all covered software items
•	What does this imply about adding a new class to your part of a project?
•	Includes portion of software lifecycle covered for each software item:
•	Know when you have to do what for each item
Sample SQA Plan document
•	References: The documents you refer to
•	Implies
•	SQA Plan must be kept synchronized with other documents
•	Should refer to other documents
•	Ex: If requirements are numbered, can identify which requirement(s) covered by a review
•	For index: index of where each requirement discussed more useful than index of terms
Sample SQA Plan document
•	Management: document members of project group
•	Who does what
The Cathedral and the Bazaar
•	http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/
•	Opposing view from Eric Raymond
•	"Cathedral": Lewis-like approach
•	Flaws:
•	massive overhead
•	still miss bugs because of limited number of tests, testers, system configurations
The Cathedral and the Bazaar (continued)
•	"Bazaar": release software "early and often"
•	Motivation: More testers --> more bugs found
•	Most bugs are relatively simple
•	Testers
•	are users
•	should not mind buggy software
•	should be "source-aware"
Comparing "Cathedral" vs. "Bazaar"
•	Goal of software engineering: better software done better
•	Bazaar has worked when requirements are known
•	Raymond states that Bazaar requires existing software
•	Most software is not completely new
Comparing "Cathedral" vs. "Bazaar" (continued)
•	Most software is not of general interest
•	Can Bazaar-produced software be for sale?
•	Most users are not programmers
•	Ex: How many real estate brokers are hackers?