SOFTWARE QUALITY
CPTS 583
Midterm exam review
1
Logistics
• Proctoring
• Zoom
• Time
• Lecture time
• Thursday, March 4
• GC students: schedule with me if needed
• Setting
• Close-book
• Cheat sheets: two sheets / both sides
2
Exam format
• Total: 100 points
• Composition
• 10 essay questions, 5 pts each
• 4 more sophisticated essay questions, 8 pts each
• 1 analytics question, 8 pts
• 1 computation question, 10 pts
• Grading guidelines
• Essay questions
• Rationale/main idea
• Justification
• Analytics and computation questions
• Steps
• Results
3
What is software quality?
• Software
Computer programs, procedures, and possibly associated
documentation and data pertaining to the operation of a
computer system. (IEEE definition)
4
What is software quality?
• Software quality
By IEEE:
(1) The degree to which a system, component, or process
meets specified requirements.
(2) The degree to which a system, component, or process
meets customer or user needs or expectations.
5
Software quality perspectives
• Different roles
Consumer
Third party/indirect users
Generalized users
Software quality perspectives
Various perspectives:
- Customer : Complete requirements (Functional and non
functional)
- Project manager: Cost and schedule
- Maintenance engineer: Detection and correction times
Quality perspective
• Vary with different software
General-purpose system
(functionality)
End-user / Web / GUI
applications
(usability)Embedded software
(interoperability)
Safety-critical systems
(safety, reliability)
What is software quality?
• Six characteristics (as per ISO/IEC 9126)
9
What is software quality?
• Six characteristics (as per ISO/IEC 9126)
10
Software quality: scope
Software quality engineering (SQE)
Software quality assurance
(SQA)
Software testing
11
Software correctness
• High quality -> few defect
• Defect
• Error – Fault – Failure
• Correctness: an attribute of Quality
Error—a quality problem found before the software is released to
end users
Fault/Failure—a quality problem found only after the software has
been released to end-users
Software correctness
Software correctness
The nine causes of software errors are:
1. Faulty requirements definition
2. Client-developer communication failures
3. Deliberate deviations from software requirements
4. Logical design errors
5. Coding errors
6. Non-compliance with documentation and coding
instructions
7. Shortcomings of the testing process
8. User interface and procedure errors
9. Documentation errors
Quality assurance
• Quality assurance (QA)
• Focus - correctness
• What - Dealing with defects
• When - Earlier the QA, lower the cost
• Post-release versus pre-release
SQA is:
(1). A planned and systematic pattern of all
actions necessary to provide adequate
confidence that an item or product conforms to
established technical requirements.
(2). A set of activities designed to evaluate the
process by which the products are developed or
manufactured. Contrast with quality control.
Quality assurance
• How?
• How to deal with defects?
Prevention
Removal
Containment
Quality assurance
Software Quality Management
Quality Planning
Quality Assurance
Quality Control
Quality Management Activities
• Quality planning
• selecting and modifying applicable quality standards
and procedures for a particular project
• Quality assurance
• establishing organizational quality standards and
procedures
• Quality control
• ensuring quality standards and procedures are
followed by development team
Quality Management Activities
Quality Management along the way
• The quality of a developed product is influenced by the
quality of the production process
• Particularly important in software development as some
product quality attributes are hard to assess
• Relationship between software processes and product
quality: complex yet poorly understood
Process and product quality
Process-based quality
Elements of a software quality plan
✓Product/process introduction/description
✓Quality goals
✓Review activities
✓Tests
✓Configuration tools/procedures
Quality Goals
❑ Quantitative measures usually preferred to qualitative
measures when choosing goals
❑easier to assess objectively during testing.
❑ Quality goals should reflect the major acceptance
criteria found in the requirement’s document (i.e. RFP)
❑correctness, reliability, robustness, maintainability….
❑ RFP is often used to measure successful achievement of
the customer’s quality requirements.
Quality planning in practice
• Preparing plans can be a hassle
• Too many
• Too bureaucratic
• Agile versus heavy-weight planning
• Avoid being “plan-centric”
• Heavy-weight plan may be unnecessary or infeasible
Quality planning for small projects
• A project of short duration (e.g., 10 days)
• A project to be worked on by a small team (e.g., 3
professionals)
• A project that would not cost much even timeline failed to
be observed
• ……
Quality planning for small projects
• Simplified/reduced quality plan
• Quality goals
• Reduction is NOT dismissal
• Advantages of quality planning
• Even for small projects!
Cost of software quality
• Balancing cost and quality
Cost of software quality
• Why should we estimate the cost?
• Put the quality cost under control
• Plan and manage budget
• Adjust quality assurance methodology and/or plan
Cost of software quality
• What are the costs?
Traditional Costs of Quality (CoQ)
• Cost of defect prevention
• E.g., process improvement, root-cause analysis, training, etc.
• Cost of defect detection
• E.g., inspection, testing
• Cost of failures
• Internal (pre-release)
• External (post-release)
15-40%
Cost of software quality
• What are the costs?
Costs of Software Quality (CoSQ)
• CoQ
• Defect Detection -> Appraisal
• Additional costs specific to Software quality
• Managerial control costs
• Managerial failure costs
CoSQ model
Cost of
software
quality
Prevention costs
Appraisal costs
Internal failure costs
External failure costs
Control
costs
Failure of
control
costs
Managerial control
costs
Managerial failure
costs
Good quality
Bad quality
Software Cost Estimation
• COCOMO (COnstructive COst MOdel)
• To tune software process (lifecycle practices)
• To support continuous model improvement
• Different levels of detail and accuracy
Early in project
After requirements
After design
Software Cost with COCOMO
• Different modes for various development settings
1. Organic mode
• Low complexity, high flexibility
2. Semi-detached mode
• Intermediate complexity, mostly less rigid requirements
3. Embedded mode
• High complexity, tight constraints
Software Cost with COCOMO
• Effort (in Man Months)
• Development time (in months)
E = a(KDSI)b * EAF (MM)
Thousand (K) lines of Delivered
Source Instructions
Effort Adjustment Factor
D = c(E)d (months)
The McCall quality factor model
Software quality factors
Product operation factors
Product revision factors
Product transition factors
The McCall quality factor model
Trading off between factors
• 11 factors
• All to be considered
Usability
Efficiency
Usability
Efficiency
Trading off between factors
• Factors with (negative mutual) influence
Correctness
Reliability
Efficiency
Integrity
Usability
Maintainability
Flexibility
Testability
Portability
Reusability
Interoperability
Correctness
Reliability
Efficiency
Integrity
Usability
Maintainability
Flexibility
Testability
Portability
Reusability
Interoperability
Trading off between factors
• Factors with (positive mutual) influence
Correctness
Reliability
Efficiency
Integrity
Usability
Maintainability
Flexibility
Testability
Portability
Reusability
Interoperability
Correctness
Reliability
Efficiency
Integrity
Usability
Maintainability
Flexibility
Testability
Portability
Reusability
Interoperability
Trading off between factors
• Tradeoffs between conflicting factors
In practice:
--- prioritization
--- compromise
State of the art:
--- modeling and tracking
--- creating facts & knowledge
McCall
Boehm’s model
Level I
characteristics
Level II
characteristics
Level III
characteristics
ISO/IEC 9126
✓✓
✓
✓
CMM
• Capability Maturity Model (CMM)
CMM

欢迎咨询51作业君