2. Software Quality Engineering CS410
Class 2
Software Process Models

3. SW Process Models A process model is: A process model is not:
Methodology - 1) A body of methods, rules, and postulates (accepted theory or statement) employed by a discipline. 2) A particular procedure or set of procedures. (Webster’s 9th Collegiate Dictionary 1988)
Life Cycle - synonym for methodology
A process model is not:
Method

4. SW Process Models (cont.)
Method - A step-by-step technical approach for performing one or more of the major activities identified in an overall methodology for software development.
For example: Structured analysis and Object-Oriented analysis are both methods for carrying out the analysis phase of a software development project.

5. SW Process Models (cont.)
Common Process Models
Waterfall
Prototyping
Rapid Throwaway
Evolutionary
Spiral
Iterative
Object-Oriented
Cleanroom

6. Waterfall First attempt at controlling SW development.
Encourages requirements gathering, ordered stages, and documentation
Divide and conquer approach
Clearly defined stages
Requirements
Design
Code
Test
Maintenance

7. Waterfall (cont.) Deliverables at each stage
Entry/Exit criteria for each stage
Feedback between stages
Emphasis on documents
Waterfall model
Figure 1.2 p. 6
Figure 2.1 p. 15

8. Waterfall (cont.) Requirements Gathering/Analysis Stage
Meetings with customers
Feedback forms
Trade shows
Conferences
Internal requirements (ISO, etc.)
Requirements document is deliverable

9. Waterfall (cont.) Architectural Design Stage
Ensure operational consistency with product line(s), and standards
Architecture:
The structure of the components of a program/system, their relationships, and principles and guidelines governing their design and evolution over time.
Gross organization and control structure
Protocols for communication, synchronization, and data access

10. Waterfall Sample
Source: MS Project

11. High-Level Design (HLD)
Develop external functions and interfaces
User interfaces
Application Programming Interface (API)
System Interfaces
Inter-component Interfaces
Data structures
Design control structure
Ensure functional requirements are met

12. High-Level Design (HLD)
Ensure components fit into system/product structure (feedback to Architecture stage)
Ensure component design is complete
Ensure external functions can be accomplished (feedback to Requirements stage)

13. Low Level Design (LLD)
Identify parts, modules, macros, include files, etc. that will be written or changed
Finalize detail level of design
Verify changes in HLD (feedback to HLD)
Verify correctness/completeness of HLD (feedback to HLD)
Create component test plans (from requirements and design specs)

14. Code Stage Transform LLD into coded parts
Code modules, macros, includes, messages etc.
Create component test cases
Verify design (feedback to LLD and HLD)

15. Unit Test Stage Verify code against LLD/HLD
Execute all new and/or changed code
Branch coverage
Statement coverage
Logic coverage
Verify error messages, error handling, return codes, input parameters
May require stubs and drivers

16. Component Test
Test the combined software parts that make up a component after the parts have been integrated into a library (Configuration Management - CM)
Objective is to test:
External user interfaces (do they meet requirements)
Inter-component interfaces
APIs

17. Component Test Functionality Intra-component (module) interfaces
Error recovery
Messages
Concurrency (multi-tasking)
Shared Resources
Existing functionality (regression)

18. System-Level Test Four portions System Test
System Test, Regression Test, Performance, Usability
System Test
Test concurrency
Stress test
Test overall system stability and completeness

19. System-Level Test Regression Test Performance Test Usability Test
Test original (unchanged) functions
Performance Test
Validate performance of system/product against requirements
Record performance metrics
Establish baselines (I.e. benchmark)
Usability Test
Test for usability requirements

20. Goal of Testing Verification Validation
Verify that the system/product we built meets all of the user requirements for usability, performance, reliability, etc. Verify that the intrinsic quality is high and that standards have been met.
Validation
Validate that the requirements that drove the process were correct.

21. Waterfall (cont.) Advantages: Disadvantages:
Better than an adhoc approach
Process, requirements, entry/exit criteria, designs are all documented
Disadvantages:
Assumption that requirements will not change
Heavy emphasis on documents
Performance problems detected late in cycle
Rework is costly
Feedback is not formalized

22. Prototyping Model
Designed to deal with changing or unknown customer requirements.
A prototype is a partial implementation of the product expressed either logically or physically with all external interfaces presented.
Prototype is ‘used’ by customer to help develop requirements

23. Prototyping Model Prototyping steps: Figure 2.2 p. 20
Requirements gathering and analysis
Quick design
Build prototype
Customer evaluation
Refinement of design and prototype (and requirements)
Decision: Iterate or accept
Figure 2.2 p. 20

24. Prototyping Model Key to success: Quick turnaround and inexpensive
Throwaway Prototyping
Good for:
High-risk projects
Complex problems
Performance concerns
“quick and dirty” approach
Once customer satisfied, then development of “real thing” begins

25. Prototyping Model Evolutionary Prototyping Some requirements are known
Each iteration evolves (refines) prototype
May or may not become final product

26. Prototyping Model Advantages Disadvantages Good for interface design
Good when requirements/problem not understood
Problems detected/corrected early
Requirements refined and validated
Disadvantages
Hard to know when to stop
Could be costly
Tempting to use prototype as product (in throwaway approach)

27. Spiral Model Refinement of the Waterfall Model
Focus is on Risk Management and prototyping
Idea: A sequence of steps (cycle) is executed for each level of elaboration. A risk analysis is performed in each cycle.
Prototyping is applied to the high-risk areas
Figure 2.3 p. 23

28. Spiral Model Advantages Risk Driven Incorporates prototypes
May encourage reuse
Eliminates bad alternatives early
Incorporates maintenance
Allows for quality objectives to be incorporated

29. Spiral Model Disadvantages Immature process
Looser checkpoints (compared to Waterfall with the documents and entry/exit criteria)
Requires good understanding of Risk-Analysis and good risk driven decisions

30. Iterative Model
Idea: Start with subset of requirements and develop a subset of the product to meet these requirements. After analysis of product, iteration is done and process is repeated with new requirement subset.
Goal: Provide a system/product to user that meets evolving customer needs with improved design based on feedback and learning.

31. Iterative Model Combination of Waterfall and Prototyping
Non-iterative portion like Waterfall Model
Iterative portion like Prototyping Model
Similar to Spiral model
Key elements
Test suite developed at each iteration
Each iteration is verified and validated
Figure 2.4 p. 26

32. Iterative Model Advantages Disadvantages Complexity broken down
Problems detected early
Allows evolution of requirements
Smaller development teams
Disadvantages
Risk Analysis not formalized
Less parallelism

33. Object-Oriented Model
Paradigm shift away from data and control, to objects which incorporate both data and methods.
Eight step process (Branson and Herness)
1. Model the essential system
User view
Essential activities
Identify essential model

34. Object-Oriented Model
2. Derive candidate essential classes
Class and method selection based on the essential model identified in step 1
3. Constrain the essential model
Model must be constrained to work within the limits of the target implementation environment
4. Derive additional classes
Derive classes/methods specific to implementation environment (I.e. environmentals)

35. Object-Oriented Model
5. Synthesize classes
Organize classes into a class hierarchy
6. Define interfaces
Interfaces and class definitions are written based on the class hierarchy
7. Complete design
Complete design to include logic, system interactions, method invocations
8. Implement solution

36. Object-Oriented Model
Phases
Analysis: steps 1-2
Design: steps 3-6 (can be iterated)
Implementation: steps 7-8
Reviews are performed to enhance control of the project
Prototypes can be used for the essential model

37. Object-Oriented Model
Advantages
OO may promote higher reuse levels
Promising new technology
Works well on small projects
Disadvantages
No commonly recognized OO model
Training
Paradigm shifts
Process needs to mature

38. Cleanroom Model Statistical (mathematical) based
Based on correctness verification and incremental development
Developers must ‘prove’ designs/code rather than test designs/code
Statistical testing replaces unit testing
Figure 2.5 p. 33

39. Cleanroom Model Advantages Disadvantages
Developers are motivated to “get it right the first time” - no unit test safety net
Promises significant quality improvements
Disadvantages
All (statistical) testing is based on expected use
Learning curve, training requirements
Limited use in industry
Questions regarding scalability

40. Pop Quiz In 27 words or less:
Define:
CMM
Defect Rate
ISO 9000
Spiral Model
DPP
What are the advantages of doing a Malcolm Baldrige Quality assessment?

41. Review CMM Waterfall Model Prototyping Spiral Model
High Level vs Low Level
Unit vs Component Testing
Prototyping
Spiral Model

42. Software Quality Engineering CS410
Class 3
DPP, Process Maturity,
Quality Standards

43. Defect Prevention Process
A process for continually improving a software development process
It is not a software methodology or model
Three main steps
Analyze existing defects or errors to trace the root cause
Suggest preventative actions to eliminate the defect root cause
Implement the preventative actions

44. Defect Prevention Process
Four key elements:
Causal analysis meeting - analyze defects for each stage of the development process, identify root cause, identify prevention actions, look for trends
Action team - prioritize and implement action items
Stage kickoff meeting - level setting, emphasis on quality improvement through action items and process improvements, pitfalls identified and discussed

45. Defect Prevention Process
Action tracking and data collecting - record all problems, root causes, and actions (and action status)
DPP should be done at every stage (unlike postmortem which is at end of entire project)
DPP addresses ISO 9000 corrective action
DPP can be used with any development model, but may be more effective with some (I.e. iterative)

46. Process Maturity Frameworks and Quality Standards
Attempt to measure implementation maturity of a software development process (I.e. how well is it executed), and analyze the quality management systems in place
Capability Maturity Model (CMM)
Software Productivity Research (SPR) assessment
Malcolm Baldrige process/assessment
ISO 9000

47. Capability Maturity Model
Developed by Software Engineering Institute (SEI) at Carnegie-Mellon Univ.
A (process) maturity assessment framework
Based on 85 item questionnaire
Five levels of process maturity (p )
1. Initial
2. Repeatable
3. Defined
4. Managed
5. Optimizing

48. SPR Assessment (p. 43)
Developed by Software Productivity Research (SPR) Inc.
Based on 400 question questionnaire
Questions are rated 1-5, and overall process rating is expressed on 1-5 scale
Questions focus on
Strategic corporate issues
Tactical project issues
Quality, Productivity, Customer satisfaction

49. Malcolm Baldrige Assessment
Malcolm Baldrige National Quality Award (MBNQA) - “most prestigious quality award in the United States”
Seven categories of examination criteria
Leadership
Information and analysis
Strategic quality planning
Human resource utilization
Quality assurance of products and service
Quality results
Customer Satisfaction

50. Malcolm Baldrige Assessment
28 examination items
1000 possible points awarded
Scoring is based on three evaluation dimensions
Approach - methods used to address the item
Deployment - extent to which the approach is applied
Results - outcomes and effects
Winners need to score 70% or better to be considered
Evaluation feedback/suggestions are provided regardless of score

51. ISO 9000 International Organization for Standards
A set of standards for quality assurance
Heavy influence in Europe
Focus
Process quality
Process Implementation

52. ISO 9000 Goal - to achieve certification/registration
Formal Audit performed
Trial-runs can be performed by independent consulting firms - goal is to get feedback and suggestions
First time failures 60% - 70%
20 elements to guideline (p. 46)
Heavy emphasis on documentation (p. 47)

53. ISO 9000 ISO Focus on metrics (statistical techniques)
Product Metrics Goals
Collect data and report values on regular basis
Identify current metric performance level
Take action if performance level is unacceptable
Establish improvement goals
Process Metrics Goals
Determine if quality objectives are being met
Track adherence to process model and methods
Track defect prevention effectiveness