Software Engineering Roadmap: Chapter 8 Focus

1
Software Engineering Roadmap Chapter 8 Focus
Identify corporate practices
Test units (parts) separately - use
implementations - apply discipline - gain
coverage
Plan project
Analyze requirements
Maintain
Integrate test system
Design
Test units
Implement
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
2
Golden Rules of Testing

• Goal of testing maximize the number and severity
  of defects found per dollar spent
• thus test early
• Limits of testing Testing can only determine the
  presence of defects, never their absence
• use proofs of correctness to establish absence

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
3
Testing the Big Picture
3. System tests
Include use-cases
2. Integration tests
OO
Packages of classes
Module combination
1. Unit tests
Combinations of methods in class
Module
Methods
Function
4
Unified Process
Jacobson et al USDP
Elaboration
Inception
Construction
Transition
Requirements Analysis Design Implemen- ta
tion Test
Unit Tests
Integration tests ... System tests
Prelim. iterations
Iter. 1
Iter. n
Iter. n1
Iter. m
Iter. m1
Iter. k
..
..
5
RoadMap for Unit Testing
Requirements
1. Plan for unit testing -- see section SSS
Identify largest trouble spots
Detailed design
Unit test plan
2. Acquire test set -- see section SSS
Products of prior testing
Test set
3. Execute unit test -- see section SSS
Test results
Code under test
IEEE, 1986
6
Generic Risk List 1 (Bach)

• Complex large, intricate or convoluted
• New no history in this product
• Changed anything that has been tampered with or
  improved
• Upstream dependency anything whose failure will
  cause cascading failures in the system

7
Generic Risk List 2 (Bach)

• Downstream dependency anything htat is
  especially sensitive to failures in the rest of
  the system
• Critical anything whose failure can cause
  substantial damage
• Precise anything that must meet its
  requirements exactly
• Popular anything that will be used a lot

8
Generic Risk List 3 (Bach)

• Strategic anything that has special importance
  for your business
• Third-party anything used in the product but
  developed outside the project
• Distributed anything spread out in time or
  space
• Buggy anything known to have a lot of problems
• Recent failure anything with a recent history
  of failure

9
Black-, Gray-, White-box Testing
Input determined by...
Result
Actual output compared with required output
Black box
requirements
Gray box
As for black- and white box testing
requirements key design elements
White box
Confirmation of expected behavior
design elements
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
10
Testing Ranges Elementary Cases

• 1. within range
• 2. at the boundaries
• of the range
• 3. outside the range
• (illegal)

range
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
11
Covering Every Statement is Not Sufficient (Myers)

• Code attempt to implement flowchart
• if( (ugt1) (v0) ) (1)
• x x/u (2)
• if( (u2) (xgt3) ) (3)
• x (4)
• u2, v0 and x3
• executes every line (1) - (4)
• gives the correct output x 2.5
• However, line (3) is wrong

Required program
ugt1 and v0
Yes
x x/u
No
u2 or xgt0
Yes
x
No
12
Plan for Unit Testing
One way to ...

• 1. Decide on the philosophy for unit testing
• individual engineer responsible (common)?
• reviewed by others?
• designed performed by others?
• 2. Decide what / where / how to document
• individuals personal document set (common)?
• how / when to incorporate into other types of
  testing?
• incorporate in formal documents?
• use tools / test utilities?
• 3. Determine extent of unit testing (i.e., in
  advance).
• do not just test until time expires
• prioritize, so that important tests definitely
  performed
• 4. Decide how and where to get the test input
• see section tbd.
• 5. Estimate the resources required
• use historical data if available
• 6. Arrange to track time, defect count, type
  source

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
13
Perform Method Testing (Humphrey) 1/2
One way to ...
1. Verify operation at normal parameter values
(a black box test based on the units
requirements) 2. Verify operation at limit
parameter values (black box) 3. Verify
operation outside parameter values (black box)
4. Ensure that all instructions execute
(statement coverage) 5. Check all paths,
including both sides of all branches (decision
coverage) 6. Check the use of all called
objects 7. Verify the handling of all data
structures 8. Verify the handling of all files
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
14
Perform Method Testing (Humphrey) 2/2
One way to ...
9. Check normal termination of all loops (part
of a correctness proof) 10. Check abnormal
termination of all loops 11. Check normal
termination of all recursions 12. Check abnormal
termination of all recursions 13. Verify the
handling of all error conditions 14. Check timing
and synchronization 15. Verify all hardware
dependencies
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
15
Perform ClassUnit Tests
One way to ...

• 1. Exercise methods in combination
• 2-5, usually
• choose most common sequences first
• include sequences likely to cause defects
• requires hand-computing the resulting attribute
  values
• 2. Focus unit tests on each attribute
• initialize, then execute method sequences that
  affect it
• 3. Verify that each class invariant is
  unchanged
• verify that the invariant is true with initial
  values
• execute a sequence (e.g., the same as in 1.)
• verify that the invariant still true
• 4. Verify that objects transition among expected
  states
• plan the state / transition event sequence
• set up the object in the initial state by setting
  variables
• provide first event check that transition
  occurred . etc.

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
16
Types of Maintenance Lientz Swanson

• Corrective
• defect identification and removal
• Adaptive
• changes resulting from operating system, hardware
  or DBMS changes
• Perfective
• changes resulting from user requests
• Preventative
• changes made to the software to make it more
  maintainable

Fixing
Enhancing
17
Software Maintenance Issues

• Management
• Return on investment hard to define
• Process
• Extensive coordination required to handle stream
  of Maintenance Requests
• Technical
• Covering full impact of changes
• Testing very expensive compared with the utility
  of each change
• focused tests ideal but expensive
• regression testing still required

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
18
Service a Maintenance Request 1
One way to ...

• 1. Be prepared to keep required metrics.
  Include..
• lines of code added
• lines of code changed
• time taken 1. preparation 2. design 3. code
  4. test
• 2. Ensure that the request has been approved
• 3. Understand the problem thoroughly
• reproduce the problem
• otherwise get clarification
• 4. Classify the MR as repair or enhancement
• 5. Decide whether the implementation requires a
  redesign at a higher level
• if so, consider batching with other MRs
• 6. Design the required modification
• (i.e., incorporate the change)

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
19
Service a Maintenance Request 2
One way to ...

• 7. Plan transition from current design
• 8. Assess changes impact throughout the
  application
• small changes can have major impact!
• 9. Implement the changes
• 10. Perform unit testing on the changed parts
• 11. Perform regression testing
• ensure changes havent compromised existing
  capabilities
• 12. Perform system testing with new capabilities
• 13. Update the configuration, requirement, design
  and test documentation

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
20
Estimating the Cost of Servicing a Maintenance
Request
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
21
RoadMap to Establish Maintenance (After Pigoski)
1a. Design for maintainability-- section 6.3 1b.
Ensure supportability 1c. Plan for transition to
maintenance 1d. Plan post-delivery logistics

• 2. Determine main-tenance scope
• all types?
• corrective only?
• limited corrective?
• -- section 2

• 4. Develop maintenance plan
• Change control approval procedure
• Help desk
• etc.
• -- section 5

• 3. Identify maintainers
• in-house?
• contracted?

6. Perform maintenance -- section 3
5. Estimate costs -- table 10.1
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
22
Impact of MR 162
Add change appearance when player achieves new
levels
Requirements
Accommodate ability to change global appearance
use Abstract Factory design pattern
Architecture
Detailed design
Interface specs
Add interface methods for Layout package
Function code
Add classes and methods as per detailed design
Module (e.g., package) code
Modify gameplay control code
System code
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
23
Five Attributes of Each Maintenance Step (IEEE)
Step
Attributes
1. Problem identification 2. Analysis 3.
Design 4. Implementation 5. System test 6.
Acceptance test 7. Delivery

• a. Input life cycle arti-facts for this step
• b. Process required for this step
• c. How the process is controlled
• d. Output life cycle artifacts
• e. Process quality factors involved
• f. Metrics for this step

24
EncounterEnvironment Package (Before Modification)
GameEnvironment
GameCharacter
GameArea
GameAreaConnection
Area
EncounterAreaConnection
EncounterEnvironment
EncounterEnvironment
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
25
Abstract Factory Applied to Encounter
Client
1..n
EncounterEnvironment
EnvironmentFactory getArea() getConnection()
Area

EncounterAreaConnection

Level2Area
Level1Area
Level3Area
Level1AreaConnection
Level2AreaConnection
Level3AreaConnection
create
Level1Factory getArea() getAreaConnection()
Level2Factory getArea() getAreaConnection()
Level3Factory getArea() getAreaConnection()
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
26
Migration Plan for Level-based Graphics
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
27
A Typical Maintenance Flow
Marketing
nominal path
Written MRs
Proposed M. R.s
Customer
Maintenance manager
Help desk
Approved M. R.s
Current source documentation
Change control board
Maintenance engineer
Modified source documentation
Rejected MRs
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
Graphics reproduced with permission from Corel.
28
disadvantages
Maintenance Patches
advantages

• Keeps customers satisfied in the short run
• Enables continued operation and testing without
  repeated prevalence of the defect
• Avoids masking other defects
• Enables test of fix

• Duplicates work
• patch and final fix both implemented
• Sometimes never replaced
• proper fix deferred forever!
• Complicates final fix
• must remove
• Complicates documentation process

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
29
Ranked Problems in Maintenance (Deklava)

• 1. Changing priorities
• 2. Testing methods
• 3. Performance measurement
• 3. Incomplete or non-existent system
  documentation
• 5. Adapting to changing business requirements
• 6. Backlog size

• 7. Measurement of contributions
• 8. Low morale due to lack of recognition or
  respect
• 9. Lack of personnel, especially experienced
• 10. Lack of maintenance methodology, standards,
  procedures and tools . . . . .

30
Managing MaintenanceExample profile of
fixing-type MRs
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
31
Profiles of Open Maintenance Requests
Fixing MRs Enhancement MRs
E.g., in April, the average enhancement MR had
been open for 8 weeks.
weeks open
10
5
February
January
August
March
April
June
May
July
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
32
Effects on Maintainability of Source Code
Properties
From Oman Om1
-global data types -global data structures data
flow consistency data type consistency -nesting -
I/O complexity
modularity -complexity consistency -nesting
-control coupling encapsu-lation module
re-use
-complexity use of structured constructs -use of
un-conditional branching -nesting cohesion
-local data types -local data structures -span of
data data initialized
overall program formatting overall program
commen-ting module separation naming symbol and
case
statement formatting vertical spacing horizontal
spacing intra-module commen-ting
Examples
modularity means greater modularity usually
makes an application more maintainable -span of
data means that the greater the scope of data
structures, the less maintainable.