Slide 10.

Object-Oriented and
Classical Software
Engineering
Eighth Edition, WCB/McGraw-Hill, 2011

Stephen R. Schach

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 CHAPTER 10 Slide 10.2

KEY MATERIAL
FROM
PART A

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 Overview Slide 10.3

 Software development: theory versus practice

 Iteration and incrementation
 The Unified Process
 Workflow overview
 Teams
 Cost–benefit analysis
 Metrics
 CASE
 Versions and configurations

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 Overview (contd) Slide 10.4

 Testing terminology
 Execution-based and non-execution-based testing
 Modularity
 Reuse
 Software project management plan

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

10.1 Software Development: Theory vs. Practice
Slide 10.5

 Ideally, software is developed

as described in Chapter 1
– Linear
– Starting from scratch

Figure 10.1
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Software Development: Theory vs. Practice (contd)
Slide 10.6

 In the real world, software development is totally

different
– We make mistakes
– The client’s requirements change while the software
product is being developed
» Moving target problem

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 10.2 Iteration and Incrementation Slide 10.7

 In real life, we cannot speak about “the design

phase”
– Instead, the operations of the design phase are spread
out over the life cycle
– We keep returning to earlier workflows

 The basic software development process is

iterative
– Each successive version is closer to its target than its
predecessor

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 Miller’s Law Slide 10.8

 At any one time, we can concentrate on only

approximately seven chunks (units of information)

 To handle larger amounts of information, use

stepwise refinement
– Concentrate on the seven aspects that are currently the
most important
– Postpone aspects that are currently less critical
– Every aspect is eventually handled, but in order of
current importance

 This is an incremental process

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 Incrementation Slide 10.9

Figure 10.2
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
 Incrementation (contd) Slide 10.10

 The number of increments will vary — it does not

have to be four

 Sequential phases do not exist in the real world

 Instead, the five core workflows (activities) are

performed over the entire life cycle
– Requirements workflow
– Analysis workflow
– Design workflow
– Implementation workflow
– Test workflow

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 Workflows Slide 10.11

 All five core workflows are performed over the entire

life cycle

 However, at most times one workflow predominates

 Examples:
– At the beginning of the life cycle
» The requirements workflow predominates
– At the end of the life cycle
» The implementation and test workflows predominate

 Planning and documentation activities are performed

throughout the life cycle
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
 Iteration Slide 10.12

 Iteration is performed during each incrementation

Figure 10.3

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 Iteration (contd) Slide 10.13

 Again, the number of iterations will vary—it is not

always three

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 10.3 The Unified Process Slide 10.14

 The software process is the way we produce

software

 It incorporates
– The methodology
» With its underlying software life-cycle model and techniques
– The tools we use
– The individuals building the software

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 The Unified Process (contd) Slide 10.15

 Despite its name, the Unified Process is not a

process!
– It’s a methodology

 The Unified Process is an adaptable methodology

– It has to be modified for the specific software product to
be developed

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 The Unified Process (contd) Slide 10.16

 The Unified Process uses a graphical language,

the Unified Modeling Language (UML) to
represent the software being developed

 A model is a set of UML diagrams that represent

various aspects of the software product we want to
develop

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 The Unified Process (contd) Slide 10.17

 The object-oriented paradigm is iterative and

incremental in nature
– There is no alternative to repeated iteration and
incrementation until the UML diagrams are satisfactory

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 10.4 Workflow Overview Slide 10.18

 Requirements workflow
– Determine exactly what the client needs

 Analysis workflow
– Analyze and refine the requirements
» To achieve the detailed understanding of the requirements
essential for developing a software product correctly and
maintaining it easily

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 Workflow Overview (contd) Slide 10.19

 Design workflow
– Refine the artifacts of the analysis workflow until the
material is in a form that can be implemented by the
programmers

 Implementation workflow
– Implement the target software product in the chosen
implementation language(s)

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 Workflow Overview (contd) Slide 10.20

 Test workflow
– Testing is carried out in parallel with the other workflows, from the
beginning
– Every developer and maintainer is personally responsible for
ensuring that his or her work is correct
– Once the software professional is convinced that an artifact is
correct, it is handed over to the software quality assurance group
for independent testing
– NOTE: the idea of an SQA group always formally checking every
artifact is good in theory, but real-world practices almost never
implement this idea. Formal SQA groups are rare except in very
large organizations that specialize in “for profit” software
development, and even then exhaustive checking is uncommon.
This observation is not meant to minimize the potential benefits of
an SQA group – it is meant to indicate that you should not assume
that an SQA group even exists, much less that it will check
everything. SO – check all your work yourself!
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
 10.5 Teams Slide 10.21

 Software products are usually too large (or too

complex) to be built by one software engineering
professional within the given time constraints

 The work has to be shared among a group of

professionals organized as a team

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 Teams (contd) Slide 10.22

 The team approach is used for each of the

workflows

 In larger organizations there may be specialized

teams for each workflow

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 10.6 Cost–Benefit Analysis Slide 10.23

 Cost–benefit analysis is a way of determining

whether a possible course of action would be
profitable
– Compare estimated future benefits against projected
future costs
 Cost–benefit analysis is a fundamental technique
in deciding whether a client should computerize
his or her business
– And if so, in what way
 Cost–benefit analysis is also fundamental in all
aspects of all software development workflows!

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 10.7 Metrics Slide 10.24

 We need measurements (or metrics) to detect

problems early in the software process
– Before they get out of hand

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 Metrics (contd) Slide 10.25

 There are five fundamental metrics

– Each must be measured and monitored for each
workflow:

 1. Size (in lines of code or, better, in a more

meaningful metric (complexity, adherence to
standards, etc.)
 2. Cost (in dollars)
 3. Duration (in months)
 4. Effort (in person-months)
 5. Quality (number of faults detected)
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
 Metrics (contd) Slide 10.26

 Metrics serve as an early warning system for

potential problems

 Management uses the fundamental metrics to

identify problems

 More specialized metrics are then utilized to

analyze these problems in greater depth

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 10.8 CASE Slide 10.27

 CASE stands for Computer-Aided Software

Engineering
– Software that assists with software development and
maintenance

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 CASE Taxonomy Slide 10.28

 A CASE tool assists in just one aspect of the

production of software
– Examples:
» A tool that draws UML diagrams
» A report generator, which generates the code needed for
producing a report

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 CASE Taxonomy (contd) Slide 10.29

 A CASE workbench is a collection of tools that

together support one or two activities
– Examples:
» A requirements, analysis, and design workbench that
incorporates a UML diagram tool and a consistency checker
» A project management workbench that is used in every
workflow

 A CASE environment supports the complete

software process

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 10.9 Versions and Configurations Slide 10.30

 During development and maintenance, there are

at least two versions of the product
– The old version, and
– The new version

 There will also be two or more versions of each of

the component artifacts that have been changed

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 Versions and Configurations (contd) Slide 10.31

 The new version of an artifact may be less correct

than the previous version

 It is therefore essential to keep all versions of all

artifacts
– A CASE tool that does this is called a version control
tool

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 Versions and Configurations (contd) Slide 10.32

 A configuration is
– A set of specific versions of each artifact from which a
given version of the complete product is built
– A configuration-control tool can handle problems caused
by development and maintenance by teams
» In particular, when more than one person attempts to change
the same artifact

 A baseline is a configuration of all the artifacts in

the product
– After each group of changes has been made to the
artifacts, a new baseline is attained

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 Versions and Configurations (contd) Slide 10.33

 If a software organization does not wish to

purchase a complete configuration-control tool,
then, at the very least,
– A version-control tool must be used in conjunction with
– A build tool, that is, a tool that assists in selecting the
correct version of each compiled-code artifact to be
linked to form a specific version of the product
» Build tools, such as make, have been incorporated into a wide
variety of programming environments

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 10.10 Testing Terminology Slide 10.34

 A fault is injected into a software product when a

human makes a mistake

 A failure is the observed incorrect behavior of the

software product as a consequence of a fault

 The error is the amount by which a result is

incorrect

 The word defect is a generic term for a fault,

failure, or error
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
 Testing Terminology (contd) Slide 10.35

 The quality of software is the extent to which the

product satisfies its specifications

 Within a software organization, the primary task of

the software quality assurance (SQA) group is to
test that the developers’ product is correct

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

10.11 Execution-Based and Non-Execution-Based Testing
Slide 10.36

 There are two basic forms of testing:

– Execution-based testing (running test cases), and
– Non-execution-based testing (carefully reading through
an artifact)

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 Non-Execution-Based Testing Slide 10.37

 In a review, a team of software professionals

carefully checks through a document
– Examples:
» specification document
» design document
» code artifact

 There are two types of review

– Walkthrough − less formal
– Inspection − more formal

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 Non-Execution-Based Testing (contd) Slide 10.38

 Non-execution-based testing has to be used when

testing artifacts of the requirements, analysis, and
design workflows

 Execution-based testing can be applied to only

the code of the implementation workflow

 Non-execution-based testing of code (code

review) has been shown to be as effective as
execution-based testing (running test cases)

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 10.12 Modularity Slide 10.39

 A module is
– A lexically contiguous sequence of program statements,
– Bounded by boundary elements (that is, {…} pairs),
– Having an aggregate identifier

 Examples:
– Procedures and functions of the classical paradigm
– Objects
– Methods within an object

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 Three Design Objectives Slide 10.40

 Ensure that the coupling (degree of interaction

between two modules) is as low as possible
– An ideal product exhibits only data coupling
» Every argument is either a simple argument or a data structure
for which all elements are used by the called module

 Ensure that the cohesion (degree of interaction

within a module) is as high as possible

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 Modularity (contd) Slide 10.41

 Maximize information hiding

– Ensure that implementation details are not visible
outside the module in which they are declared
» In the object-oriented paradigm, this can be achieved by careful
use of the private and protected visibility modifiers

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 10.13 Reuse Slide 10.42

 Reuse refers to using components of one product

to facilitate the development of a different product
with a different functionality
– Examples of a reusable component:
» Module
» Class
» Code fragment
» Design
» Part of a manual
» Set of test data, a contract
» Duration and cost estimate

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 Reuse (contd) Slide 10.43

 Reuse is most important because

– It takes time (= money) to
» specify,
» design,
» implement,
» test, and
» document
a software component

 If we reuse a component, we must retest the

component in its new context

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 10.14 Software Project Management Plan Slide 10.44

 The components of a software project

management plan:
– The work to be done
– The resources with which to do it
– The money to pay for it

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 Resources Slide 10.45

 Resources needed for software development:

– People
– Hardware
– Support software

 Use of resources varies with time

– The entire software development plan must be a
function of time

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 Three Work Categories Slide 10.46

 Project function
– Work carried on throughout the project
– Examples:
» Project management
» Quality control

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 Three Work Categories (contd) Slide 10.47

 Activity
– Work that relates to a specific phase
– A major unit of work
» With precise beginning and ending dates,
» That consumes resources, and
» Results in work products like the budget, design, schedules,
source code, or users’ manual

 Task
– An activity comprises a set of tasks (the smallest unit of
work subject to management accountability)

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 Completion of Work Products Slide 10.48

 A milestone is the date on which the work product

is to be completed

 It must first pass reviews performed by

– Fellow team members
– Management
– The client

 Once the work product has been reviewed and

agreed upon, it becomes a baseline

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Software Project Management Plan (contd) Slide 10.49

 A work package is
– A work product, plus
» Staffing requirements
» Duration
» Resources
» The name of the responsible individual
» Acceptance criteria for the work product
» The detailed budget as a function of time, allocated to
– Project functions
– Activities

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

 Software Project Management Plan (contd) Slide 10.50

 Money is a vital component of the plan

– A detailed budget must be worked out
– The money must be allocated, as a function of time, to
the project functions and activities

 Key components of the plan include

– The cost estimate, and
– The duration estimate

Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.