Software Engineering
How many lines of code?
Average CS1004 assignment:
• 200 lines
Average CS4115 project:
• 5000 lines
Corporate e-commerce project:
• 100,000 lines
Microsoft Windows Vista:
• 50,000,000+ lines
Writing a program is easy
– Program = code (with comments)
Developing a software system is harder
– System = program plus technical documentation
sufficient such that someone other than original
developers can maintain
Developing a software product is very hard
– Product = system plus customers, fulfilling the
business needs of those customers, with
customer-oriented documentation and support
“__________ was late,
took more memory
than was planned,
costs were several
times the estimate,
and it did not perform
very well until several
releases after the first”
“IBM OS/360 was late,
took more memory
than was planned,
costs were several
times the estimate,
and it did not perform
very well until several
releases after the first”
-Fred Brooks, 1975
What is Software Engineering?
• NOT just programming
• NOT just programming [part of] a large
software system
• NOT just programming as a member of a
large team
What is Software Engineering?
“The practice of creating and maintaining
software applications by applying
technologies and practices from
engineering, computer science, project
management, application domains and
other fields.”
-Wikipedia
Why do software projects fail?
Difficult to accurately estimate how long something will take
Why do software projects fail?
Developers typically overestimate/overstate their productivity
Why do software projects fail?
Requirements are not always clearly defined
Why do software projects fail?
Requirements are not always realistic
Why do software projects fail?
Requirements are always changing
Software development = tradeoffs
•
•
•
•
Cost vs Scope vs Quality vs Time
Security vs Performance
Specialization vs Generalization
Specificity vs Flexibility
Software Engineering
• Processes:
–
–
–
–
–
Project management (resources, time, etc.)
Requirements gathering & management
Software design & architecture
Software development
Testing and quality assurance
• Tools:
–
–
–
–
Software design, development, and testing
Communication
Requirements and defect tracking
Version control
Why Study Software Engineering?
• Writing a program is easy
– Program = code (possibly with comments)
• Developing a software system is harder
– System = program plus technical documentation
sufficient such that someone other than original
developers can maintain, typically involving
environmental interoperation (beyond just UI and file
system)
• Developing a software product is very hard
– Product = system plus customers, fulfilling the
business needs of those customers, with customeroriented documentation and support
Why Study Software Engineering?
• Software Engineering aims at supporting
the development of high-quality software
products
– High-quality software products are more
robust, efficient and effective
– High-quality software products are easier to
use, understand, modify, and compose with
other high-quality software products
But I just want to learn Java!!!
Software Engineering is still important!
• “Software Engineers” aren’t the only ones
who should know about software
engineering
• Creating high-quality software is
necessary in any case in which you or
someone else will need to maintain and/or
modify your code
Software Engineering Activities
•
•
•
•
•
•
•
System Engineering
Process Selection and Training
Requirements
– Eliciting
– Analysis
– Recording
Technology Selection and Training
Design
– Architecture
– Components
– Modules
Coding
– Unit Testing
– Debugging
Integration
– Build
– Integration Testing
– Configuration Management
•
•
•
•
System Testing
– Performance Testing & Optimization
– Acceptance Testing
– Beta Testing
Deployment
– Delivery
– Installation
Operations
– System Management
– Maintenance
– Upgrades
Support Activities
– Project Planning and Tracking
– Customer Interaction
– Process Improvement
– Training
– Documentation
– Personnel Management
In the Beginning…
Code-and-Fix
Build First
Version
Modify until
Customer satisfied
Operations
Retirement
Discussion of Code-and-Fix
• Really Bad
• Really Common
• Advantages
– No Overhead
– No Expertise
• Disadvantages
– No means of assessing progress
– Difficult to coordinate multiple programmers
• Useful for “hacking” single-use/personal-use programs:
start with empty program and debug until it works
Waterfall
Requirements
Validate
Design
Verify
Implementation
Test
Operations
Retirement
Discussion of Waterfall
• Articulated by Win Royce, ~1970
• Widely used today
• Advantages
– Measurable progress
– Experience applying steps in past projects can be used in
estimating duration of “similar” steps in future projects
– Produces software artifacts that can be re-used in other projects
• The original waterfall model (as interpreted by many)
disallowed iteration
–
–
–
–
Inflexible
Monolithic
Requirements change over time
Maintenance not handled well
• The “waterfall with feedback” model was, however, what
Royce had in mind
Waterfall*
REQUIREMENTS
ANALYSIS
SYSTEM
DESIGN
PROGRAM
DESIGN
CODING
UNIT & INTEGRATION TESTING
SYSTEM
TESTING
ACCEPTANCE
TESTING
OPERATION
& MAINTENANCE
Prototyping
Initial Concept
Design and
Implement
Initial Prototype
Refine Prototype
Until Acceptance
Complete and
Release
Prototype
Discussion of Prototyping
• Mock-ups allow users to visualize an application that
hasn't yet been constructed
• Used to help develop requirements specification
– Useful for rapidly changing requirements
– Or when customer won’t commit to specification
• Once requirements “known”, waterfall (or some other
process model) used
• Prototypes discarded once design begins
– Prototypes should not be used as a basis for implementation,
since prototyping tools do not create production quality code
– Customer (and management) may need to be “educated” about
prototypes: a prototype is not 80-90% of the final product, usually
not even 10%
Incremental (Staged)
Requirements
Validate
Architectural
Design
Verify
Detailed Design,
Implement, Test,
Deliver Feature Set
Operations
Retirement
Discussion of Incremental
• Iterations are classified according to
feature sets
– e.g., features 1 and 2 will be delivered in
this iteration, features 3 and 4 are next
• Series of increasingly “complete” releases
The Basic Problem: Risk
• Some modern approaches view “risk” as
the main problem of software development
– Schedule slips
– Business changes
– Staff turnovers
– New technologies
–…
Spiral Model
DETERMINE GOALS,
ALTERNATIVES,
CONSTRAINTS
EVALUATE ALTERNATIVES
AND RISKS
Risk analysis 4
Risk analysis 3
Risk analysis 2
Risk analysis 1
Budget 4
Budget 3
Budget
Budget 1
Prototype
1
Proto type 2
Proto type 3
Proto type 4
2
start
Requirements,
life-cycle plan
Detailed
design
Concept of
operation
Code
Unit test
PLAN
Implementation
plan
Acceptance
test
System
test
DEVELOP AND TEST
Discussion of Spiral Model
• Proposed by Barry Boehm, ~1986
• Similar to Incremental Model, but each
iteration is driven by “risk management”
and/or customer feedback
• Determine objectives and current status
• Identify risks and priorities
• Next iteration addresses (current) highest
risk and/or highest priority items
• Repeat
Agile Programming
Initial Concept
Requirements
and Iteration
Planning
Next Iteration
Design and
Implement
Acceptance
Testing
and Delivery
Operations
Discussion of Agile
• Each iteration a mini-project
– Each iteration’s deliverable is not a prototype, but an
operational system
– Understand risk vs. business value in planning
iterations
– Put some working functionality into user’s hands as
early as possible
• Timeboxing:
–
–
–
–
Set the date for delivering an iteration
Date cannot change
Only functionality (scope) can change
Short duration iterations (weeks, not months)
eXtreme Programming
eXtreme Programming
• Created by Kent Beck in late 1990s
• “Takes best practices to extreme levels”
• Focuses on five values:
– Communication
– Simplicity
– Feedback
– Courage
– Respect