Software Engineering

1
Software Engineering
2
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

3

• 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

4

• __________ 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

5

• 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
6
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

7
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

8
Why do software projects fail?
Difficult to accurately estimate how long
something will take
9
Why do software projects fail?
Developers typically overestimate/overstate their
productivity
10
Why do software projects fail?
Requirements are not always clearly defined
11
Why do software projects fail?
Requirements are not always realistic
12
Why do software projects fail?
Requirements are always changing
13
Software development tradeoffs

• Cost vs Scope vs Quality vs Time
• Security vs Performance
• Specialization vs Generalization
• Specificity vs Flexibility

14
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

15
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
  customer-oriented documentation and support

16
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

17
But I just want to learn Java!!!
18
Software Engineering is still important!

• Software Engineers arent 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

19
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

20
In the Beginning
21
Code-and-Fix
22
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

23
Waterfall
24
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

25
Waterfall
26
Prototyping
Initial Concept
Design and Implement Initial Prototype
Refine Prototype Until Acceptance
Complete and Release Prototype
27
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 wont 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

28
Incremental (Staged)
29
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

30
The Basic Problem Risk

• Some modern approaches view risk as the main
  problem of software development
• Schedule slips
• Business changes
• Staff turnovers
• New technologies

31
Spiral Model
PLAN
DEVELOP AND TEST
32
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

33
Agile Programming
34
Discussion of Agile

• Each iteration a mini-project
• Each iterations deliverable is not a prototype,
  but an operational system
• Understand risk vs. business value in planning
  iterations
• Put some working functionality into users 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)

35
eXtreme Programming
36
eXtreme Programming

• Created by Kent Beck in late 1990s
• Takes best practices to extreme levels
• Focuses on five values
• Communication
• Simplicity
• Feedback
• Courage
• Respect