Introduction to Software Engineering

CS231: Software Engineering

Kardi Teknomo, PhD

Note: Most of these materials are borrowed from Schach (2007)

 Kardi Teknomo, PhD

Purpose
„ To introduce software engineering
„ Historical Aspect
„ Economic Aspect
„ To distinguish classical and modern
approach in software engineering
„ Maintenance Aspect
„ Software Life cycle
 Kardi Teknomo, PhD

Software development costs

What can you infer from the graph?

Hardware costs vs. Software costs
Software costs are increasing as
Hardware hardware costs continue to decline.
costs
Software •Hardware technology has made
costs great advances
•Simple and well understood tasks
are encoded in hardware
•Least understood tasks are encoded
in software
•Demands of software are growing
•Size of the software applications is
also increasing
•Hence “the software crisis”

Time
 Kardi Teknomo, PhD

Software Engineering History

„ SE introduced first in 1968 – NATO Conference,
Garmisch, Germany

„ Aim: To solve the software crisis

„ Early approaches based on informal methodologies

leading to
„ Late: Delays in software delivery
„ Over budget: Higher costs than initially estimated
„ Unreliable: difficult to maintain software

„ Need for new methods and techniques to manage

the production of complex software.
 Kardi Teknomo, PhD

State of the practice

What can you infer from this chart?
Estimate Early On Time Delayed Canceled
13,000 6.06% 74.77% 11.83% 7.33%
130,000 1.24% 60.76% 17.67% 20.33%
1,300,000 0.14% 28.03% 23.83% 48.00%
13,000,000 0.00% 13.67% 21.33% 65.00%

Source: Patterns of software failures and successes, Capers Jones, 1996

•Delays common with mid- to –large projects.

•Majority of the large projects are canceled.
 Kardi Teknomo, PhD

What can you infer from this chart?

60

50

40

30

20

10

0
Cost overrun Successful Cancelled
Source: The Standish Group, 1994

•Successful projects (16.2%)

- Delivered fully functional on time and on budget.
•Challenged (52.7%)
- Deliver less than full functionality, over-budget and late.
•Impaired (31.1%)
- Cancelled during development.
 Kardi Teknomo, PhD

Standish Group Data

„ Data on
9236
projects
completed
in 2004

Schach Figure 1.1

 Kardi Teknomo, PhD

Cutter Consortium Data

„ 2002 survey of information technology organizations
„ 78% have been involved in disputes ending in litigation

„ For the organizations that entered into litigation:

„ In 67% of the disputes, the functionality of the information
system as delivered did not meet up to the claims of the
developers
„ In 56% of the disputes, the promised delivery date slipped
several times
„ In 45% of the disputes, the defects were so severe that the
information system was unusable

„ Thus, The software crisis has not been solved

 Kardi Teknomo, PhD

Software myths
„ Management myths
„ Standards and procedures for building software
„ Add more programmers if behind the schedule

„ Customer myths
„ A general description of objectives enough to start
coding
„ Requirements may change as the software is flexible

„ Practitioner myths
„ Task accomplished when the program works
„ Quality assessment when the program is running
„ Working program the only project deliverable
 Kardi Teknomo, PhD

Software failures
Failures resulting from software errors have varied
consequences ranging from minor inconveniences
to catastrophic loss of life & property:
„ Therac-25 (1985-1987): six people overexposed
during treatments for cancer
„ Taurus (1993): the planned automatic transaction
settlement system for London Stock Exchange
cancelled after five years of development
„ Ariane 5 (1996): roket exploded soon after its
launch due error conversion (16 floating point into 16-
bit integer)
„ The Mars Climate Orbiter assumed to be lost by
NASA officials (1999): different measurement systems
(Imperial and metric)
 Kardi Teknomo, PhD

However …
Important progress:
„ Ability to produce more complex software has increased

„ New technologies have led to new SE approaches

„ A better understanding of the activities involved in

software development
„ Effective methods to specify, design and implement
software have been developed
„ Many aspects have been made more systematic
„ Methods/methodologies/techniques
„ Languages
„ Tools
„ Processes
 Kardi Teknomo, PhD

Economic Aspects
„ Coding method CMnew is 10% faster than currently used
method CMold. Should it be used?

„ Common sense answer

„ Of course!

„ Software Engineering answer

„ Consider the cost of training
„ Consider the impact of introducing a new technology
„ Consider the effect of CMnew on maintenance
 Kardi Teknomo, PhD

Economic and Management Aspects

„ Software production =
development + maintenance (evolution)

„ Maintenance costs > 60% of all development costs

„ 20% corrective (bug fixing)
„ 30% adaptive (change of environment)
„ 50% perfective (improve performance & functionality)

„ Quicker development is not always preferable

„ higher up-front costs may defray downstream costs
„ poorly designed/implemented software is a critical cost factor
 Kardi Teknomo, PhD

Dicussion Example
„ You are in charge of a software development.
The cost of developing the software is
estimated to be P 400,000. Approximately, how
much additional money would be needed for
post delivery maintenance of the software?

Answer: P 400,000 = 40%

Additional 60% = P 600,000 may be needed for
post delivery maintenance.
Thus the total cost could reach P 1 million
 Relative costs to fix errors:
Kardi Teknomo, PhD

What can you infer from this graph?

80

70
60
Cost
50

40
30

20

10

0
Design

Maintenance
Testing
Implementation
Requirements

Cost to fix an error increases as it is found later and later

in the software lifecycle
 Kardi Teknomo, PhD

Why are software projects late?

Estimating techniques are poorly developed
•Estimates are based on optimism:
- Programmers are optimistic.
- Assume “All will go well” with the project.
- Don’t plan for slippage.
- “This is the last bug.”
- “It’s going to work this time!”

•Optimism could be because of the nature of creativity:

- Conception of an idea and its implementation.
- Medium of creation constrains our ideas.
- In case of software the medium is infinitely malleable.
- Expect a few problems in implementation.
 Kardi Teknomo, PhD

Why are software projects late? (contd..)

Does effort necessarily == progress?

• Is one man working six months equal to six men working one month?

• Unit of man-month implies

that men and month are interchangeable.
- True only when a task can be partitioned among many workers
with no communication between them.
- For sequential tasks, more effort has no effect on the schedule.
- Many tasks in software engineering have sequential constraints.

Our estimating techniques fallaciously confuse effort with progress,

hiding the assumption that men and months are interchangeable.
- Fred Brooks, The Mythical Man-Month
 Kardi Teknomo, PhD

Why software projects are late? (contd..)

Managers do not monitor progress effectively

•Schedule slips day-by-day.
•Day-by-day slips are harder to recognize,
harder to prevent and harder to make up.

How does a software project get to be a year late?

One day at a time!
Fred Brooks, The Mythical Man-Month
 Kardi Teknomo, PhD

Why are software projects late ? (contd..)

When we recognize slippage, should we add more people?

•Most tasks require communication among workers.
•Communication consists of:
- Training.
- Sharing information (intercommunication).
•Training affects effort at worst linearly, with the number of people.
•For n workers, intercommunication adds n(n-1)/2 to effort.
- If each worker must communicate with every other worker.
•Adding more people to an already late project is usually like
“Adding gasoline to fire!”

Brooks' Law:
Adding manpower to a late software project makes it later.
Fred Brooks, The Mythical Man-Month
Kardi Teknomo, PhD
 Kardi Teknomo, PhD

Software Development Life cycle

„ Life-cycle model
„ The steps (phases) to follow when building
software
„ A theoretical description of what should be
done

„ Life cycle
„ The actual steps performed on a specific
product
 Kardi Teknomo, PhD

Classical Life Cycle Model (1970)

 Kardi Teknomo, PhD

Modern Waterfall Life-Cycle Model

Requirements

Analysis

Design

Implementation

Maintenance

Retirement
 Kardi Teknomo, PhD

Typical Phases
„ Requirements phase
„ Explore the concept
„ Elicit the client’s requirements

„ Analysis (specification) phase

„ Analyze the client’s requirements
„ Draw up the specification document
„ Draw up the software project management
plan
„ “What the product is supposed to do”
 Kardi Teknomo, PhD

Typical Phases (contd)

„ Design phase
„ Architectural design, followed by
„ Detailed design
„ “How the product does it”

„ Implementation phase
„ Coding
„ Unit testing
„ Integration
„ Acceptance testing
 Kardi Teknomo, PhD

Typical Phases (contd)

„ Postdelivery maintenance
„ Corrective maintenance
„ Perfective maintenance
„ Adaptive maintenance

„ Retirement
 Kardi Teknomo, PhD

Classical and Modern Views of Maintenance

„ Classical maintenance
„ Development-then-maintenance model

„ This is a temporal definition

„ Classification as development or
maintenance depends on when an activity is
performed
 Kardi Teknomo, PhD

Classical Maintenance Defn — Consequence 1

„ A fault is detected and corrected one day

after the software product was installed
„ Classical maintenance

„ The identical fault is detected and

corrected one day before installation
„ Classical development
 Kardi Teknomo, PhD

Classical Maintenance Defn — Consequence 2

„ A software product has been installed

„ The client wants its functionality to be

increased
„ Classical (perfective) maintenance

„ The client wants the identical change to be

made just before installation (“moving target
problem”)
„ Classical development
 Kardi Teknomo, PhD

Classical Maintenance Definition

„ The reason for these and similar
unexpected consequences
„ Classically, maintenance is defined in terms
of the time at which the activity is performed

„ Another problem:
„ Development (building software from
scratch) is rare today
„ Reuse is widespread
 Kardi Teknomo, PhD

Modern Maintenance Definition

„ In 1995, the International Standards
Organization and International
Electrotechnical Commission defined
maintenance operationally

„ Maintenance is nowadays defined as

„ The process that occurs when a software
artifact is modified because of a problem or
because of a need for improvement or
adaptation
 Kardi Teknomo, PhD

Modern Maintenance Definition (contd)

„ In terms of the ISO/IEC definition

„ Maintenance occurs whenever software is
modified
„ Regardless of whether this takes place
before or after installation of the software
product

„ The ISO/IEC definition has also been

adopted by IEEE and EIA
 Kardi Teknomo, PhD

Modern Maintenance Terminology

„ Postdelivery maintenance
„ Changes after delivery and installation [IEEE
1990]

„ Modern maintenance (or just

maintenance)
„ Corrective, perfective, or adaptive
maintenance performed at any time
[ISO/IEC 1995, IEEE/EIA 1998]
 Kardi Teknomo, PhD

The Importance of Postdelivery Maintenance

„ Bad software is discarded

„ Good software is maintained, for 10, 20

years or more

„ Software is a model of reality, which is

constantly changing
 Kardi Teknomo, PhD

Time (= Cost) of Postdelivery Maintenance

(a) Between 1976 and 1981

(b) Between 1992 and 1998
Figure 1.3
 Kardi Teknomo, PhD

The Costs of the Phases

„ Surprisingly, the costs of the phases have
hardly changed over time

Figure 1.4
 Kardi Teknomo, PhD

Consequence of Relative Costs of Phases

„ Comparison of Coding Techniques: CTnew =10%

faster than CTold. Will you use?

„ Reducing the coding cost by 10% yields at

most a 0.85% reduction in total costs
„ Consider the expenses and disruption incurred

„ Comparison of Maintenance Technique:MTnew

=10% cheaper than MTold. Will you use?

„ Reducing postdelivery maintenance cost by

10% yields a 7.5% reduction in overall costs
 Kardi Teknomo, PhD

Requirements, Analysis, and Design Aspects

„ The cost of
detecting and
correcting a
fault at each
phase

Figure 1.5
 Requirements, Analysis, and Design Aspects
Kardi Teknomo, PhD

(contd)

„ The
previous
figure
redrawn
on a
linear
scale

Figure 1.6
 Kardi Teknomo, PhD

Relative Costs of Fixing Software Faults

200
The earlier we
detect and correct
a fault, the less it
costs us

30

10
3 4
1 2
Requirements Specification Planning Design Implementation Integration Maintenance
Requirements, Analysis, and Design Aspects
Kardi Teknomo, PhD

(contd)
„ To correct a fault early in the life cycle
„ Usually just a document needs to be changed

„ To correct a fault late in the life cycle

„ Change the code and the documentation
„ Test the change itself
„ Perform regression testing
„ Reinstall the product on the client’s computer(s)

„ Between 60 and 70% of all faults in large-scale

products are requirements, analysis, and design faults
 Kardi Teknomo, PhD

Discussion Example
„ 6 months after delivery a fault is detected in the
software. Cost of fixing is P 2,000,000. The cause of
faults is an ambiguus senetnce in the sepcification
document. Approximately, how much would it cost to
have corrected the fault during analysis phase?

„ Answer:
„ Relative costs of fixing software faults during
specification is 2 compare to 200 during maintenance.
Thus, if the fault was corrected during analysis phase,
it would cost only P 20,000
 Kardi Teknomo, PhD

Conclusion
„ It is vital to improve our requirements,
analysis, and design techniques
„ To find faults as early as possible
„ To reduce the overall number of faults (and,
hence, the overall cost)
Kardi Teknomo, PhD
 Kardi Teknomo, PhD

Why There Is No Planning Phase

„ We cannot plan at the beginning of the
project —we do not yet know exactly
what is to be built
 Kardi Teknomo, PhD

Planning Activities of the Classical Paradigm

„ Preliminary planning of the requirements and

analysis phases at the start of the project

„ The software project management plan is

drawn up when the specifications have been
signed off by the client

„ Management needs to monitor the SPMP

throughout the rest of the project
 Kardi Teknomo, PhD

Conclusion
„ Planning activities are carried out
throughout the life cycle

„ There is no separate planning phase in

modern life cycle
 Kardi Teknomo, PhD

Why There Is No Testing Phase

„ It is far too late to test after development
and before delivery
 Kardi Teknomo, PhD

Testing Activities of the Classical Paradigm

„ Verification
„ Testing at the end of each phase (too late)

„ Validation
„ Testing at the end of the project (far too
late)
 Kardi Teknomo, PhD

Conclusion
„ Continual testing activities must be
carried out throughout the life cycle

„ This testing is the responsibility of

„ Every software professional, and
„ The software quality assurance group

„ There is no separate testing phase

 Kardi Teknomo, PhD

Why There Is No Documentation Phase

„ It is far too late to document after

development and before delivery
 Kardi Teknomo, PhD

Documentation Must Always be Current

„ Key individuals may leave before the
documentation is complete

„ We cannot perform a phase without having the

documentation of the previous phase

„ We cannot test without documentation

„ We cannot maintain without documentation

 Kardi Teknomo, PhD

Conclusion
„ Documentation activities must be
performed in parallel with all other
development and maintenance activities

„ There is no separate documentation

phase
 Kardi Teknomo, PhD

The Object-Oriented Paradigm

„ The structured paradigm was successful initially
„ It started to fail with larger products (> 50,000 LOC)

„ Postdelivery maintenance problems (today, 70 to 80%

of total effort)

„ Reason: Structured methods are

„ Action oriented (e.g., finite state machines, data flow
diagrams); or
„ Data oriented (e.g., entity-relationship diagrams, Jackson’s
method);
„ But not both
 Kardi Teknomo, PhD

The Object-Oriented Paradigm (contd)

„ Both data and actions are of equal importance

„ Object:
„ A software component that incorporates both data
and the actions that are performed on that data

„ Example:
„ Bank account
„ Data: account balance
„ Actions: deposit, withdraw, determine balance
 Kardi Teknomo, PhD

Structured versus Object-Oriented Paradigm

Schach Figure 1.7

„ Information hiding
„ Responsibility-driven design
„ Impact on maintenance, development
 Kardi Teknomo, PhD

Information Hiding
„ In the object-oriented version
„ The solid line around accountBalance denotes that
outside the object there is no knowledge of how
accountBalance is implemented

„ In the classical version

„ All the modules have details of the implementation
of account_balance
 Kardi Teknomo, PhD

Strengths of the Object-Oriented Paradigm

„ With information hiding, postdelivery

maintenance is safer
„ The chances of a regression fault are reduced

„ Development is easier
„ Objects generally have physical counterparts
„ This simplifies modeling (a key aspect of the object-
oriented paradigm)
Strengths of the Object-Oriented Paradigm
Kardi Teknomo, PhD

(contd)

„ Well-designed objects are independent

units
„ Everything that relates to the real-world item
being modeled is in the corresponding object
— encapsulation
„ Communication is by sending messages
„ This independence is enhanced by
responsibility-driven design (see later)
Strengths of the Object-Oriented Paradigm
Kardi Teknomo, PhD

(contd)

„ A classical product conceptually consists of a

single unit (although it is implemented as a set
of modules)
„ The object-oriented paradigm reduces complexity
because the product generally consists of
independent units

„ The object-oriented paradigm promotes reuse

„ Objects are independent entities
 Kardi Teknomo, PhD

Responsibility-Driven Design
„ Also called design by contract

„ Send flowers to your mother in Chicago

„ Call 1-800-flowers
„ Where is 1-800-flowers?
„ Which Chicago florist does the delivery?
„ Information hiding
„ Send a message to a method [action] of an object
without knowing the internal structure of the object
 Classical Phases vs Object-Oriented
Kardi Teknomo, PhD

Workflows

Figure 1.8

„ There is no correspondence between phases

and workflows
 Kardi Teknomo, PhD

Analysis/Design “Hump”
„ Structured paradigm:
„ There is a jolt between analysis (what) and
design (how)

„ Object-oriented paradigm:
„ Objects enter from the very beginning
 Kardi Teknomo, PhD

Analysis/Design “Hump” (contd)

„ In the classical paradigm
„ Classical analysis
„ Determine what has to be done
„ Design
„ Determine how to do it
„ Architectural design — determine the modules
„ Detailed design — design each module
 Kardi Teknomo, PhD

Removing the “Hump”

„ In the object-oriented paradigm
„ Object-oriented analysis
„ Determine what has to be done
„ Determine the objects
„ Object-oriented design
„ Determine how to do it
„ Design the objects

„ The difference between the two paradigms is

shown on the next slide
 Kardi Teknomo, PhD

In More Detail

Schach Figure 1.9

„ Objects enter here

 Kardi Teknomo, PhD

Object-Oriented Paradigm
„ Modules (objects) are introduced as early
as the object-oriented analysis workflow
„ This ensures a smooth transition from the
analysis workflow to the design workflow

„ The objects are then coded during the

implementation workflow
„ Again, the transition is smooth
 Kardi Teknomo, PhD

The Object-Oriented Paradigm in Perspective

„ The object-oriented paradigm has to be

used correctly
„ All paradigms are easy to misuse

„ When used correctly, the object-oriented

paradigm can solve some (but not all) of
the problems of the classical paradigm
The Object-Oriented Paradigm in Perspective
Kardi Teknomo, PhD

(contd)

„ The object-oriented paradigm has

problems of its own

„ The object-oriented paradigm is the best

alternative available today
„ However, it is certain to be superceded by
something better in the future
 Kardi Teknomo, PhD

Summary
„ Critical aspects of our day to day lives depend on
software, yet software development lacks the rigor and
discipline of mature engineering disciplines:
„ Too many projects get delayed, costs and schedules

slip
„ Software engineering seeks to bring discipline and rigor
to the building and maintenance of software systems

„ Why is important to consider alternative models of the

software development process?