Ch6 HCI in software process 
	Software engineering
	Systems Analysis and Design
	Use-ability engineering
	Iterative design
	Design rationale

Section 1: look at the PROCESS of design
	(all stages, all activities)

Section 2: software life cycle
	Designer, customer, end user
	Waterfall vs agile
	
	Requirements specification
		(what system should do, and how)
		Functional requirements—what
		Non-functional requirements—constraints, standards
	Architectural design
	Detailed design
	Coding, unit testing
	Integrate and (system) testing
	Maintenance

	Validation and verification
		(not a math proof)
		Use-ability often known only after the fact
	Management and contract issues
		Marketability of a system
		Its training needs
		Availability of skilled personnel
		Subcontractors
		Other issues
		Life cycle in phases
		Management goes in time schedules
		Contracts go by contract law
	Original systems were not (very) interactive
		Estimate at least 50% of development time spent on interface
		Lack of predictive psychology : need to observe users
		BUT how can you observe users with system, when system not designed yet?
		Mockup, prototype, interface

Section 3: use-ability engineering
	Much focus interface
	But deeper aspects essential for use-ability
	
	Example: backward recovery of VCR
		Measuring concept: UNDO
		Number of steps to undo
		(current level: no product allows)
		Worst case: as many actions as programming it correctly
		
		Planned level: max 2
		Best case: one cancel action
		
		Need empirical approach
			User performance is ultimate goal
			Not necessarily the best way to go
			Example: assume ‘undo’ needed;
				Did we discuss how to keep error from occurring in first place?
			Satisfy use-ability specifications
				<>use-ability
			Why/how does (use-ability measure)
				Enhance use-ability for real people?

	Section 4: iterative design and prototyping
		Mockup
		Animation
		Simulation
		Prototype
		Throw away
			(Visual Basic then C)
		Incremental
			(add modules; functions)
		Evolutionary
			(prototype changed into system)
		Realism is important but costly
			(wasted effort on polish before concept)
		Often have limited functionality for evaluation
		Problems:
			Time
			Planning
			Non-functional often sacrificed or ignored in prototype
			
			Prototype cannot be basis of legal contract
Techniques
	Storyboard
	Limited functionality
	Wizard of oz functionality
	High level programming support
Problems
	An early decision
		Can be bad but has inertia
	Need to understand reason and not just system
	(12 vs 24 clock)

Section 5 design rationale
	Both reflection and documentation throughout SDLC
	Good to have:
		Communication
		Transfer knowledge to their situation
		Effort requires careful deliberation
	Important
		No single best alternative (tradeoffs)
		Unlikely to discover the best solution
		later identify why a decision was made
		usability depends on context
	design rationales can be:
		process oriented (historical)
			root issues and arguments
		design decision (choices made)
			questions and decisions
		user focus (psychology)
			new system supports more than designers intended
			Visi-Calc (spreadsheet) was for tabular computations
			Word processor was to enhance productivity of typists
			Ask
				What can I do?
				How does it work?
				How can I do this?
			Make changes on how use naturally evolves
		Other issues
			Alter process or document
			Cost of using
		Computational power and tools needed