Comp 302: Software Engineering
Outline of today’s lecture
How important is software? Why?
 An overview of the software industry
 What is software engineering?
 The issues
 The constraints
 Key ideas underlying software engineering methodologies
 The software life cycle
2
Comp 302
But, first
 Brush up on your programming skills!
 Make sure you know
 how to use arrays in Java
 how to use the Collections framework and the java.util package
 Chapter 19 in Deitel&Deitel, Java How to Program, 6/e
 Chapters 20, 21 and 22 in Deitel&Deitel, Java How to Program, 5/e
 how to write to and read from a file
 how to build a basic GUI
 how polymorphism works
 You will need these skills for the prototype and the
project
 There will not be time to re-teach you these in this class
 Your project grades and learning experience will suffer
SIGNIFICANTLY if you don’t have a working knowledge of these
3
Comp 302
How important is software?
 Very important
 Many businesses, entire industries, the global economy rely on
software
 Financial institutions, the stock market, …
 Aerospace, automotive, almost any manufacturing
 Inventory, supply-chain management
 e-commerce
 Government, medicine, other research, …
 Reflected in economic indicators
 Guess
 Turkey’s Gross National Product
 Turkey’s yearly budget
 Yearly revenue of the software industry
4
Comp 302
How important is software?
 Very important
 Many businesses, entire industries, the global economy rely on
software
 Financial institutions, the stock market, …
 Aerospace, automotive, almost any manufacturing
 Inventory, supply-chain management
 e-commerce
 Government, medicine, other research, ..
 Reflected in economic indicators
 Guess
 Turkey’s Gross National Product
 ~$200 billion
 Turkey’s yearly budget
 ~$70-80 billion
 Yearly revenue of the software industry
 ~$150 billion
5
Comp 302
The Software Marketplace
 Software remains one of the most innovative and fastest
growing sectors of the global economy, generating
revenues of more than $150 billion every year.
6
Comp 302
From Software Magazine’s Software 500 for 2004
Company
Software /
Services
Revenue
($Million)
Corporate
Revenue
($Million)
1 IBM
2 Microsoft Corporation
3 EDS
$56,946.00
$32,190.00
$20,000.00
$89,131.00
$32,190.00
$20,000.00
4 Lockheed Martin
$15,275.50
$31,824.00
5 Computer Sciences Corp.
$13,846.30
$13,846.30
6 Accenture Ltd.
$13,397.20
$13,397.20
7 Hewlett-Packard Company
8 Oracle Corporation
9 Hitachi, Ltd.
$10,165.00
$9,475.00
$9,345.00
$56,588.00
$9,475.00
$21,834.00
10 SAP America
$8,779.00
$8,848.80
11 Capgemini
12 NTT Data Corporation
$7,224.00
$6,943.10
$7,224.00
$6,943.10
13 Unisys Corporation
14 Ingram Micro Inc.
15 SYNNEX Corp.
$4,691.90
$4,520.00
$4,126.20
$5,911.20
$22,613.00
$4,126.20
R&D
R&Das
as%%
of
Services as Corporate
%
Revenue Employees Software Business Sector
Middleware/Application
71.00%
6%
319,000 Server/Web Server
NA
14%
54,468 Operating Systems
100.00%
NA
120,000 IT Sourcing
System Integration
NA
NA
130,000 Services
System Integration
NA
NA
90,000 Services
System Integration
NA
NA
83,000 Services
System Integration
NA
NA
142,000 Services
NA
NA
41,600 Database
84.00%
7%
326,344 Other
Telecommunications
32.00%
14%
30,251 Services
System Integration
NA
NA
49,805 Services
NA
NA
7,550
System Integration
NA
NA
37,300 Services
NA
NA
11,300 Supply Chain
NA
NA
1,664 Supply Chain
Characteristics of IT Industry
 20 million new jobs in the US in the past seven years
 Between 1995 and1998, the IT sector contributed one-third of all U.S.
economic growth
 Between 1996 and 1997, falling prices in the IT sector knocked almost
a full percentage point off US inflation (typically 3-5%)
 IT now accounts for nearly one-half of all business investment.
 Workers in the IT industry earn 80% more than the private sector
average--$53,000 as compared to $30,000.
(Data taken from the testimony of Harris N. Miller
President, Information Technology Association of America (ITAA)
http://www.itaa.org/govt/cong/c19991208.pdf and http://www.nfo-bi.com/)
 Total e-commerce revenue in 2003 was $720 billion.
 E-commerce revenue in 2004 is estimated to reach $3.2 trillion
(eMarketer estimate, www.nfo-bi.com)
 US retail e-commerce revenue: $102 billion
 25% increase over 2005
8
Comp 302
Cost of software
 Ratio of hardware to software procurement cost
approaching zero
 Total cost of ownership for computers: 5 times the cost
of hardware
 Gartner estimate: Keeping a PC functional for five years
costs $7-14 K.
9
Comp 302
It’s a great time to be a software engineer!
10
Comp 302
It’s a great time to be a software engineer!
11
Comp 302
It’s a great time to be a software engineer!
 Software engineering is a great and
growing profession!
 The field is young




It is innovative and fast-paced
Lots of unsolved, complex problems
Lots of new solutions every day
Lots of opportunities for smart, energetic people to make their
mark!
 This is not just the greatest profession of our time –
 It’s the greatest profession of all time
12
Comp 302
Goals of Course
Being smart and energetic doesn’t cut it, so, this course will
 introduce you to disciplined software development
 convey a number of key concepts about
commercial/industrial software development
 Formal, structured software development process
 Teams, management, organizations
13
Comp 302
Outline of today’s lecture
 How important is software? Why?
 An overview of the software industry
What is software engineering?
 The issues
 The constraints
 Key ideas underlying software engineering methodologies
 The software life cycle
14
Comp 302
Software Engineering
 Classic Definition (1969)
“The establishment and use of sound engineering
principles in order to obtain economically software
that is reliable and works efficiently on real
machines.”
 IEEE Definition (1993)
“Software Engineering: The application of a systematic,
disciplined, quantifiable approach to the development,
operation, and maintenance of software; that is the
application of engineering to software.”
15
Comp 302
Outline of today’s lecture
 How important is software? Why?
 An overview of the software industry
 What is software engineering?
The issues
 The constraints
 Key ideas underlying software engineering methodologies
 The software life cycle
16
Comp 302
Issue 1: Fault-Free Software
 What are Faults?
 software behavior unaccounted for in its design
 Examples?
 Therac-25 medical linear accelerator incident
 Int’l Atomic Energy Agency declared radiological emergency in
2001 in Panama.
 28 patients overexposed, 8 died.
 Data entry software was in error
 Ariane-5 (ESA rocket)
 Rocket lost due to (unneeded) code throwing exception
 Patriot missile timing error
 NASA Climate Orbiter failure
 London Ambulance Dispatch system
 Dropped, duplicated calls
17
Comp 302
Development failures
 IBM survey,1994
 55% of systems cost more than expected
 68% overran schedules
 88% had to be substantially redesigned
 Advanced Automation System (FAA, 1982-1994)
 industry average was $100/line, expected to pay $500/line
 ended up paying $700-900/line
 $6B worth of work discarded
 Bureau of Labor Statistics (1997)




18
for every 6 new systems put into operation, 2 cancelled
probability of cancellation is about 50% for biggest systems
average project overshoots schedule by 50%
3/4 systems are regarded as ‘operating failures’
Comp 302
Issue 1: Working, quality software
 Buggy software is a huge problem
 Defects in software are commonplace
 Much more common than in other engineering disciplines
 How can we lessen our chances of faults?
 Use a well-defined process that includes rigorous design, testing, and
programming techniques
 Role of design and designers
 thinking in advance always helps (and it’s cheap!)
 can’t add quality at the end:
 contrast with reliance on testing; more effective, much cheaper
 makes delegation and teamwork possible
19
Comp 302
Specification
 But how do we know behavior is a bug?
 Because we have some separate specification of what
the program must do
 Separate from the code
 Thus, knowing whether the code works requires us first
to define what “works” means
 A specification
 Formal, or semi-formal
20
Comp 302
Teams and Specifications
Principle #1:
Communication is hard.
In any conversation, the participants will have (slightly)
differing interpretations of what was said.
21
Comp 302
Teams and Specifications (Cont.)
 Principle #1 is devastating for software development
 People will




22
Discuss what to do
Divide up the work
Implement incompatible components
Be surprised when it doesn’t all just work together
Comp 302
What Can We Do?
 Write specifications
 Write down what it is supposed to do
 Make sure everyone understands it
 Keep the specification up to date
 This does not solve the problem
 There are always ambiguities, contradictions
 These lead to bugs
 But the problem is reduced to manageable size
23
Comp 302
Summary of Issue 1
 A specification allows us to:
 Check whether software works
 Build software in teams at all
 Checking that the software works is hard




24
Code reviews
Static analysis tools
Testing and more testing
Formal verification
Comp 302
Issue 2: Time & Budget Constraints
 What happens if we are late?
 miss the market window (competition wins)
 costs rise, less profit
 What happens if we are over budget?
 loss of profit
 cancellation of project
 Case study: California DMV software (‘87-’93)
 attempt to merge driver & vehicle registration systems
 spent 7 years and $50 million before pulling the plug
 costs 6.5x initial estimate & expected delivery slipped to 1998!
25
Comp 302
Time
 Time is the enemy of all software projects
 Taking a long time is inherently risky
 Time pressure is (seemingly) at conflict with sound
development.
 The Netscape vs. IE story
26
Comp 302
Why?
 The world changes, sometimes quickly
 Technologies become obsolete
 Many products obsolete before they first ship!
 Other people produce competitive software
 Software usually depends on many 3rd-party pieces
 Compilers, networking libraries, operating systems, etc.
 All of these are in constant motion
 Moving slowly means spending lots of energy keeping up with
these changes
27
Comp 302
Issue 2: How Do We Code Efficiently?
 Assume we want to minimize time
 Usually the case
 Time-to-market exerts great pressure in software
 How can we code faster?
 Obvious answer: Hire more programmers!
28
Comp 302
Parallel Development
 How many programmers can we keep busy?
 As many as there are independent tasks
 People can work on different modules
 Thus we get parallelism
 And save time
 What are the pitfalls?
29
Comp 302
Pitfalls of Parallel Development
 The problems are the same as in parallel computing
 More people = more communication
 Which is hard
 Individual tasks must not be too fine-grain
 Increases communication overhead further
 Inherent sequential constraints
 e.g., pipeline architecture
30
Comp 302
Interfaces
 The chunks of work must be independent
 But work together in the final system
 We need interfaces between the components
 To isolate them from one another
 To ensure the final system works
 The interfaces must not change (much)!
 Otherwise, development is not parallel
31
Comp 302
Defining Interfaces
 What are interfaces?
 They are just specifications!
 But of a special kind
 Interfaces are the boundaries between components
 And people
32
Comp 302
Defining Interfaces
 Specifying interfaces is most important
 Interfaces should not change a lot
 Effort must be spent ensuring everyone understands the
interfaces
 Both things require preplanning and time
 But often we can stop at specifying interfaces
 Let individual programmers handle the internals themselves
33
Comp 302
Software Architecture
 To define interfaces, we must decompose a system into
separate pieces with boundaries
 The decomposition of a system is driven by:
 What it does
 How we build it
 Who builds it
34
Comp 302
How We Build It
 Buildings need scaffolding during construction
 So does software!
 Two areas in particular:
 Lots of extra code that is not really part of the final product
 Influence of third-party subsystems
 Test harnesses, stubs, ways of building and running
partial systems
35
Comp 302
Who Builds It
 Software architecture reflects the structure of the
organization that builds it
 Often, 5 developers = 5 components
36
Comp 302
Summary of Issue 2
 Efficient development requires
 Decomposing system into pieces
 Good interfaces between pieces
 The pieces should be large
 Don’t try to break up into too many pieces
 Interfaces are specifications of boundaries
 Must be well thought-out and well communicated
37
Comp 302
Issue 3: Satisfies the User’s Needs
 Functionality & Usability




does what the user’s tasks require
easy to learn
efficient to use & error rates kept to a minimum
leads to high user satisfaction
 Bad (even if correct) user interfaces cost
 money (5% satisfaction -> up to 85% profits)
 lives (Therac)
 How to attack this issue?
 Capture user’s needs in the form of a requirements
document
 Iterate on this document, update throughout
lifecycle of project
38
Comp 302
Conclusions
 Software engineering boils down to two issues:
 Know what you want to do
 Develop an efficient plan for doing it
 Both require specifications
 To even define what you want to do
 To ensure everyone understands the plan
39
Comp 302
Outline of today’s lecture
 How important is software? Why?
 An overview of the software industry
 What is software engineering?
 The issues
 The constraints
 Key ideas underlying software engineering methodologies
 The software life cycle
40
Comp 302
Phases
Gather Requirements
Specification
Design
Implementation
Integration
Product
41
Comp 302
Cost of Finding Flaws Late
42
Comp 302