CS201: Software Development Methods

1
CS201 Software Development Methods
Course Unit 1 Modern Software Development

• Textbook readings
• MSD Chapter 1

2
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

3
How many classes in your largest program?

• 3 or fewer
• 4-6 classes
• 6-12 classes
• 13-20 classes
• more than 20 classes

4
Lines of code in your largest program?

• 200 or fewer
• 200 400
• 400 - 1,000
• 1,000 2,000
• 2,000 or more

5
Whats a Big Program?

• Table from the textbook

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

7
Whats 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

8
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 ATT Long Distance switches
• Network unusable for about 9 hours Jan 15, 1990.
• 1st major network problem in ATT'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

9
Ariane 5

• What we wanted

10
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."

11
Software Failures or Disasters (contd)

• 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

12
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 didnt 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

13
Definition of Software Engineering

• Fairleys 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.

14
SW Engineering Is About...

• Its about
• Engineering
• A systematic, careful, disciplined, scientific
  activity
• Building software systems, particularly larger
  ones
• Hacking or debugging until it works wont 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

15
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!
• Whats 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

16
Whats a Big Program?

• Table from the textbook

17
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

18
Analogy SE is like Construction

• Think about how buildings come to be
• Requirements
• Architecture
• Construction
• Differences?
• Maintenance
• Buildings dont change much
• Design
• Buildings really are less complex
• Number of states
• Remove one brick

19
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. Well see UML soon!

20
Relative Cost per Phase
21
Engineering Design (a la ENGR 162)

• Some sections of ENGR 162 talk about a
  three-phase 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

22
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.

23
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)

24
More on Design

• High-level or architectural design
• Describe major components of a larger system
• What they do, how they interact with other
  sub-systems (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!

25
(No Transcript)
26
Is this a requirements statement?
The software will allow the user to enter and
edit document information saved by the system.

• Yes
• No

27
Is this a requirements statement?
User query operations will complete in less than
5 seconds.

• Yes
• No

28
Is this a requirements statement?
The system will be written in Java and make use
of the HooGUI interface library.

• Yes
• No

29
Is this a requirements statement?
The connection manager in the system will
encapsulate all data related to network
connections and handle the cancel operation.

• Yes
• No

30
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

31
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!

32
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?

• 75, 15, 10
• 60, 20, 20
• 20, 60, 20
• 40, 20, 40

33
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!

34
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?

35
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

36
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

37
Development Lifecycles, Other Fields

• SW development lifecycle vs. other development
  lifecycles in engineering Different?
• Tell me! What have you learned about this in
  ENGR 162 or other engineering classes?
• Systems Engineering
• See what is systems engineering on INCOSEs
  websitehttp//www.incose.org/practice/whatissyst
  emseng.aspx
• Is there a lot thats common? Whats different?

38
Whats Next?

• Software quality
• Testing software
• Then, on to OO class design
• Inheritance
• Interfaces
• Etc.

39
Unused slides
40
Risk and SW Engineering

• Many problems arise because of risk
• Things happen that we didnt 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 dont work well enough
• etc.
• Good SEs work to manage and reduce risk

41
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

42
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