CS2110: Software Development Methods
Intro. to Software Engineering
• Textbook readings:
• MSD: Chapter 1
Goals for this Course Unit
• To introduce students to all aspects of software
development (not just programming)
• Course objective #5:
• Comprehend important basic concepts of software
engineering and the development of large
software systems, including the software lifecycle,
requirements, design, and software quality…
• Software development is about more than:
• Syntax, rules, libraries to use, a Java environment
• Computer Science is also about more than these
things and also more than SW development
How many classes in your largest program?
1.
2.
3.
4.
5.
3 or fewer
4-6 classes
6-12 classes
13-20 classes
more than 20 classes
Lines of code in your largest program?
1.
2.
3.
4.
5.
200 or fewer
200 – 400
400 - 1,000
1,000 – 2,000
2,000 or more
What’s a Big Program?
• Table from the textbook:
Category
Programmrs
Duration
Product Size
(Lines of Code)
Trivial
1
1 - 4 weeks
< 500
Small
1-2
1 - 6 months
500 - 3,000
Medium
2-5
6 mo - 2 yrs
3,000 - 20,000
Large
5 - 20
2 - 3 yrs
20,000 - 100,000
Very Large
20 - 200
3 - 6 yrs
100,000 - 1,000,000
Extremely
Large
> 200
> 6 yrs
> 1,000,000
Roadmap of Topics in Unit 1
• What is software engineering? What problems
does it address?
• What is the software development lifecycle?
• What is involved in the phases of the SDLC?
•
•
•
•
•
Requirements and specification
Design (high-level and low-level)
Implementation
Integration and verification
Maintenance (AKA evolution)
• What is a SW development methodology?
What’s the Problem?
• Software costs are increasing as hardware costs
decline.
• Many software development disasters:
• Cost overruns, late delivery
• Reduced or wrong functionality, non-existent
documentation
• Many failures attributed to software
• Cost of failure becoming very high:
• Financial
• Loss of life or loss of equipment
• Inconvenience
Software Failures or Disasters
• Shuttle launch anomaly
• Launch 3 years late, millions over cost
• 1st launch cancelled on pad
• 2 years earlier, delay factor changed in software from 50 ms
to 80 ms
• Outages of AT&T Long Distance switches
• Network unusable for about 9 hours Jan 15, 1990.
• 1st major network problem in AT&T's 114 years
• Ariane 5 launch explosion, 4 June 1996
• Short summary of report:
http://www.esa.int/esaCP/Pr_33_1996_p_EN.html
Ariane 5
• What we wanted:
Ariane 5
• What we got!
•
“The failure of Ariane 501 was
caused by the complete loss of
guidance and attitude
information… This loss of
information was due to
specification and design errors in
the software of the inertial
reference system. The extensive
reviews and tests carried out
during the Ariane 5 development
programme did not include
adequate analysis and testing of
the inertial reference system or of
the complete flight control system,
which could have detected the
potential failure."
Software Failures or Disasters (cont’d)
• Social Security disaster
•
•
•
•
System started in 1980 by Sperry
In 1985, inadequate, 100% cost overrun
$90M equipment added
Late refunds caused the IRS to pay:
• $40.2M in interest
• $22.3M in over-time
• Space Defense Operations Center (SPADOC)
• $147M more than estimate
• 7-8 years late
• Death and injury from Therac 25
We have a “software crisis” (1968)
• “Software Engineering” term coined in 1968
• NATO conference in Garmisch, Germany
• An “early” study of “problem” DOD projects
• 47% of software delivered could not be used
• Usually didn’t meet requirements
• 29% of funded software never delivered
• Usually canceled due to cost/schedule overruns
• 19% of software useful after extensive rework
• Costs 36 times more to fix problems after release
Definition of Software Engineering
• Fairley’s definition:
• Software engineering is the technological and
managerial discipline concerned with systematic
production and maintenance of software products
that are developed and modified on time and within
cost estimates.
• Engineering versus science:
• Production, practical, quality, maintenance, reuse,
standards, teams, management, etc.
SW Engineering Is About...
• It’s about:
• Engineering
• A systematic, careful, disciplined, scientific activity
• Building software systems, particularly larger ones
• Hacking or debugging until it works won’t work
• Modifying software systems over time
• Not just focused on creating new applications.
• Programming may be fun, but SW Engin. should
not be considered:
• Easy, simple, boring or pointless
One Way to Think About It
• Build a bridge to cross a small creek
• Cut down a tree. Drop a board across it.
• Build a bridge across the Golden Gate
• Need a big tree!
• What’s different?
• Size of project matters. Number of people involved.
How long does it has to last. Risk. Economics.
• “Programming in the large” vs. “Programming in
the small”
What’s a Big Program?
• Table from the textbook:
Category
Programmrs
Duration
Product Size
(Lines of Code)
Trivial
1
1 - 4 weeks
< 500
Small
1-2
1 - 6 months
500 - 3,000
Medium
2-5
6 mo - 2 yrs
3,000 - 20,000
Large
5 - 20
2 - 3 yrs
20,000 - 100,000
Very Large
20 - 200
3 - 6 yrs
100,000 - 1,000,000
Extremely
Large
> 200
> 6 yrs
> 1,000,000
Software Lifecycle and Phases
• Stages or phases that are typical in software
development, from “birth” to “death”
• There are various different lifecycle models of
how we move through these (more later)
• Phases might include:
•
•
•
•
•
Requirements phase (also a Specification phase)
Design phase
Implementation phase
Integration or “testing” phase
Maintenance phase
• Also maybe “conception” and “planning”
Analogy: SE is like Construction
• Think about how buildings come to be:
• Requirements
• Architecture
• Construction
• Differences?
• Maintenance
• Buildings don’t change much
• Design
• Buildings really are less complex
• Number of states
• Remove one brick
Requirements, Design, and Implementation
• Requirements
• Statements of what the system should do (or
what qualities it should have)
• From the customer or client point of view
• Not expressed in terms of a solution
• Design
• A description of how we will implement a solution
• A model or blueprint for meeting requirements
• Done before implementation, so it can be
evaluated
• Many possible designs for a set of requirements. How to
choose?
• Often models are used to describe either of
these. We’ll see UML soon!
Relative Cost per Phase
2%
Requirements
5%
Specification
Design
6%
5%
7%
Module coding
Module testing
Integration
8%
67%
Maintenace
Engineering Design (a la ENGR 1620)
• Some sections of ENGR 1620 talk about a threephase view of engineering design
• Problem Formulation
• Recognize needs; gather info on needs; determine
requirements of the project
• Problem Solving
• Identify and analyze alternatives to meet
requirements; choose and specify details for one
alternative
• Solution Implementation
• Create a plan for implementation and testing; build it;
evaluate it against requirements
More on Requirements
• Reminder: Requirements are…
• Statements of what the system should do (or what
qualities it should have)
• From the customer or client point of view
• Not expressed in terms of a solution
• Class program assignments are and are not like
requirements documents. How?
• Like: Should be clear, unambiguous statements of
what must be done. Must be consistent, complete,
feasible, “testable”
• Not like: Often say how to do it (what classes, what
methods, etc). Also, not for a “real” customer.
Types of Requirements
• Functional requirements
• describes a function or activity the system will carry
out
• Perhaps in response to input(s)
• Describes the state of the system (or parts of the
system) before and after an activity occurs
• Non-functional requirements
• What else might we want to describe? Suggestions?
• Qualities: efficiency, reliability, usability, etc.
• Constraints:
• On its design: Must run on certain platform, use particular
components, etc.
• On how its built: Must be built in a certain way (i.e. DOD
standard process)
More on Design
• High-level or architectural design
• Describe major components of a larger system
• What they do, how they interact with other subsystems (control, information flow)
• Often diagrams (but few standard notations)
• Lower-level or detailed design
• For OO, what are the classes
• Even lower, how are certain methods implemented
• Algorithms
• Notations: the Unified Modeling Language (UML) for
OO design
• Note: Should have good requirements
descriptions before doing any of this!
Is this a requirements statement?
The software will allow the
user to enter and edit
document information saved
by the system.
1. Yes
2. No
Is this a requirements statement?
User query operations will
complete in less than 5
seconds.
1. Yes
2. No
Is this a requirements statement?
The system will be written in
Java and make use of the
HooGUI interface library.
1. Yes
2. No
Is this a requirements statement?
The connection manager in
the system will encapsulate
all data related to network
connections and handle the
cancel operation.
1. Yes
2. No
Reminders: Requirements vs. Design
• Requirements:
• The problem statement: what the system should do
• Functional requirements
• Non-functional requirements: constraints, qualities
• Design
• Describes one possible solution: how to meet the
requirements
• Must meet requirements
• Can be used to build (like blueprints)
• High-level vs. low-level design
• E.g. “Subsystems” vs. class-design
Why Is Maintenance Expensive?
• Good software is maintained. Bad software is
discarded. (Success has a long-term cost!)
• Different types of maintenance
• Corrective maintenance
• Fix defects after release
• Perfective maintenance
• Enhance to add new features etc.
• Adaptive maintenance
• Make it work in changing environment
• Maintenance matters and costs even if released
code has zero defects!
Costs of types of maintenance?
Different types of maintenance
•Corrective maintenance: Fix defects after release
•Perfective maintenance: Enhance to add new
features etc.
•Adaptive maintenance: Make it work in changing
environment
How much of total maintenance costs goes to each?
1.
2.
3.
4.
75%,
60%,
20%,
40%,
15%,
20%,
60%,
20%,
10%
20%
20%
40%
Why Is Maintenance Expensive?
• Good software is maintained. Bad software is
discarded. (Success has a long-term cost!)
• Different types of maintenance
• Corrective maintenance [20%]
• Fix defects after release
• Perfective maintenance [60%]
• Enhance to add new features etc.
• Adaptive maintenance [20%]
• Make it work in changing environment
• Maintenance matters and costs even if released
code has zero defects!
Source of Defects by Phase
• 60 to 70 % of faults are from specification or
design
• One example: (Data of Bhandari et al. [1994])
Faults found at end of design phase of new
version of a product
• 13% of faults from previous version of product
• 16% of faults in new specifications
• 71% of faults in new design
• Faults discovered later in the lifecycle cost
significant more to fix? Why?
Cost to Correct Faults Increases by Phase
• If found late, how much more expensive to fix?
• Say the problem is in the requirements
• If you found it immediately, it costs $X to fix
• But you find it later in the lifecycle -- how much
more does it cost to fix?
•
•
•
•
4x as expensive if found and corrected in design
10x as expensive … in implementation
30 – 52 x as expensive … in integration
200 – 368 x as expensive … in maintenance
Importance of “Front-End” Activities
• Much better to find problems early!
• Reminder:
• More serious errors occur there
• More expensive to fix them
• Thus, a principle:
• Do better early (requirements and design)!
• And also:
• Coding matters, but in the big picture other things
matter a lot too
Development Lifecycles, Other Fields
• SW development lifecycle vs. other development
lifecycles in engineering: Different?
• Tell me! What have you learned about this in
ENGR 1620 or other engineering classes?
• Systems Engineering
• See “what is systems engineering” on INCOSE’s
website:
http://www.incose.org/practice/whatissystemseng.aspx
• Is there a lot that’s common? What’s different?
What’s Next?
• Software quality
• Testing software
• Then, on to OO class design
• Inheritance
• Interfaces
• Etc.
Unused slides
Risk and SW Engineering
• Many problems arise because of risk
• Things happen that we didn’t anticipate
• Example problems
•
•
•
•
•
•
•
Wrong requirements
Critical staff leave project
Bad design requires later re-design
Expected new HW or SW fails to arrive or work
Schedule plan turns out to be too optimistic
Tools don’t work well enough
etc.
• Good SEs work to manage and reduce risk
Managing Risk
• Risk areas
•
•
•
•
•
Personnel
Schedule and budgets
Wrong functionality created
Requirements are volatile
SW Development is harder than we thought!
• How to identify, manage and reduce risk
•
•
•
•
Prototyping
Simulation
Modeling
Planning and management
Comparative Cost Per Phase
• Data on this slide from two sets of projects:
• Various projects between 1976 and 1981
• 132 more recent Hewlett-Packard projects [Grady, 1994]
• Note: not including maintenance costs
Project Set
#1
Project
Set #2
Planning, Req., Spec.
21%
18%
Design
18%
19%
Implementation
36%
34%
Integration
24%
29%