Farhan Aadil
COMSATS Institute of Information Technology
Lecture 16
HCI Process and Methodology
In the Last Lecture
• WIMP Interfaces
• What are Paradigms
• Paradigms of Interaction
• Paradigm shifts (example)
– Batch processing – Timesharing
– Networking
– Graphical display – Microprocessor – WWW
In Today’s Lecture
• Lifecycle Models
• Software Engineering
• Life-cycle Process Models
– Waterfall Model– RAD Model – Spiral Model
• HCI in Software Processes
– Star Life-cycle ModelLifecycle Models
• Show how activities are related to each other
• Lifecycle models are:
— management tools
— simplified versions of reality
• Many lifecycle models exist, for example:
What’s the Problem?
• Software costs are increasing as hardware costs decline.
• Many software development disasters:
– Cost overruns, late delivery
– Reduced or wrong functionality, non-existent documentation
• Many failures attributed to software
• Cost of failure becoming very high:
– Financial
Definition of Software Engineering
• Fairley’s:
– Software engineering is the technological and managerial discipline concerned with systematic production and maintenance of software products that are developed and modified on time and within cost estimates.
• Engineering versus science:
SW Engineering Is and Is Not...
• It is (or should be):
– Engineering– Building software systems – Modifying software systems
– A systematic, careful, disciplined, scientific activity
• It is not:
– Just building small systems or new systems. – Hacking or debugging until it works.
Software Lifecycle and Phases
• Stages or phases that are typical in software development, from
“birth” to “death”
• There are various different models (more later)
• Phases might include
:– Requirements phase – Specification phase – Design phase
– Implementation phase
– Integration or “testing” phase – Maintenance phase
Analogy: SE is like Construction
• Think about how buildings come to be:
– Requirements– Architecture – Construction
• Differences?
– Maintenance• Buildings don’t change much
– Design
• Buildings really are less complex
Requirements, Design, and Implementation
• Requirements
– Statements of what the system should do (or what qualities it should
have)
– From the customer or client point of view – Not expressed in terms of a solution
• Design
– A description of how we will implement a solution
– A model or blueprint for meeting requirements
– Done before implementation, so it can be evaluated
• Many possible designs for a set of requirements. How to choose?
Three Key Elements in SE
• Process
:– life-cycle model used, project management and assessment, quality assurance, etc.
• Method:
– Approaches for solving a particular problem. The “how to’s” for doing some specific task.
• E.g. object-oriented design; black-box testing; prototypes for requirements analysis.
• Tools:
– Software that supports methods and/or processes
Example: Process, Method, Tools
•
Unit testing
of code modules (before integration)
• Process: How it’s to be done? When, who, etc.?
– Documents:
• Overall SW QA Plan • Software Test Plan
– Based on design; includes test strategies, test cases, etc. for each module
– Who?
• Development team has a SQA lead
• Perhaps a department or company SQA group • Independent testers, or tested by developers?
Example: Process, Method, Tools
• Method: What approach to be used?
– Example: Black box testing• Test cases, grouped into classes
• Before testing, expected outcome is documented • After testing, did expected behavior occur?
– Example: Testing for memory leaks
• Tools: Software approach for process and methods
– Test case generator: creates test cases– Regression test environment: repeats earlier tests – Memory leak tool
– Problem reporting tool: keep problem database
Relative Cost Per Phase
6% 5%
7% 8%
Maintenance 67%
Software Development Processes
• Outline
– What’s this all about?
Life-cycle Process Models
• Process means the events or tasks a development organization
does, and their sequence
– Again, think about construction
•
Organizations
want a well-defined, well-understood, repeatable
software development process. Why?
• Find and repeat good practices
• Management: know what to do next; know when we’re done with
current task; know if we’re late; estimate time to completion, costs;
Etc.
Various Models for SW Lifecyles
• “Historical Models”
– Waterfall model – Spiral model• Government Standards
– DoD standards: 2167, 2167A
– FAA standard DO-178A, DO-178B
• Corporate “Standards” or common practices
– Many companies define their own.– Perhaps using:
Why Learn About Process Now?
• There are general principles of about:
– What we do at various stages of SW development – How to inject quality into SW
Waterfall Model
• Early, simple model
– Do the phases shown before, in order
– Complete one phase before moving on to the next
– Produce a document that defines what to do at the start of each phase – At end of each stage, a document or other work-product is produced:
requirements doc, design doc, code, etc.
– Little or no iteration (going back to previous phase)
• The order of phases/stages is generally “right”, but…
Traditional ‘Waterfall’ Lifecycle
Requirements analysis
Design
Code
Test
Activities in the Life Cycle
• Requirements specification
– Designer and customer try capture what the system is expected to provide can be expressed in natural language or more precise languages, such as a task analysis would provide
• Architectural design
– High-level description of how the system will provide the services required factor system into major components of the system and how they are interrelated needs to satisfy both functional and non-functional requirements
• Detailed design
Verification and Validation
• Verification
– designing the product right
• Validation
– designing the right product
• The formality gap
– validation will always rely to some extent on subjective means of proof
• Management and contractual issues
– design in commercial and legal contexts
Real-world requirements
Flaws of the Waterfall
• Need
iteration
and
feedback
– Things change (especially requirements)
– Change late requires change in earlier results
– Often need to do something multiple times, in stages
• As described, it’s very rigid
– Not realistic to freeze results after each phase
• The model does not emphasize important issues
– Risk managementA Quality-based View
• People who do testing and SW
Quality often re-draw the waterfall to emphasize testing activities that are not explicit in the last diagram
• Is this a model organization a
group can “follow”?
– No. It’s a big-picture view for understanding.
– A company might have a detailed standard plan (their process)
A Lifecycle for RAD
(Rapid Applications Development)
JAD workshops Project set-up
Iterative design and build
Engineer and test final prototype
Spiral Model (Barry Boehm)
• Important features:
— Risk analysis — Prototyping— Iterative framework allowing ideas to be checked and evaluated — Explicitly encourages alternatives to be considered
HCI in the Software Process
• Software engineering and the design process for interactive
systems
• Usability engineering
• Iterative design and prototyping
The Software Lifecycle
• Software engineering is the discipline for understanding the
software design process, or life cycle
The Life Cycle for Interactive Systems
Requirements specification Requirements specification Architectural design Architectural design Detailed design Detailed design Coding and unit testing Coding and unit testing Integration and testing Integration and testing Operation and Operation andlots of feedback!
A Simple Interaction Design Model
Evaluate (Re)Design
Identify needs/ establish requirements
Build an interactive version
Final product
The Star Lifecycle Model
• Suggested by Hartson and Hix (1989
)
• Important features:
— Evaluation at the centre of activities
The Star Model (Hartson and Hix, 1989)
Evaluation
Conceptual/ formal design
Requirements specification Prototyping
Usability Engineering Lifecycle Model
• Reported by Deborah Mayhew
• Important features
:– Holistic view of usability engineering
– Provides links to software engineering approaches, e.g. OOSE
– Stages of identifying requirements, designing, evaluating, prototyping – Can be scaled down for small projects
Other Process Models
• The Unified Process
– A widely-adopted process model in industry
– Originally developed by Rational (now part of IBM) – More complicated model that what we’ve seen
– Try looking for books on this with Google or at Amazon
• Many light-weight or
Agile
Process Models
– Best known example: Extreme Programming
http://www.extremeprogramming.org
Agile Process Models
• Many developers and organization feel existing process models
have been too “heavy weight”
– Too many rules and documents. Inflexible. Not fun.
• XP and many other agile methods try to be alternatives
• XP says it’s: “a deliberate and disciplined approach to software
development.” (So it is a process model.)
– Claims to be good for risky projects with dynamic requirements, and when continuous customer involvement is crucial (and possible)
– Emphasizes
Final Thoughts on Process Models
• Every organization does have a process
– Might be chaos every time– But, should be defined, documented, planned and managed
– Should be based on the nature of the projects the team is building
