AGENDA
• Review Syllabus
- Course Overview
• Introductions
• The Software Crisis
- What is it?
- How real is it?
1
CISH-6050 - Software Engineering Management
AGENDA …
• Software Engineering Basics
and Definitions
- Software
 Quality
 Development
- Software Engineering
 Software Process Framework
 Software Processes
2
CISH-6050 - Software Engineering Management
AGENDA …
- Software Engineering
Management
• Software Process & Product
Quality
3
CISH-6050 - Software Engineering Management
The Software Crisis
What is it?
4
CISH-6050 - Software Engineering Management
Software Crisis Examples
• IRS – Business Systems
Modernization - $8B Upgrade
– Launched in 1999
– CADE- 1st software release 3 years
late & $36.8M over budget
– 8 other major projects missed
deployment deadlines
– Cost Overruns > $200M
5
CISH-6050 - Software Engineering Management
Software Crisis Examples …
Ongoing IRS Modernization Projects
IRS Project
Status
E-Services
2004
Deployments
2 years
$86M
Customer Account
1st release
Data Engine (CADE) August, 2004
3 years
$36.8
Integrated Financial
Target
System
October, 2004
1 year
$50M
Scheduled for
Spring, 2004
4 months
$17.1M
Custodial
First phase
Accounting Project August, 2004
20 months
$59.5M
Modernized E-file
Past Due $ Overrun
6
CISH-6050 - Software Engineering Management
Software Crisis Examples …
Completed IRS Modernization Projects
IRS Project
Status
$ Overrun
Security and Technology
Infrastructure Release 1
5 months late
$7.6M
Customer Communications 2001
9 months late
$5.3M
Customer Relationship
Management Exam
3 months late
($1.9M Under
budget)
Human Resource Connect
On time
$200K
Internet Refund Fact of Filing
14 months late
$12.9M
7
CISH-6050 - Software Engineering Management
Software Crisis Examples …
• Bank of America – MasterNet
– Spent $23M on an initial 5 year
accounting & reporting system
– Spent $600M trying to make it work
– Project cancelled
– Lost customer accounts - $Billons
8
CISH-6050 - Software Engineering Management
Software Crisis Examples …
• Allstate Insurance – In 1982
– $8M computer system to automate
business
– EDS providing software
– Initial 5 year project continued for
10 years, until 1993
– Cost approached $100M
9
CISH-6050 - Software Engineering Management
Software Crisis Examples …
• Blue Cross and Blue Shield of
Wisconsin - 1983
– EDS hired to build $200M computer
system
– Delivered on time in 18 months
– System didn’t work – issued $60M in
overpayments and duplicate checks
– BC lost 35,000 policy holders by 1987
10
CISH-6050 - Software Engineering Management
Software Crisis Examples …
• Therac-25: 1985 - 1987
– Computerized radiation therapy
machines made by Atomic Energy
Canada Limited (AECL)
– Massive radiation overdoses by the
Therac-25 between 6/85 and 1/87
– 4 deaths and serious injuries
– Original User Interface faulty, allowing
techs to administer high dosages
11
CISH-6050 - Software Engineering Management
The Software Crisis
• Software development projects
suffering from:
–
–
–
–
Cost overruns
Schedule delays
Reduced functional deliverables
Potential project cancellation
12
CISH-6050 - Software Engineering Management
Software Crisis Stats
• Standish Group ‘94 CHAOS Report:
– The US spends $250B on IT projects
– 31.3% of projects will be cancelled
before being completed
– 52.7% will cost 189% of original est.
– 78.4% of software projects deployed
with at least 74.2% of features
– $140B in project waste
13
CISH-6050 - Software Engineering Management
The Software Crisis
How did it start?
14
CISH-6050 - Software Engineering Management
The Software Crisis History
• 1950s and 1960s – Programs are
procedures to run hardware
– Procedural, sequential thought
process
– Assembler level coding languages
– Modules, interfaces, state machines,
data abstractions, etc. not familiar
concepts to most practitioners
15
CISH-6050 - Software Engineering Management
The Software Crisis History …
− Procedurally coded instructions led
to subroutines and macros
– Monitor programs evolved that could
invoke and provide services to other
programs
– Late 1960s, Monitor programs
evolved to operating systems
16
CISH-6050 - Software Engineering Management
The Software Crisis History …
• Late 1960s – Operating Systems
– Utility programs developed for
repeated data manipulation
– FORTRAN and COBOL
– Assembler programs with I/O
devices called at machine lang level
– New subsystems - Databases to
handle mass of data
17
CISH-6050 - Software Engineering Management
The Software Crisis History …
• 1970s – Software Properties
– Complex
 Rapid growth in size of apps
− Error Prone
 Inherited ‘spaghetti’ code
− Labor-intensive
 Very few good development tools
18
CISH-6050 - Software Engineering Management
The Software Crisis History …
• Cost overruns become the norm
− Software complex, labor intensive,
and high volume of errors
– More time needed than planned to
develop code
• More focus needed
– How software developed
– Process of developing software
19
CISH-6050 - Software Engineering Management
The Software Crisis History …
• 1970s - concepts & practices
developed to manage size and
complexity
− Lifecycle models
− Defect detection earlier in cycle
− Improved testing methodologies
− Design and code inspections
− Program proof of correctness
20
CISH-6050 - Software Engineering Management
The Software Crisis History …
• Despite improvements from the
1970s to 1980s, investing in
software development still
viewed as “bottomless pit”
− Highly error prone
− Labor-intensive
− Cost overruns
21
CISH-6050 - Software Engineering Management
The Software Crisis History …
• Early 1980s – hardware costs
decreased
• Software development & service
dominating cost factor
• Led to shift in industry:
− Defect Prevention
− Defect Removal
− Software Development Tools
22
CISH-6050 - Software Engineering Management
The Software Crisis – Why?
“The most likely way for the world to
be destroyed, most experts agree, is
by accident. That's where we come
in; we're computer professionals.
We cause accidents."
- Nathaniel Borenstein
23
CISH-6050 - Software Engineering Management
The Software Crisis – Why?
• Why are late deliverables and
poor quality tolerated?
• For other items:
– Defects not tolerated – cars,
appliances, homes, etc.
– High quality expected
– Compensation for defects
– Contractual obligation
24
CISH-6050 - Software Engineering Management
The Software Crisis – Why?
• Arguments – Valid or Invalid?
– Software is an art form; planning and
cost management will damage
creativity.
– Defect-free software can’t be
produced.
25
CISH-6050 - Software Engineering Management
The Software Crisis – Why?
• How long will this be tolerated?
– Until someone does it better
– Until the defects cause damage
• If there are no improvements and
customers don’t suffer intolerable
pain, the market place could
continue as it has
26
CISH-6050 - Software Engineering Management
The Software Crisis - Improving
• General public no longer shielded
from computers or software:
– Critical component in products
 Brakes cars, flies planes,
manages financial transactions,
runs machinery, etc.
– General public more intolerant of
software flaws
27
CISH-6050 - Software Engineering Management
The Software Crisis - Improving
• Is the Software Crisis real?
– Really a crisis?
– Or, a chronic affliction causing pain?
• Did (or will) it escalate as
originally predicted?
• If it’s improving, is it over now?
28
CISH-6050 - Software Engineering Management
The Software Crisis - Improving
• Robert Glass, author of a number
of books on software failures:
"I look at my failure stories and see
exception reporting, spectacular
failures in the midst of many
successes, a cup that is nearly full."
29
CISH-6050 - Software Engineering Management
The Software Crisis - Improving
• March, 2004 CHAOS Chronicles
Report shows big improvements:
– Project success rate increased to 34%
(1994: 16% success rate)
– Project failures rate declined to 15%
(1994: 31% failure rate)
– Challenged projects account for
remaining 51%
30
CISH-6050 - Software Engineering Management
The Software Crisis - Improving
– 51% of challenged projects have a
lower overrun ratio than in 2000
– 43% average cost overrun
(1994: 180% cost overrun)
– $55B spent on project waste
(1994: $140B project waste)
 $17B cost overruns (1994: $59B)
 $38B lost projects (1994: $81B)
31
CISH-6050 - Software Engineering Management
The Software Crisis - Improving
• Not all good news:
– Time overruns increased to 82%
(2000: 63% time overruns)
− 52% of required features/functions
make it in released product
(2000: 67% features in final product)
(1994: 74% features in final product)
32
CISH-6050 - Software Engineering Management
The Software Crisis - Improving
• Software Engineering and Software
Engineering Management are a
continued effort against the Software
Crisis
• Software and Software Engineering
Basics
33
CISH-6050 - Software Engineering Management
Software Fundamentals
• What is Software? (Pressman)
– Instructions that when executed
perform desired function
– Data structures that enable programs
to adequately manipulate information
– Documents that describe the operation
and use of programs
34
CISH-6050 - Software Engineering Management
Software Characteristics
• Developed or Engineered – not
“manufactured”
– Software is logical system element
– Software projects managed differently
than manufacturing projects
• Software doesn’t physically wear out
like hardware might
• Most software custom built
35
CISH-6050 - Software Engineering Management
Software
• Many Types
– Systems, Real Time, Business,
Scientific, Embedded, PC, Web, AI
• Products
– Generic or Packaged (COTS)
– Custom Built
• Sources
– Open (shareware)
– Closed (Proprietary)
36
CISH-6050 - Software Engineering Management
Software Quality
Expect software to contain sufficient:
– Usability
– Portability
– Learnability
– Efficiency
– Security
– Functionality
– Reliability and
Dependability
– Maintainability
37
CISH-6050 - Software Engineering Management
Software Quality …
• Some attributes are exclusive and
difficult to optimize
– Relationship of cost to improving each
attribute
– Cost vs. efficiency
Cost
Efficiency
38
CISH-6050 - Software Engineering Management
Software Development
Basic Development Activities
1. Understand problem (Requirements)
2. Identify possible solutions (Design)
3. Implement solution (Develop - code)
4. Ensure solution solves problem (Test)
5. Ensure solution continues to solve
problem (Lifecycle Management)
39
CISH-6050 - Software Engineering Management
Myth vs. Reality
• Myth #1
– General statement of objectives is
sufficient to begin writing programs;
the details can be filled in later.
• Reality #1
– Poor definition up front is major cause
of failed software efforts.
40
CISH-6050 - Software Engineering Management
Myth vs. Reality …
• Myth #2
– Project requirements continue to
change, but can be easily
accommodated – software is flexible.
• Reality #2
– Impact of change varies with the
phase it was introduced –
Requirements, Design, Code, Test
41
CISH-6050 - Software Engineering Management
Myth vs. Reality …
• Myth #3
– Once we write the program and get it
to work, our job is done.
• Reality #3
– The sooner you begin writing code,
the longer it will take to get done.
– 60%-80% of all effort expended after
delivered to customer for first time.
42
CISH-6050 - Software Engineering Management
Myth vs. Reality …
• Myth #4
– Until the program is running, there’s
no way to assess its quality.
• Reality #4
– SQA – Formal technical reviews can
be applied from the start of the
project.
43
CISH-6050 - Software Engineering Management
What is Software Engineering?
• Fritz Bauer (Naur, 1969)
– "The establishment and use of sound
engineering principles in order to
obtain economically software that is
reliable and works efficiently on real
machines.“
• Problems with this definition?
44
CISH-6050 - Software Engineering Management
Software Engineering …
• Sommerville (1995)
– "Software engineering is concerned
with the theories, methods, and tools
which are needed to develop the
software for these computers.“
• Problems with this definition?
45
CISH-6050 - Software Engineering Management
Software Engineering …
• IEEE (IEE93)
– " (1) The application of a systematic,
disciplined, quantifiable approach to
the development, operation, and
maintenance of software; that is the
application of engineering to software.
(2) The study of approaches as in (1).”
• Problem with this definition?
46
CISH-6050 - Software Engineering Management
Software Engineering …
• H. Younessi (SE 1)
– "Software Engineering is the collective
term applied to attempts to produce
high quality, complex, and large
software on a largely methodical and
reasonably sustainable basis with an
increasingly scientific and quantitative
orientation.”
• Scientific, Quantitative & Quality
47
CISH-6050 - Software Engineering Management
Software Engineering Process
• Principle Elements of SEP:
1.Methodology
2.People and Organizational Influences
3.Technology
• SEP – A mix of an instance of a
methodology, conducted within an
organizational content, utilizing a
specific set of technologies
48
CISH-6050 - Software Engineering Management
Software Process Framework
• Define Framework as a method or
approach to do something
– Example: Follow recipe to cook a
meal
• Software Process sometimes
inaccurately called a method or
methodology
49
CISH-6050 - Software Engineering Management
Software Process Framework …
• Is a Software Engineering Process
– The process of developing a piece of
code (i.e. using OO methodology)
– Or, is it the process of getting through
a software development project (i.e.
start to finish)?
• Different levels of “Process”
granularity
50
CISH-6050 - Software Engineering Management
Software Process Framework …
• Lower Level
– Describes steps to complete a task
– Methods by which work is done
• Higher Level
– By definition, process contains a
methodology component, as well as
organizational and technology
component
51
CISH-6050 - Software Engineering Management
Software Process Framework …
• Characteristics of Process
Framework:
– Understandable
– Enactable (instantitable)
– Repeatable
– Definable (well defined)
– Manageable (well managed)
– Improvable
52
CISH-6050 - Software Engineering Management
Software Process Framework …
• Development Models used in
Process Framework:
– Waterfall
– V-Model
– Spiral
– Evolutionary
– Rational Unified Process (RUP)
– OPEN
53
CISH-6050 - Software Engineering Management
Software Process Framework …
• Software Process should provide:
– Functionality - appropriateness of use
– Usability
– Clarity of definition
•Software Process (& Framework
that yielded it) should reflect:
– Methodology, Organization,
Technology
54
CISH-6050 - Software Engineering Management
Myth vs. Reality
• Myth #1
– We already have a book full of
standards & procedures for building
software, won't that provide everything
that my developers need to know?
• Reality #1
– Is the book used? Are developers
aware of it? Does it reflect current SE
standards?
55
CISH-6050 - Software Engineering Management
Myth vs. Reality
• Myth #2
– People have state-of-the-art software
development tools, since we buy them
the newest computers.
• Reality #2
– It takes more than the latest model
mainframe, PC, or workstation to do
high-quality software development –
CASE tools.
56
CISH-6050 - Software Engineering Management
Myth vs. Reality
• Myth #3
– Software Engineering will cause us to
create large amounts of unnecessary
documentation and will slow us down.
• Reality #3
– Software Engineering is not about
creating documents. It’s about creating
quality. Better quality leads to reduced
rework, resulting in faster delivery times.
57
CISH-6050 - Software Engineering Management
Myth vs. Reality
• Myth #4
– If we get behind schedule, we can add
more programmers and catch up
• Reality #4
– Software development is not a
mechanistic process like
manufacturing. In the words of Brooks:
"adding people to a late software
project makes it later."
58
CISH-6050 - Software Engineering Management
Software Engineering
Management
Why do Software Engineering
Management?
59
CISH-6050 - Software Engineering Management
Software Engineering
Management …
• SE subject to budget and
schedule constraints
• Project Management ensures
software development done
according to organization’s
constraints: policies, goals,
and requirements
60
CISH-6050 - Software Engineering Management
Software Engineering
Management …
Balance Schedule, Cost, Product
Cost
Product
Schedule
61
CISH-6050 - Software Engineering Management
Software Engineering Mgmt …
• Software Engineering Management
differs from other types of
engineering management
– Intangible product
– No standard process
– Large software projects often ‘one-off’
projects
62
CISH-6050 - Software Engineering Management
Software Engineering Mgmt …
• Software Engineering Management
Fundamentals
– Determine size of product
– Allocate resource for the product
– Create plan for utilizing resource
– Monitor project
– Measure project
63
CISH-6050 - Software Engineering Management
Software Engineering Mgmt …
• Effective Software Project
Management: 4 P’s
– People
– Product
– Process
– Project
64
CISH-6050 - Software Engineering Management
Recap
• The Software Crisis
• Software
– Quality
– Development
• Software Engineering
– Software Process Framework
– Software Processes
• Software Engineering Management
65
CISH-6050 - Software Engineering Management
References
• R. S. Pressman, Software Engineering: A
Practitioner's Approach, 5th ed., McGraw-Hill,
New York, 2001
• I. Sommerville, Software Engineering, 5th ed.,
Addison-Wesley, Reading, MA, 1995
• R. Radice, R. Phillips, Software Engineering:
An Industrial Approach, Prentice Hall,
Englewood Cliffs, NJ, 1988
• P. G. Neumann, Computer Related Risks,
Addison-Wesley, Reading, MA, January, 1995
66
CISH-6050 - Software Engineering Management
References …
• R. L. Glass, Software Runaways, Prentice Hall
PTF, Upper Saddle River, NJ, 1998
• N. G. Leveson, C. S. Turner, "An Investigation of
the Therac-25 Accidents," IEEE Computer, Vol.
26, No. 7, July 1993, pp. 18-41
• W. S. Humphrey, "The Changing World of
Software", Software Engineering Institute,
Carnegie Mellon University, December, 2001.
Available at
http://www.sei.cmu.edu/publications/articles/watt
s-humphrey/changing-world-sw.html
67
CISH-6050 - Software Engineering Management
References …
• H. Younessi, B. Henderson-Sellers, "Cooking up
Improved Software Quality: Developing reliable
and usable critical information systems with
processes", Object Development, October 1997,
pp. 38-42
• S. McConnell, Rapid Development: Taming
Wild Software Schedules, Microsoft Press,
Redmond, Washington, 1996
68
CISH-6050 - Software Engineering Management
References …
• The Standish Group, “The CHAOS Report
(1994)”. Available at
http://www.standishgroup.com/sample_research/
chaos_1994_1.php
• The Standish Group, “Latest Standish Group
CHAOS Report Shows Project Success Rates
Have Improved by 50%”, March 25, 2003.
Available at
http://www.standishgroup.com/press/article.php?
id=2
69
CISH-6050 - Software Engineering Management
References …
• E. Varon, “For the IRS There’s No EZ Fix”, CIO
Magazine, Vol. 17, No. 12, April 1 2004, pp. 5056. Also available at
http://www.cio.com/archive/040104/irs.html
70
CISH-6050 - Software Engineering Management