1. Why do we need this course?
Why engineer software?
Can’t we 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

2. 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
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

3. Poor quality software menaces the maintenance of that infrastructure
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

4. 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)

5. 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

6. What is software?
Code
Various design documents
User manuals
Development plans, timelines, and budgets
Maintenance documents
The way of producing software (process)

7. 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

8. 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 LOCs
25 faults/KLOC
Ranges between faults/KLOC

9. Software costs Development costs Maintenance 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

10. Software Costs Development costs Full lifecycle costs reqts and design
35%
code
15%
testing
50%
Full lifecycle costs
code
reqts/design
testing
maintenance

11. Software code is too complex to reason about it directly
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

12. 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,...

13. 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

14. some types of relationships:
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

15. Trends in Software Expansion (Bernstein, 1997)
Factor
The ratio
of machine
lines of
code to a
source line
of code 1 10
100
1000
1960
1965
1970
1975
1980
1985
1990
2000
1995
Order of Magnitude Increase Every Twenty Years
Machine
Instructions
Macro
Assembler
High Level
Language
Database
Manager
On-line
Regression
Testing
Prototyping
4GL
Subsecond
Time
Sharing
Small
Scale
Reuse
Object
Oriented
Programming
Large Scale
142
113 81 75 47
37.5 30 15 3
475
638
Projection

16. 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

17. 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
Build quality in
Define software product formally
Define software process formally
Reason about the product and process formally
Incorporate validation as integral steps in the process

18. Software Lifecycle requirements reqts. analysis design specs
validation
coding
validation
testing
adequacy
maintenance
revalidation

19. requirements-- a complete,consistent specification of what is needed
Waterfall Model
requirements-- a complete,consistent specification of what is needed
provides visibility 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

20. 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

21. 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

22. 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

23. 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

24. 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
...

25. Barriers to engineering software
Industry’s short term focus
Shortage of skilled personnel
Inadequate investment in R&D
Poor technology transfer models
Insufficient standards

26. 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

27. Industry’s short term focus
software houses
intensely competitive
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

28. 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

29. What do we need?
Scientific basis
Organized discipline
R&D strategy
Trained professionals
Technology transfer strategies
Quality control

30. 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

31. High-level Goals of Software Engineering
improve productivity
reduce resources e.g., time, cost, personnel
improve predictability
improve maintainability
improve quality

32. Basic OO terms: object and class
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

33. Class notation
UML
Class Name
field 1 …
field n
method 1
method n

34. 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() {

35. 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>);

36. A module is a part of an application
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

37. 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

38. 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
The smaller 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

39. 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

40. 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:

41. Inheritance (cont.)
Multiple levels of inheritance are possible
Subclasses inherit attributes and methods of their superclasses

42. 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

43. Important OO concepts: aggregation
Aggregation is a relationship where one class is a part of another

44. Important OO concepts: association
Association is a general relationship among two classes

45. Class diagram for a game of dice

46. Modeling dynamic behaviors: state and sequence diagrams
Static behavior represents relationships among classes
Class diagrams
inheritance
aggregation
association
Dynamic behavior represents interactions among objects
State diagrams
Sequence diagrams

47. Represent all possible behaviors of an object
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

48. State diagram example: Game class

49. Sequence diagrams
Illustrate interaction of several objects

50. Annotations, or comments, may be added to any part of any UML diagram
Car
This class serves as a
very general type of
a car. You have to
instantiate one of its
children