1. James Nowotarski 9 October 2008
SE 325/425 Principles and Practices of Software Engineering Autumn 2008
James Nowotarski
9 October 2008

2. Today’s Agenda Topic Duration Testing (cont. from 10/2) 75 minutes
*** Break
Current events 15 minutes
Project estimating 45 minutes
Project scheduling 45 minutes 2

3. Verification & Validation
Testing is just part of a broader topic referred to as Verification and Validation (V&V)
Pressman/Boehm/IEEE:
Verification: Are we building the product right?
Validation: Are we building the right product?
IEEE standard :
Requirements validation is the process of evaluating an implemented system to determine whether it conforms to the specified requirements. 3

4. Stage Containment  Planning & Managing Communication requirements
project initiation
requirements
Modeling
analysis
design
Construction
code
test
Deployment
delivery
support
Error origination 
Error detection
error
fault
defect 4

5. V-Model System engineering System Test Requirements Validation Test
External/Internal
Design
Integration
Test
Detailed
Design
Unit Test
Left side of V shows successive stages of design and specification activities.
Right side of V depicts the levels of testing that correspond to each level of specifications.
Test conditions should be developed as part of the design and specification activities. These test conditions feed into the corresponding tests on the right side of the V.
As deliverables evolve along the left side of the V, they are subjected to verification and validation:
verification - check that a deliverable conforms to the standards for the current stage (“do the thing right”)
validation - check that a deliverable is implementing the specifications from prior stage(s) (“do the right thing”)
Entry/Exit criteria are an input to verification, validation, and testing activities. They help to determine when stage n is complete and stage n + 1 can begin.
Timely and thorough verification, validation, and testing helps achieve stage containment, whereby errors are discovered in the stage during which they originate and are not passed to a later stage (when they are more costly to correct).
Code
Testing: Test that the product implements the specification
Flow of Work
Verification
Validation
Legend: 5

6. Regression testing
The re-execution of some subset of tests that have already been conducted to ensure that changes have not introduced unintended side effects.
Whenever change is introduced or existing tests uncover errors that are fixed – there is opportunity for new errors to be introduced.
Supported by capture/playback tools.
Regression testing includes:
Tests focusing on the software components that have been changed.
Additional tests that focus on software functions that are likely to be affected by the change.
A representative sample of tests that will exercise all software functions. 6

7. Independent Test Group (ITG)
“Many parts of the test process are best handled by test specialists who did not necessarily contribute to the original design With good documentation it is feasible to use specialists in software product assurance who will, in my judgment, do a better job of testing than the designer.” - Royce, W. (1970). "Managing the Development of Large Software Systems." 9th International Conference on Software Engineering Proceedings, pp. 325. 7

8. V-Model Black box White box Unit Test Code System Test Validation Test
Integration
Test
White box
Unit Test
Code 8

9. Basis Path Testing First proposed by Tom McCabe in 1976.
Enables the test case designer to derive a logical complexity measure of the procedural design.
Uses this measure as the basis for defining an upper bound on the number of execution paths needed to guarantee that every statement in the program is executed at least once.
Uses a notation known as a flow graph. 9

10. Benefits for Basis Path Testing
Defines the number of independent paths thus the number of test cases needed to ensure:
Every statement will be executed at least one time
Every condition will be executed on its true & false sides
Focuses attention on program logic
Facilitates analytical instead of arbitrary test case design 10

11. Flow Graph Notation Sequence Case if while until
Where each circle represents one or more nonbranching set of source code statements. 11

12. An Example: Procedure Average (Pressman 6e, p.397, Figure 14.4)
* This procedure computes the average of 100 or fewer numbers that lie between bounding values; it also computes the sum of the total number valid.
INTERFACE RETURNS average, total.input, total.valid; INTERFACE ACCEPTS value, minimum, maximum; TYPE value[1:100] IS SCALAR ARRAY; TYPE average, total.input, total.valid; minimum, maximum, sum IS SCALAR; TYPE i IS INTEGER; 12

13. Continued…
i = 1; total.input = total.valid = 0; sum = 0; DO WHILE value[i] <> -999 AND total.input < 100 increment total.input by 1; IF value[i] >= minimum and value[i] <= maximum THEN increment total.valid by 1; sum = sum + value[i] ELSE skip ENDIF increment i by 1; ENDDO
IF total.valid > 0 THEN average = sum / total.valid; ELSE average = -999; ENDIF
END average 2 1 3 4 6 5 7 8 9 10 11 12 13 13

14. Steps for deriving test cases
Use the design or code as a foundation and draw corresponding flow graph. 1 2 3 4 5 6 7 8 9 10 13 12 11
2. Determine the cyclomatic complexity of the resultant flow graph.
V(G) = 17 edges – 13 nodes + 2 = 6 V(G) = 5 predicate nodes + 1 = 6. 14

15. Steps for deriving test cases
Determine a basis set of linearly independent paths. 1 2 3 4 5 6 7 8 9 10 13 12 11
Path 1: Path 2: Path 3: Path 4: … Path 5: … Path 6: …
Prepare test cases that will force execution of each path in the basis set. 15

16. Basis Path Testing In small groups
Derive a data flow graph from the code (see next slide).
Define independence paths (basis set)
Derive tests to drive each path in the basis set 17

17. Code for small group activity (Valid pins 10000-19999):
Procedure Validate_Pin (Valid_Pin, Return_Code)
Valid_Pin = FALSE
Return_Code = GOOD
Pin_Count = 0
do until Valid_Pin = TRUE or Pin_Count > 2 or Return_Code = CANCEL
begin
get Pin_Number (Pin_Number, Return_Code)
if (Return_Code ≠ CANCEL)
call Validate Pin_Number (Pin_Number, Valid_Pin)
if (Valid_Pin = FALSE) then
output “Invalid PIN, please re-enter PIN”
Pin_Count = Pin_Count + 1
end
return (Valid_Pin, Return_Code) 18

18. Test Coverage Metrics
Statement coverage: Goal is to execute each statement at least once.
Branch coverage Goal is to execute each branch at least once.
Path coverage Where a path is a feasible sequence of statements that can be taken during the execution of the program.
5/10 = 50%
2/6  33%
1/4  25% Where does the 4 come from?
What % of each type of coverage does this test execution provide?
= tested
= not tested 19

19. Today’s Agenda Topic Duration Testing (cont. from 10/2) 75 minutes
*** Break
Current events 15 minutes
Project estimating 45 minutes
Project scheduling 45 minutes 20

20. Project Management Our focus Planning & Managing Communication
project initiation
requirements
Modeling
analysis
design
Construction
code
test
Deployment
delivery
support 21

21. What is SE? Software Engineering Body of Knowledge
Software requirements
Software design
Software construction
Software testing
Software maintenance
Software configuration management
Software engineering management
Software engineering process
Software engineering tools and methods
Software quality
Source: Guide to the Software Engineering Body of Knowledge. (2004). IEEE.
tonight 22 22 22

22. Creating a project “work plan”
Cust
requirements 1
Negotiate
reqts
negotiated
requirements
Iterate as necessary 2
Decom-
pose
work
breakdown
structure 3
Estimate
size
deliverable 4
Estimate
resources
workmonths 5
Develop
schedule 23

23. Work breakdown structure (WBS)
Analogous to a table of contents
Hierarchical
Ensures clarity and completeness of planning
Can be deliverable-oriented, activity-oriented, or (most common) a combination 24

24. Deliverable-oriented WBS
Copyright © 2006 The McGraw-Hill Companies. All rights reserved.

25. Deliverable-oriented WBS: Building a bicycle
Develop a WBS for a project in which you are going to build a bicycle.
Try to identify all of the major components and provide 3 levels of detail 26

26. Sample WBS (deliverable-oriented)27

27. Sample WBS (activity-oriented)
Breaks project into a hierarchy.
Creates a clear project structure.
Avoids risk of missing project elements.
Enables clarity of high level planning. 28

28. Activity-oriented WBS
Copyright © 2006 The McGraw-Hill Companies. All rights reserved.

29. Planning process Users requirements Negotiate reqts negotiated1
Negotiate
reqts
negotiated
requirements
Iterate as necessary 2
Decom-
pose
work
breakdown
structure 3
Estimate
size
deliverable
productivity rate 4
Estimate
resources
workmonths 5
Develop
schedule 30

30. Units of software size Lines of code (LOC) Function points (FP)
Components 31

31. LOC
How many physical source lines are there in this C language program?
#define LOWER 0 /* lower limit of table */
#define UPPER 300 /* upper limit */
#define STEP 20 /* step size */
main() /* print a Fahrenheit->Celsius conversion table */ {
int fahr;
for(fahr=LOWER; fahr<=UPPER; fahr=fahr+STEP)
printf(“%4d %6.1f\n”, fahr, (5.0/9.0)*(fahr-32)); } 32

32. LOC Need standards to ensure repeatable, consistent size counts
Include Exclude
Executable 
Nonexecutable
Declarations 
Compiler directives 
Comments
On their own lines 
On lines with source 
. . . 33

33. Estimation of LOC CAD program to represent mechanical parts
Estimated LOC = (Optimistic + 4(Likely)+ Pessimistic)/6
Major Software Functions
Opt-imistic
Most Likely
Pess-imistic
Estimated LOC
User interface and control facilities
UICF
1,500
2,300
3,100
Two-dimensional geometric analysis
2DGA
3,800
5,200
7,200
5,300
Three-dimensional geometric analysis
3DGA
4,600
6,900
8,600
6,800
Database management
DBM
1,600
3,500
4,500
3,350
Computer graphics display features
CGDF
3,700
5,000
6,000
4,950
Peripheral control PC
1,400
2,200
2,400
2,100
Design analysis modules
DAM
8,300
10,000
8,400
Estimated lines of code
23,800
33,400
41,800
33,200 34

34. LOC
“Lines of code is a useless measurement in the face of code that shrinks when we learn better ways of programming” (Kent Beck) 35

35. Computing Function Points
Measurement parameter
Count
Sim-ple
Avg
Com-plex
Number of user inputs X 3 4 6 =
Number of user outputs 5 7
Number of user inquiries
Number of files 10 15
Number of external interfaces
Count (Unadjusted Function Points) UFP 5 15 8 32 10 40 8 80 2 10
177

36. Function Points A measure of the size of computer applications
The size is measured from a functional, or user, point of view.
It is independent of the computer language, development methodology, technology or capability of the project team used to develop the application.
Can be subjective
Can be estimated EARLY in the software development life cycle
Two flavors:
Delivered size = total application size delivered, including packages, assets, etc.
Developed size = portion built for the release 37

37. Calculate Degree of Influence (DI)1 2 3 4 5
No influence
Incidental
Moderate
Average
Significant
Essential
Does the system require reliable backup and recovery?
Are data communications required?
Are there distributed processing functions?
Is performance critical?
Will the system run in an existing, heavily utilized operational environment?
Does the system require on-line data entry?
Does the on-line data entry require the input transaction to be built over multiple screens or operations?
Are the master files updated on-line?
Are the inputs, outputs, files, or inquiries complex?
Is the internal processing complex?
Is the code designed to be reusable?
Are conversion and installation included in the design?
Is the system designed for multiple installations in different organizations?
Is the application designed to facilitate change and ease of use by the user? 3 4 1 3 2 4 3 3 2 1 3 5 1 1

38. The FP Calculation: Inputs include:
Count Total
DI =  Fi (i.e., sum of the Adjustment factors F1.. F14)
Calculate Function points using the following formula: FP = UFP X [ X  Fi ]
In this example: FP = 177 X [ X ( ) FP = 177 X [ X (36) FP = 177 X [ ] FP = 177 X [1.01] FP =
TCF: Technical complexity factor

39. AVERAGE SOURCE STATEMENTS PER FUNCTION POINT
Reconciling FP and LOC
LANGUAGE
AVERAGE SOURCE STATEMENTS PER FUNCTION POINT
1032/AF 16
1st Generation default
320
2nd Generation default
107
3rd Generation default 80
4th Generation default 20
5th Generation default 5
Assembly (Basic)
BASIC C
128
C++ 53
COBOL
JAVA
Visual Basic 5 29

40. Components
Simple
Medium
Hard
# Database tables
# Reports
Etc. 41

41. Planning process Users requirements Negotiate reqts negotiated1
Negotiate
reqts
negotiated
requirements
Iterate as necessary 2
Decom-
pose
work
breakdown
structure 3
Estimate
size
deliverable
productivity rate 4
Estimate
resources
workmonths 5
Develop
schedule 42

42. Bottom-up estimating Estimate = #units x time per unit
For example, a report design task:
10 reports
3 hours per report
Estimate = 30 person-hours (aka “workhours”
Most projects are estimated in this way, once details are known about units 43

43. Using FP to estimate effort:
If for a certain project
FPEstimated = 372
Organization’s average productivity for systems of this type is 6.5 FP/person month
EffortEstimated = ???
Burdened labor rate of $8000 per person month
Total project cost  $???
Cost per FP  $???

44. Other estimating techniques
Expert judgment
Analogy
Algorithmic
General model:
E = A + B x (ev)c where E is effort in person months
A, B, and C are empirically derived constants
ev is the estimation variable (either in LOC or FP) 45

45. Software size estimation formulae
LOC-Oriented Estimation Models
E = 5.2 X (KLOC)0.91
Walston-Felix Model
E = X (KLOC)1.16
Bailey-Basili Model
E = 3.2 X (KLOC)1.05
Boehm simple model
E = X (KLOC)1.047
Dot Model for KLOC > 9
FP-Oriented Estimation Models
E = FP
Albrecht and Gaffney Model
E = X X 10-8 FP3
Kemerer model
E = FP
Matson, Barnett, Mellichamp model 46

46. Top-down vs. Bottom-up Planning & Managing Communication requirements
project initiation
requirements
Modeling
analysis
design
Construction
code
test
Deployment
delivery
support
Top-down “approximating”:
Expert judgment
Analogy
Algorithmic
Bottom-up “estimating” 47

47. Estimating accuracy improves over time 48

48. Some famous words from Aristotle
It is the mark of an instructed mind to rest satisfied with the degree of precision which the nature of a subject admits, and not to seek exactness when only approximation of the truth is possible….
Aristotle ( B.C.)
Accuracy of software project estimate is predicated on:
Correct estimate of the size & complexity of the product to be built.
Ability to translate size & complexity into human effort.
The degree to which the project plan reflects the abilities of the software team.
The stability of product requirements.
The maturity of the software engineering environment.

49. Today’s Agenda Topic Duration Testing (cont. from 10/2) 75 minutes
*** Break
Current events 15 minutes
Project estimating 45 minutes
Project scheduling 45 minutes 50

50. Planning process Users requirements Negotiate reqts negotiated1
Negotiate
reqts
negotiated
requirements
Iterate as necessary 2
Decom-
pose
work
breakdown
structure 3
Estimate
size
deliverable
productivity rate 4
Estimate
resources
workmonths 5
Develop
schedule 51

51. GANTT Schedule View Project in Context of time.
Critical for monitoring a schedule.
Granularity 1 –2 weeks. 52

52. Gantt Example 1:
Suppose a project comprises five activities: A,B,C,D, and E. A and B have no preceding activities, but activity C requires that activity B must be completed before it can begin. Activity D cannot start until both activities A and B are complete. Activity E requires activities A and C to be completed before it can start. If the activity times are A: 9 days; B: 3 days; C: 9 days; D: 5 days; and E: 4 days, determine the shortest time necessary to complete this project.
Identify those activities which are critical in terms of completing the project in the shortest possible time. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 A B C D E 53

53. Immediate Predecessors
Gantt Example 2:
Activity
Immediate Predecessors
Activity Time (days) A - 12 B 6 C 13 D
A, B E
C, D 11 F G
E, F
Construct a Gantt chart which will provide an overview of the planned project.
How soon could the project be completed?
Which activities need to be completed on time in order to ensure that the project is completed as soon as possible? 54

54. Immediate Predecessors
Gantt Example 3: Software Package Selection ID
Description
Immediate Predecessors
Activity Time (weeks) A
Select consultant - 2 B
Meet with consultant 4 C
Meet with board of directors D
Develop rough outline to solicit proposals
B, C 1 E
Obtain vendor proposals F
Identify alternatives for consideration 3 G
Analyze alternative designs 8 H
Present proposals to board I
Redo estimates per board requests J
Obtain board approval
Construct a Gantt chart.
How soon could the project be completed?
Which activities need to be completed on time in order to ensure that the project is completed as soon as possible? 55

55. Estimating Schedule Time
Rule of thumb (empirical)
Schedule Time (months) =
3.0 * person-months1/3 56

56. One of the primary jobs of a project manager is to manage these tradeoffs57

57. Some Courses at DePaul SE 468: Software Measurement and Estimation
Software metrics. Productivity, effort and defect models. Software cost estimation. PREREQUISTE(S):CSC 423 and either SE 430 or CSC 315 or consent
SE 477: Software and System Project Management
Planning, controlling, organizing, staffing and directing software development activities or information systems projects. Theories, techniques and tools for scheduling, feasibility study, cost-benefit analysis. Measurement and evaluation of quality and productivity. PREREQUISTE(S):SE 465 or CSC 315 58

58. People trump process
One good programmer will always outcode 100 hacks in the long run, no matter how good of a process or IDE you give them 59

59. For October 16 Midterm (post to COL) Read Pressman Chapter 10
Current event reports 60