Conventional Method (Muhammad Muchtar Aham - 108091000071)

Supplementary Slides for
Software Engineering:
A Practitioner's Approach, 5/e
copyright © 1996, 2001

R.S. Pressman & Associates, Inc.
For University Use Only

May be reproduced ONLY for student use at the university level
when used in conjunction with Software Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly prohibited.
This presentation, slides, or hardcopy may NOT be used for

short courses, industry seminars, or consulting purposes.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
1
Design Concepts and Principles
2
Analysis to Design
Process Specification (PSPEC)

Data Object Description procedural
Entity-
design
Data Flow
Relationship Diagram
Diagram
interface
Data Dictionary
design
architectural
State-Transition design
Diagram
data
Control Specification (CSPEC) design
THE ANALYSIS MODEL THE DESIGN MODEL
3
Where Do We Begin?
modeling
Prototype
Spec
Design
4
Design Principles
 The design process should not suffer from ‘tunnel vision.’
 The design should be traceable to the analysis model.
 The design should not reinvent the wheel.
 The design should “minimize the intellectual distance” [DAV95] between the software and
the problem as it exists in the real world.
 The design should exhibit uniformity and integration.
 The design should be structured to accommodate change.
 The design should be structured to degrade gently, even when aberrant data, events, or
operating conditions are encountered.
 Design is not coding, coding is not design.
 The design should be assessed for quality as it is being created, not after the fact.
 The design should be reviewed to minimize conceptual (semantic) errors.
From Davis [DAV95]
5
Fundamental Concepts
 abstraction—data, procedure, control
 refinement—elaboration of detail for all abstractions
 modularity—compartmentalization of data and function
 architecture—overall structure of the software
 Structural properties
 Extra-structural properties
 Styles and patterns
 procedure—the algorithms that achieve function
 hiding—controlled interfaces
6
Data Abstraction
door
manufacturer
model number
type
swing direction
inserts
lights
type
number
weight
opening mechanism
implemented as a data structure
7
Procedural Abstraction
open
details of enter
algorithm
implemented with a "knowledge" of the

object that is associated with enter
8
Stepwise Refinement
open
walk to door;
reach for knob;
open door; repeat until door opens
turn knob clockwise;
walk through; if knob doesn't turn, then
close door. take key out;
find correct key;
insert in lock;
endif
pull/push door
move out of way;
end repeat
9
Modular Design
easier to build, easier to change, easier to fix ...
10
Modularity: Trade-offs
What is the "right" number of modules
for a specific software design?
module development cost
cost of
software
module
integration
cost
optimal number number of modules

of modules
11
Sizing Modules: Two Views
What's How big
inside?? is it??
MODULE
12
Functional Independence
COHESION - the degree to which a

module performs one and only one
function.
COUPLING - the degree to which a

module is "connected" to other
modules in the system.
13
Architecture
“The overall structure of the software and the
ways in which that structure provides
conceptual integrity for a system.” [SHA95a]
Structural properties. This aspect of the architectural design
representation defines the components of a system (e.g., modules,
objects, filters) and the manner in which those components are packaged
and interact with one another. For example, objects are packaged to
encapsulate both data and the processing that manipulates the data and
interact via the invocation of methods .
Extra-functional properties. The architectural design description should
address how the design architecture achieves requirements for
performance, capacity, reliability, security, adaptability, and other system
characteristics.
Families of related systems. The architectural design should draw upon
repeatable patterns that are commonly encountered in the design of
families of similar systems. In essence, the design should have the ability
to reuse architectural building blocks.
14
Information Hiding
module • algorithm
controlled
interface • data structure
• details of external interface
• resource allocation policy
clients "secret"
a specific design decision
15
Why Information Hiding?
 reduces the likelihood of “side effects”
 limits the global impact of local design
decisions
 emphasizes communication through
controlled interfaces
 discourages the use of global data
 leads to encapsulation—an attribute of high
quality design
 results in higher quality software
16
Architectural Design
17
Why Architecture?
The architecture is not the operational software.
Rather, it is a representation that enables a software
engineer to:
(1) analyze the effectiveness of the design in meeting
its stated requirements,
(2) consider architectural alternatives at a stage when
making design changes is still relatively easy, and
(3) reduce the risks associated with the construction of
the software.
18
Data Design
 refine data objects and develop a set of data
abstractions
 implement data object attributes as one or more
data structures
 review data structures to ensure that appropriate
relationships have been established
 simplify data structures as required
19
Data Design—Component Level
1. The systematic analysis principles applied to function and
behavior should also be applied to data.
2. All data structures and the operations to be performed on
each should be identified.
3. A data dictionary should be established and used to define
both data and program design.
4. Low level data design decisions should be deferred until
late in the design process.
5. The representation of data structure should be known only
to those modules that must make direct use of the data
contained within the structure.
6. A library of useful data structures and the operations that
may be applied to them should be developed.
7. A software design and programming language should
support the specification and realization of abstract data types.
20
Architectural Styles
Each style describes a system category that encompasses: (1) a
set of components (e.g., a database, computational modules) that
perform a function required by a system, (2) a set of connectors
that enable “communication, coordination and cooperation”
among components, (3) constraints that define how components
can be integrated to form the system, and (4) semantic models
that enable a designer to understand the overall properties of a
system by analyzing the known properties of its constituent parts.
 Data-centered architectures
 Data flow architectures
 Call and return architectures
 Object-oriented architectures
 Layered architectures
21
Data-Centered Architecture
22
Data Flow Architecture
23
Call and Return Architecture
24
Layered Architecture
25
Analyzing Architectural Design
1. Collect scenarios.
2. Elicit requirements, constraints, and environment
description.
3. Describe the architectural styles/patterns that have been
chosen to address the scenarios and requirements:
• module view
• process view
• data flow view
4. Evaluate quality attributes by considered each attribute in
isolation.
5. Identify the sensitivity of quality attributes to various
architectural attributes for a specific architectural style.
6. Critique candidate architectures (developed in step 3)
using the sensitivity analysis conducted in step 5.
26
An Architectural Design Method
customer requirements
"four bedrooms, three baths,
lots of glass ..."
architectural design
27
Deriving Program Architecture
Program
Architecture
28
Partitioning the Architecture
 “horizontal” and “vertical” partitioning
are required
29
Horizontal Partitioning
 define separate branches of the module hierarchy
for each major function
 use control modules to coordinate
communication between functions
function 1 function 3
function 2
30
Vertical Partitioning:
Factoring
 design so that decision making and work are
stratified
 decision making modules should reside at the
top of the architecture
decision-makers
workers
31
Why Partitioned Architecture?
 results in software that is easier to test

 leads to software that is easier to maintain
 results in propagation of fewer side effects
 results in software that is easier to extend
32
Structured Design
 objective: to derive a program architecture
that is partitioned
 approach:
 the DFD is mapped into a program architecture
 the PSPEC and STD are used to indicate the content
of each module
 notation: structure chart
33
Flow Characteristics
Transform flow
Transaction
flow
34
General Mapping Approach
isolate incoming and outgoing flow
boundaries; for transaction flows, isolate
the transaction center
working from the boundary outward, map

DFD transforms into corresponding modules
add control modules as required
refine the resultant program structure

using effective modularity concepts
35
Transform Mapping
b g h
a e f
d
c i
j
data flow model
x1 "Transform" mapping
x2 x3 x4
b c d e f g i
a h j
36
Factoring
direction of increasing
decision making typical "decision
making" modules
typical "worker" modules
37
First Level Factoring
main
program
controller
input processing output

controller controller controller
38
Second Level Mapping
main
D
C
control
B A
A
B
C
mapping from the D

flow boundary outward
39
Transaction Flow
incoming flow
action path
T
40
Transaction Example
fixture setting fixture
servos
commands
operator process
report display
operator
commands screen
robot control
robot
control
software
assembly
record
in reality, other
commands
would also be shown
41
Refining the Analysis Model
1. write an English language processing narrative
for the level 01 flow model
2. apply noun/verb parse to isolate processes, data

items, store and entities
3. develop level 02 and 03 flow models

4. create corresponding data dictionary entries
5. refine flow models as appropriate

... now, we're ready to begin design!
42
Deriving Level 1
Processing narrative for " process operator commands"
Process operator command software reads operator commands from
the cell operator. An error message is displayed for invalid commands.
The command type is determined for valid commands and appropriate
action is taken. When fixture commands are encountered, fixture
status is analyzed and a fixture setting is output to the fixture servos.
When a report is selected, the assembly record file is read and a
noun-verb report is generated and displayed on the operator display screen.
When robot control switches are selected, control values are sent to
parse the robot control system.
Process operator command software reads operator commands from

the cell operator. An error message is displayed for invalid commands.
The command type is determined for valid commands and appropriate
action is taken. When fixture commands are encountered, fixture
status is analyzed and a fixture setting is output to the fixture servos.
When a report is selected, the assembly record file is read and a
report is generated and displayed on the operator display screen.
When robot control switches are selected, control values are sent to
the robot control system.
43
Level 1 Data Flow Diagram
operator commands Error msg status fixture
servos
read
operator
commands fixture setting
valid command analyze
fixture
fixture status
determine
command
select report
type
generate report
control display
report
robot screen
send
control
assembly
value robot
record
control
system
robot control
44
Level 2 Data Flow Diagram
command error msg
produce
error
msg
status format
read command setting fixture setting
command invalid command determine
setting
validate read raw setting
command fixture
status combined
determine status
type
robot control read

record record
calculate
send output values
control values report
format
value
report
assembly
record
start /stop
45
Transaction Mapping Principles
isolate the incoming flow path
define each of the action paths by looking for

the "spokes of the wheel"
assess the flow on each action path
define the dispatch and control structure
map each action path flow individually
46
Transaction Mapping
e f
a d
b
t i
g
h k
l j
data flow model
m
n
x1 Mapping
b t
a x2 x3 x4
d e f g h x3.1 l m n
i j
k
47
Isolate Flow Paths
command error msg
produce
error
msg
status format
read command setting fixture setting
command invalid command determine
setting
validate read raw setting
command fixture
status combined
determine status
type
robot control read

record record
calculate
send output values
control values report
format
value
report
assembly
record
start /stop
48
Map the Flow Model
process
operator
commands
command determine
input type
controller
read validate produce fixture report send

command command error status generation control
message controller controller value
each of the action paths must be expanded further
49
Refining the Structure Chart
process
operator
commands
command determine
input type
controller
read validate produce fixture report send

command command error status generation control
message controller controller value
read determine format read calculate format

fixture record output
setting setting report
status values
50
Interface Are Designed
 intermodular interface design
 driven by data flow between modules
 external interface design
 driven by interface between applications
 driven by interface between software and non-human producers
and/or consumers of information
 human-computer interface design
 driven by the communication between human and machine
51
User Interface Design
52
Interface Design
Easy to learn?
Easy to use?
Easy to understand?
53
Interface Design
Typical Design Errors
lack of consistency
too much memorization
no guidance / help
no context sensitivity
poor response
Arcane/unfriendly
54
Golden Rules
 Place the user in control

 Reduce the user’s memory load
 Make the interface consistent
55
Place the User in Control
Define interaction modes in a way that does not force a user
into unnecessary or undesired actions.
Provide for flexible interaction.
Allow user interaction to be interruptible and undoable.
Streamline interaction as skill levels advance and allow the
interaction to be customized.
Hide technical internals from the casual user.
Design for direct interaction with objects that appear on the
screen.
56
Reduce the User’s Memory Load
Reduce demand on short-term memory.
Establish meaningful defaults.
Define shortcuts that are intuitive.
The visual layout of the interface should be based on a
real world metaphor.
Disclose information in a progressive fashion.
57
Make the Interface Consistent
Allow the user to put the current task into a meaningful
context.
Maintain consistency across a family of applications.
If past interactive models have created user
expectations, do not make changes unless there is a
compelling reason to do so.
58
User Interface Design Models
 System perception — the user’s mental image of
what the interface is
 User model — a profile of all end users of the
system
 System image — the “presentation” of the system
projected by the complete interface
 Design model — data, architectural, interface and
procedural representations of the software
59
User Interface Design Process
60
Task Analysis and Modeling
 All human tasks required to do the job (of the
interface) are defined and classified
 Objects (to be manipulated) and actions (functions
applied to objects) are identified for each task
 Tasks are refined iteratively until the job is
completely defined
61
Interface Design Activities
1. Establish the goals and intentions for each task.
2. Map each goal/intention to a sequence of specific actions.
3. Specify the action sequence of tasks and subtasks, also
called a user scenario, as it will be executed at the interface
level.
4. Indicate the state of the system, i.e., what does the interface
look like at the time that a user scenario is performed?
5. Define control mechanisms, i.e., the objects and actions
available to the user to alter the system state.
6. Show how control mechanisms affect the state of the system.
7. Indicate how the user interprets the state of the system from
information provided through the interface.
62
Design Evaluation Cycle
preliminary
design
build
prototype #1
interface
build
prototype # n
interface
user
evaluate's
interface
design
modifications
are made
evaluation
is studied by
designer
Interface design
is complete
63
Component-Level Design
64
Component-Level Design
 the closest design activity to coding
 the approach:
 review the design description for the component
 use stepwise refinement to develop algorithm
 use structured programming to implement
procedural logic
 use ‘formal methods’ to prove logic
65
Stepwise Refinement
open
walk to door;
reach for knob;
open door; repeat until door opens
turn knob clockwise;
walk through; if knob doesn't turn, then
close door. take key out;
find correct key;
insert in lock;
endif
pull/push door
move out of way;
end repeat
66
The Component-Level
Design Model
 represents the algorithm at a level of detail that
can be reviewed for quality
 options:
 graphical (e.g. flowchart, box diagram)
 pseudocode (e.g., PDL) ... choice of many
 programming language
 decision table
 conduct walkthrough to assess quality
67
Structured Programming
for Procedural Design
uses a limited set of logical constructs:
sequence
conditional — if-then-else, select-case
loops — do-while, repeat until
leads to more readable, testable code
important for achieving high quality,
but not enough
68
A Structured Procedural Design
add a condition Z,
a if true, exit the program
x1
b x2 c
x3 d
f e
x4
x5
69
Program Design Language (PDL)
if condition x
then process a;
else process b;
endif
if-then-else PDL
easy to combine with source code
machine readable, no need for graphics input
graphics can be generated from PDL
enables declaration of data as well as procedure
easier to maintain
70
Why Design Language?
can be a derivative of the HOL of choice
e.g., Ada PDL
machine readable and processable
can be embedded with source code,

therefore easier to maintain
can be represented in great detail, if

designer and coder are different
easy to review
71
Software Testing Techniques
72
Software Testing
Testing is the process of exercising a

program with the specific intent of finding
errors prior to delivery to the end user.
73
Testability
 Operability—it operates cleanly
 Observability—the results of each test case are
readily observed
 Controlability—the degree to which testing can be
automated and optimized
 Decomposability—testing can be targeted
 Simplicity—reduce complex architecture and logic
to simplify tests
 Stability—few changes are requested during testing
 Understandability—of the design
74
What Testing Shows
errors
requirements conformance
performance
an indication
of quality
75
Who Tests the Software?
developer independent tester

Understands the system Must learn about the system,
but, will test "gently" but, will attempt to break it
and, is driven by "delivery" and, is driven by quality
76
Exhaustive Testing
loop < 20 X
14
There are 10 possible paths! If we execute one
test per millisecond, it would take 3,170 years to
test this program!!
77
Selective Testing
Selected path
loop < 20 X
78
Software Testing
white-box black-box
methods methods
Methods
Strategies
79
Test Case Design
"Bugs lurk in corners
and congregate at
boundaries ..."
Boris Beizer
OBJECTIVE to uncover errors
CRITERIA in a complete manner
CONSTRAINT with a minimum of effort and time
80
White-Box Testing
... our goal is to ensure that all

statements and conditions have
been executed at least once ...
81
Why Cover?
logic errors and incorrect assumptions
are inversely proportional to a path's
execution probability
we oftenbelieve that a path is not

likely to be executed; in fact, reality is
often counter intuitive
typographical errors are random; it's

likely that untested paths will contain
some
82
Basis Path Testing
First, we compute the cyclomatic
complexity:
number of simple decisions + 1
or
number of enclosed areas + 1
In this case, V(G) = 4
83
Cyclomatic Complexity
A number of industry studies have indicated
that the higher V(G), the higher the probability
or errors.
modules
V(G)
modules in this range are

more error prone
84
Basis Path Testing
Next, we derive the
independent paths:
1
Since V(G) = 4,
2 there are four paths
3 Path 1: 1,2,3,6,7,8
4
5 6 Path 2: 1,2,3,5,7,8
Path 3: 1,2,4,7,8
Path 4: 1,2,4,7,2,4,...7,8
7
Finally, we derive test
cases to exercise these
8
paths.
85
Basis Path Testing Notes
you don't need a flow chart,

but the picture will help when
you trace program paths
count each simple logical test,

compound tests count as 2 or
more
basis path testing should be

applied to critical modules
86
Loop Testing
Simple
loop
Nested
Loops
Concatenated
Loops Unstructured
Loops
87
Loop Testing: Simple Loops
Minimum conditions—Simple Loops

1. skip the loop entirely
2. only one pass through the loop
3. two passes through the loop
4. m passes through the loop m < n
5. (n-1), n, and (n+1) passes through
the loop
where n is the maximum number
of allowable passes
88
Loop Testing: Nested Loops
Nested Loops
Start at the innermost loop. Set all outer loops to their
minimum iteration parameter values.
Test the min+1, typical, max-1 and max for the
innermost loop, while holding the outer loops at their
minimum values.
Move out one loop and set it up as in step 2, holding all
other loops at typical values. Continue this step until
the outermost loop has been tested.
Concatenated Loops
If the loops are independent of one another
then treat each as a simple loop
else* treat as nested loops
endif*
for example, the final loop counter value of loop 1 is
used to initialize loop 2.
89
Black-Box Testing
requirements
output
input events
90
Equivalence Partitioning
user output FK
queries mouse formats input
prompts data
picks
91
Sample Equivalence Classes
Valid data
user supplied commands
responses to system prompts
file names
computational data
physical parameters
bounding values
initiation values
output data formatting
responses to error messages
graphical data (e.g., mouse picks)
Invalid data
data outside bounds of the program
physically impossible data
proper value supplied in wrong place
92
Boundary Value Analysis
user output FK
queries mouse formats input
data
picks prompts
output
input domain domain
93
Other Black Box Techniques
 error guessing methods
 decision table techniques
 cause effect graphing
94
Software Testing Strategies
95
Testing Strategy
unit test integration
test
system validation
test test
96
Unit Testing
module
to be
tested
results
software
engineer test cases
97
Unit Testing
module
to be
tested
interface
local data structures
boundary conditions
independent paths
error handling paths
test cases
98
Unit Test Environment
driver
interface
local data structures
Module boundary conditions
independent paths
error handling paths
stub stub
test cases
RESULTS
99
Integration Testing Strategies
Options:
• the “big bang” approach
• an incremental construction strategy
100
Top Down Integration
A
top module is tested with
stubs
B F G
stubs are replaced one at

a time, "depth first"
C
as new modules are integrated,
some subset of tests is re-run
D E
101
Bottom-Up Integration
A
B F G
drivers are replaced one at a

time, "depth first"
C
worker modules are grouped into

builds and integrated
D E
cluster
102
Sandwich Testing
A
Top modules are
tested with stubs
B F G
Worker modules are grouped into

builds and integrated
D E
cluster
103
High Order Testing
validation test
system test
alpha and beta test
other specialized testing
104
Debugging:
A Diagnostic Process
105
The Debugging Process
test cases
new test results

regression cases
tests suspected
causes
corrections
Debugging
identified
causes
106
Debugging Effort
time required
to diagnose the
time required symptom and
to correct the error determine the
and conduct cause
regression tests
107
Symptoms & Causes
symptom and cause may be
geographically separated
symptom may disappear when

another problem is fixed
cause may be due to a

combination of non-errors
cause may be due to a system
or compiler error
cause may be due to

symptom assumptions that everyone
cause believes
symptom may be intermittent
108
Consequences of Bugs
infectious
damage
catastrophic
extreme
serious
disturbing
annoying
mild
Bug Type
Bug Categories: function-related bugs,
system-related bugs, data bugs, coding bugs,
design bugs, documentation bugs, standards
violations, etc.
109
Debugging Techniques
brute force / testing
backtracking
induction
deduction
110
Debugging: Final Thoughts
1. Don't run off half-cocked, think about the

symptom you're seeing.
2. Use tools (e.g., dynamic debugger) to gain
more insight.
3. If at an impasse, get help from someone else.
4. Be absolutely sure to conduct regression tests

when you do "fix" the bug.
111
Software Quality Assurance
112
Why SQA Activities Pay Off?
cost to find
and fix a defect
100 60.00-100.00
log
scale
10 10.00
3.00
1.50
1 0.75 1.00
Design testsystem field

Req. code use
test
113
Quality Concepts
 general objective: reduce the “variation between
samples” ... but how does this apply to software?
 quality control: a series of inspections, reviews, tests
 quality assurance: analysis, auditing and reporting
activities
 cost of quality
 appraisal costs
 failure costs
 external failure costs
114
Software Quality Assurance
SQA Process Formal

Definition & Technical
Standards Reviews
Analysis
& Test
Reporting Planning
& Review
Measurement
115
Reviews & Inspections
... there is no particular reason

why your friend and colleague
cannot also be your sternest critic.
Jerry Weinberg
116
What Are Reviews?
 a meeting conducted by technical people for
technical people
 a technical assessment of a work product created
during the software engineering process
 a software quality assurance mechanism
 a training ground
117
What Reviews Are Not!
They are not:
a project budget summary
a scheduling assessment
an overall progress report
a mechanism for reprisal or political
intrigue!!
118
The Players
review
leader standards bearer (SQA)
producer
maintenance
oracle
recorder reviewer
user rep
119
Conducting the Review
1. be prepared—evaluate
product before the review
2. review the product, not

the producer
3. keep your tone mild, ask

questions instead of
making accusations
4. stick to the review agenda

5. raise issues, don't resolve them
6. avoid discussions of style—stick to technical
correctness
7. schedule reviews as project tasks
8. record and report all review results

120
Review Options Matrix
IPR * WT IN RRR
trained leader no yes yes yes
agenda established maybe yes yes yes
reviewers prepare in advance maybe yes yes yes
producer presents product maybe yes no no
“reader” presents product no no yes no
recorder takes notes maybe yes yes yes
checklists used to find errors no no yes no
errors categorized as found no no yes no
issues list created no yes yes yes
team must sign-off on result no yes yes maybe
* IPR—informal peer review WT—Walkthrough

IN—Inspection RRR—round robin review
121
Metrics Derived from Reviews
inspection time per page of documentation
inspection time per KLOC or FP
inspection effort per KLOC or FP
errors uncovered per reviewer hour
errors uncovered per preparation hour
errors uncovered per SE task (e.g., design)
number of minor errors (e.g., typos)
number of major errors
(e.g., nonconformance to req.)
number of errors found during preparation
122
Statistical SQA
• collect information on all
defects
Product • find the causes of the
& Process defects
• move to provide fixes for
the process
measurement
... an understanding of how
to improve quality ...
123

Conventional Method (Muhammad Muchtar Aham - 108091000071)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Conventional Method (Muhammad Muchtar Aham - 108091000071)

Uploaded by

Copyright:

Available Formats

Supplementary Slides for

copyright © 1996, 2001

For University Use Only

This presentation, slides, or hardcopy may NOT be used for

Process Specification (PSPEC)

THE ANALYSIS MODEL THE DESIGN MODEL

From Davis [DAV95]

implemented as a data structure

implemented with a "knowledge" of the

optimal number number of modules

COHESION - the degree to which a

COUPLING - the degree to which a

a specific design decision

 results in software that is easier to test

working from the boundary outward, map

add control modules as required

refine the resultant program structure

typical "worker" modules

input processing output

mapping from the D

2. apply noun/verb parse to isolate processes, data

3. develop level 02 and 03 flow models

5. refine flow models as appropriate

Process operator command software reads operator commands from

robot control read

define each of the action paths by looking for

assess the flow on each action path

define the dispatch and control structure

map each action path flow individually

robot control read

read validate produce fixture report send

each of the action paths must be expanded further

read validate produce fixture report send

read determine format read calculate format

 Place the user in control

machine readable, no need for graphics input

graphics can be generated from PDL

enables declaration of data as well as procedure

machine readable and processable

can be embedded with source code,

can be represented in great detail, if

Testing is the process of exercising a

developer independent tester

OBJECTIVE to uncover errors

CRITERIA in a complete manner

CONSTRAINT with a minimum of effort and time

... our goal is to ensure that all

we oftenbelieve that a path is not

typographical errors are random; it's

number of simple decisions + 1

number of enclosed areas + 1

In this case, V(G) = 4

modules in this range are

you don't need a flow chart,

count each simple logical test,

basis path testing should be

Minimum conditions—Simple Loops

stubs are replaced one at

drivers are replaced one at a

worker modules are grouped into

Worker modules are grouped into

alpha and beta test

other specialized testing