Professional Documents
Culture Documents
SWEngpptpres
SWEngpptpres
• Essence • Inherent
– difficulties inherent in Difficulties
the nature of – Complexity
software
– Conformity
• Accidents – Changeability
– difficulties – Invisibility
encountered but not
inherent
• Reliability • Testability
• Portability • Understandability
• Efficiency • Modifiability
• Human Engineering
Why?
Issues concerning software quality
• Relative costs of fixing faults
• Price performance factors
• Product size increase leads to larger teams
• Requirements • Integration
• Specifications • Maintenance
• Design • Retirement
• Implementation
Requirements Phase
“What I need, not what I said I needed”
Specifications Phase
What the developer wants to know:
• What does the • Frequent problems with
product do? a spec:
– ambiguous
• What are the
– incomplete
constraints on the – contradictory
product? • Specifications testing
• Acceptance criteria – SQA
– reviews
Design Phase
How does the product do what it is supposed to do?
Implementation Phase
Initial CS courses have to focus on this element first
• Code • Implementation
• Documentation testing
• Tests – desk checking
– test cases
– reviews
Integration Phase
Putting it all together
Maintenance Phase
In the user’s hands
• Why?
– operation
• Maintenance testing
– documentation
– changes
– turnover
– regression testing
• Kinds of maintenance
– Corrective
• Retirement
– Adaptive
– cost-effective?
– Perfective
– Preventive
Specification principles
• Separate functionality from implementation
– A process-oriented systems spec language is required
– A spec must encompass the system of which the SW is a
component
– A spec must encompass the environment in which the
system operates
– A system spec must be a cognitive model
– A spec must be operational
– The spec must be tolerant of incompleteness and
augmentable
– A spec must be localized and loosely coupled
• Analysis is information-driven
– First provide a mechanism for representing info
then derive function and behavior
– Common characteristics
1) mechanism for info domain analysis
2) approach for functional and/or behavior representation
3) definition of interfaces
4) mechanisms for problem partitioning
5) support of abstraction
6) representation of essential and implementation views
Testing
Testing cannot show the absence of defects,
it can only show that software defects are present.
Testing Methods
• Black-box testing
– Knowing the specified function that a product has been
designed to perform, tests can be conducted that
demonstrate each function is fully operational.
Development Testing
• Debugging approaches
– brute force
– backtracking
– cause elimination
• Before you fix
1. Is the cause of this bug also reproduced
elsewhere?
2. What new bug might I be putting in?
3. What would have prevented this bug?