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
• 80,000 lines
• Microsoft Windows Vista
• 50,000,000 lines

3
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

4
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

5
Over 50 of software projects fail

• Fred Brooks IBMs 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

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

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

12
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

13
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

14
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

15
But I just want to learn Java!!!
16
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

17
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

18
In the Beginning
19
Code-and-Fix
20
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

21
Waterfall
22
More Detailed Waterfall
23
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

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

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

29
The Basic Problem Risk

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

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

32
Agile Programming
33
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)

34
eXtreme Programming
35
eXtreme Programming

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

36
What does this mean for me?
37
Software Engineering in CS1007

• The programs you write in this class will graded
  as much on their quality as on their
  functionality
• This means that they should be
• Well-designed
• Robust and well-tested
• You need to come up with your own personal
  software process to ensure the quality of the
  code you write