1
Dec 15, 2015
1
2
Software Quality EngineeringCS410
Class 2
Software Process Models
3
SW Process Models
• A process model is:– 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, Regression Test, Performance, Usability
• System Test– Test concurrency– Stress test– Test overall system stability and completeness
19
System-Level Test• Regression 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– 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:
– 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:– 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
– 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– 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– 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 QuizIn 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– High Level vs Low Level– Unit vs Component Testing
• Prototyping
• Spiral Model
42
Software Quality EngineeringCS410
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 Frameworksand 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. 40-41)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– (standards 9000, 9001, 9002, 9003)
• 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