Why do we need this course?

 Why engineer software?

 Can’twe just hack at it, until we get something
that works?
Many people/companies do this anyway…
 Answer: can’t hack it if we care about
quality
 If a system is not put together in a well-
organized manner, the chance for bugs is greater
 Another answer: You can’t just hack together
a 106 LOC system
 Complex systems are impossible to build in an ad-
hoc manner
Introduction: software quality
 Software is often buggy
 In critical applications, bugs can lead to
drastic consequences
 Therac-25 malfunctions killed or severely injured
several people in 1985-87
 Ariane 5 launcher crash on 4/6/1996
 Airbus problems
 Banking software failures
 Many more

 The main reason for bugs is enormous

complexity of software
 Need techniques to cope with this complexity
Quality Issues
 Software is now an integral part of every
facet of our societal infrastructure
 Air traffic control
 Telecommunication
 Financial infrastructure

 Poor quality software menaces the

maintenance of that infrastructure
 Software is the "Grand Enabler" holding the
key to scientific and engineering challenges
 Human genome project
 Space exploration
 Weather prediction
Why isn’t software quality up to snuff?
 deliver prototypes
 "leave it to the marketplace"
 unsophisticated consumers
 don't know what they want
 tolerate high failure rates

"the computer is down"

 misled by "coverups" in banking, finance,
communications
 lack of understanding of risks

Year 2000 (Y2K)

Software is everywhere
 Android: more than 1 million lines of code
 A military drone: 3.5 million lines of code
 A car: 100 million lines of code
 Google: 2 billion lines of code
What is software?
 Code
 Various design documents
 User manuals
 Development plans, timelines, and budgets
 Maintenance documents
 The way of producing software (process)
Desirable qualities of software systems
 Reliability
 Performs the required functions correctly
 The rate of failures is low

 Maintainability
 Understandability
 Changeability
 Simplicity

 Reusability
 The solution to a problem should be as general as
possible
 User friendliness
 Efficiency
Some interesting numbers
 About 25% of s/w projects fail
 Failure rate increases as the size of the project
increases
 Costs about $100/LOC
 Ranges between $10-$600
 Typical programmer produces about 30 LOCs
a day
 Ranges between 10-100 LOCs
 25 faults/KLOC
 Ranges between 3-100 faults/KLOC
Software costs

 Development costs
 generally measured in hundreds to thousands of
dollars per delivered LOC
many artifacts associated with a line of code
 testing and analysis is usually 50% of this cost

 Maintenance costs
 2-3 times as much as development
 Software Costs

Development costs

reqts and design

35% code
15%

testing
50%

Full lifecycle costs

code

reqts/design testing

maintenance
Models
 Software code is too complex to reason
about it directly
 Need a higher level representation, called
design
 Captures only the most important relevant
characteristics of the problem
 Needs to capture the behavior of the problem
accurately
 Software code must conform to its design
Software Engineering

 Name coined at the NATO Science Committee

Conference, October 1968
 Engineering-- established, scientifically sound
practices that well trained practitioners follow
 Software Engineering-- the application of scientific
knowledge to the the development and maintenance
of software systems
 Software-- ALL associated artifacts to assist with
the development, operation, validation, and
maintenance of programs/software systems
 e.g., code, documentation, designs, requirements, user
manuals, installation manuals, test cases, test results, bug
reports, revision history, make files,...
The nature of software

 Software is a complex, intricately

interconnected data aggregate
 Software Development is the process of
creating such a complex product, while
continuously assuring that it remains
consistent
 Software Engineering combines some of the
approaches of classical engineering with some
of the abstract approaches of mathematics
A software product is a complex web of
intertwined software objects, connected by a
multitude of diverse relations and constraints
 some types of objects:
 source code
 designs
 testcases
 documentation

 some types of relationships:

 is invoked by
 is derived from
 is consistent with
 is a version of
 Trends in Software Expansion (Bernstein, 1997)

Projection
1000
638
475

142
113
Expansion
100 75 81
Factor
47
37.5
The ratio 30
of machine
lines of 15
code to a 10
source line
of code
3
Order of Magnitude Increase Every Twenty Years

1
1960 1965 1970 1975 1980 1985 1990 1995 2000
Machine Macro High Level Database On-line Prototyping Subsecond Object Large Scale
Instructions Assembler Language Manager Time Oriented Reuse
Sharing Programming
Regression 4GL Small
Testing Scale
Reuse
What is novel about software, compared to
other fields of engineering?
 product is unprecedentedly complex
 application horizons expand too fast--with
human demands/imagination
 construction is human-intensive
 solutions require unusual rigor
 extremely malleable--can modify the product
all too easily
How to increase Software Quality

 Treat software as a PRODUCT produced in a

systematic way by a PROCESS designed and
implemented to achieve explicit quality
objectives
 Buildquality in
 Define software product formally
 Define software process formally
 Reason about the product and process formally
 Incorporate validation as integral steps in the
process
Software Lifecycle
requirements
reqts. analysis

design specs
validation

coding
validation

testing
adequacy

maintenance
revalidation
Waterfall Model
 requirements-- a complete,consistent
specification of what is needed
 providesvisibility for customers, developers, and
managers
 benchmark for testing and acceptance
 reduces misunderstandings

 requirements analysis
 evaluate completeness and consistency
 evaluate needs and constraints
 evaluate feasibility and costs

development and maintenance costs

Probability of success
Waterfall Model (continued)

 design specifications--a description of how

the requirements are to be realized
 high-level architectural design
 low-level detailed design

 design validation
 traceability between requirements and design
decisions
 internal consistency
Waterfall Model (continued)

 code--realization of the design in executable

instructions
 code validation
 assure coding and documentation standards have
been maintained
 internal consistency

e.g., syntactic analysis, semantic analysis,

type
checking, interface consistency
 consistency between design/requirements and code
Waterfall Model (continued)

 testing--reveal problems, demonstrate

behavior, assess reliability, evaluate
non-functional requirements
(e.g., performance, ease of use)
 unit testing
 integration testing
 system testing
 acceptance testing
 regression testing

 testing validation
 adequacy of the testcases
 Waterfall Model (continued)

 maintenance--the process of modifying existing software

while leaving its primary functionality intact
 corrective maintenance-- fix problems (20%)
 adaptive maintenance-- add new functionality/enhance existing
features (30%)
 perfective maintenance-- improve product (50%)

e.g., performance, maintainability

 3 primary steps
 understand existing software
 change existing software
 revalidate existing software

 maintenance involves all the previous phases of the

lifecycle
Is the waterfall model an appropriate
process model?
 recognizes distinct activities
 clearly oversimplifies the process
 wait, wait, wait, surprise model
 actual processes are more complex
 numerous iterations among phases
 not purely top down
 decomposition into subsystems

 many variations of the waterfall model

 prototyping
 re-engineering
 risk reduction
 ...
Barriers to engineering software

 Industry’s short term focus

 Shortage of skilled personnel
 Inadequate investment in R&D
 Poor technology transfer models
 Insufficient standards
Industry’s short term focus

 "bottom line orientation"

 emphasis on time to market
not life cycle
 return on investment

 startups cannot invest in R&D until product

established in marketplace
 without the R&D, takes too long for next or
improved product
 market strategy driven by investors who want
impressive short term gains
Industry’s short term focus

 software houses
 intenselycompetitive
 often don't use own technology
 keep development cost down, fix later

 unsophisticated industries
 lack of technical expertise
 lack of administrative experience

 overselling the technology

Barriers to engineering software
 industry’s short term focus
 shortage of skilled personnel
 inadequate investment in R&D
 PITAC(Kennedy-Joy) Report
 US SW GNP is $228B but less than 1% spent on
R&D
 Poor technology transfer models
 tend to "toss over the fence"
 Lack of standards
What do we need?

 Scientific basis
 Organized discipline
 R&D strategy
 Trained professionals
 Technology transfer strategies
 Quality control
Certification and Licensing?

 Currently, software engineering is not one of the 36

engineering professions recognized and licensed in
the United States.
 48 states prohibit using the term "engineer" without
a license
 Texas has forced universities to stop MSSE
 Tennessee prohibits the use of "software engineering" in
business literature and advertising
 New Jersey considered, but did not pass, a regulation that
would have required licensing of all SW professionals
 IEEE/CS & ACM established Commission on
Software Engineering in 1993
High-level Goals of Software
Engineering
 improve productivity
 reduce resources
e.g., time, cost, personnel
 improve predictability
 improve maintainability
 improve quality
Basic OO terms: object and class
 Object
 represents anything that can be distinctly
identified
 has a unique identity

what does it represent?

 Has a unique state

what is it doing?
 Has a set of possible behaviors

what are all possible things it can be doing?

 Class
 represents a set of objects with similar
characteristics and behavior
 in other words, the type of an object
Class notation
 UML
Class Name

field 1
…
field n

method 1
…
method n
Example: class Tree
 UML  Java
Class Tree {
private float height_;
private int noOfBranches_;
private Classification species_;

public void die() {

…
}
public void germinate() {
…
}
public void grow(Date untilDate) {
…
}
public void shedLeaves() {
…
}
}
Interaction among objects
 An OO program is a collection of
communicating objects
 This communication happens via message
passing
 To send a message to object b, object a has
to call a method of b
 b.<method name>(<parameter 1>…<parameter
k>);
Modules
 A module is a part of an application
 A module captures some well-defined
functionality
 Modules can be defined hierarchically
A module can contain a number of lower-level
modules
 A module consists of entities
 Functions
 Algorithms
 Objects
 Lower-level modules
 A module can be a class
Important OO principles: cohesion and coupling
 Cohesion refers to how well the entities of a
class fit together
 High cohesion, good
entities are highly related
 Low cohesion, bad

entities are not highly related

 Coupling refers to the amount of dependency
among the modules
 High coupling, bad
the amount of information that one module
should reveal to another is excessive
 Low coupling, good
Important OO principles: abstraction and
encapsulation
 Abstraction in terms of a module represents
the amount of information that the users of
this module need to be able to use it
 Thesmaller this amount of information, the
better
 Encapsulation is the principle of not making
“internal” information visible to the users
 Also known as information hiding
 Encapsulation improves abstraction
 Internal
changes can be made without affecting
the way that users use this module
Important OO principles: interface
 Interface to a module is the amount of
information that this module makes visible
 Abstraction can be characterized as complexity of
the interface
 Interface represents a contract between the
module and its users
 the module: “Here are all the services that I can
provide to you”
 UML notation
Module Interface Module
Important OO principles: inheritance
 The idea is to define a relationship where
class A is more general than class B
B inherits from A
 B is a subclass of A
 A is a superclass of B
 B is a kind of A

 Example:
Inheritance (cont.)
 Multiple levels of inheritance are possible
 Subclasses inherit attributes and methods of
their superclasses
Important OO principles: polymorphism
 A related but different kinds of functionality
can be implemented by several different
modules
 If the interfaces to all these modules are
the same, they can be used in exactly the
same way
 In the program, a module being used can be
changed dynamically, as long as the interface
remains the same
Important OO concepts: aggregation
 Aggregation is a relationship where one class
is a part of another
Important OO concepts: association
 Association is a general relationship among
two classes
Class diagram for a game of dice
Modeling dynamic behaviors: state and
sequence diagrams
 Static behavior represents relationships
among classes
 Classdiagrams
inheritance
aggregation
association
 Dynamic behavior represents interactions
among objects
 State diagrams
 Sequence diagrams
State diagrams
 Represent all possible behaviors of an object
 Consist of states and transitions
 At any moment of time, an object is in some state
Doing something
Having certain qualities
 A transition represents the object moving from one
state to another
Transitions are triggered by events
May have guards and side-effects
 Has a start state
 May have a final state

 States can be composite, called hyperstates

State diagram example: Game class
Sequence diagrams
 Illustrate interaction of several objects
Annotations
 Annotations, or comments, may be added to
any part of any UML diagram
 Notation:

Car
This class serves as a
very general type of
a car. You have to
instantiate one of its
children