Lecture 1 Think like an engineer George D. Ogden, Ph. D. [e-mail] or [e-mail]

1
Lecture 1 Think like an engineerGeorge D.
Ogden, Ph. D.ogden_at_cs.stevens.edu
orgeorge.ogden_at_stevens.edu
CS 540 Quantitative Software Engineering

2
Roadmap

• My history
• Class mechanics
• Quantitative Software Engineering
• Software Process Models
• CMM and the SEI
• Ethics of our profession
• Reading first chapter in Bernstein and Yuhas
  (BY)

3
George Ogden, Ph D Background

• 25 years at Bell Telephone Laboratories (and
  corporate successors)
• Project experience with NASA, DARPA, and Naval
  Personnel Research, Exxon, et. al.
• Small software company specializing in
  statistical analysis programming
• Human Factors/Industrial-Organizational Research

4
Class mechanics

• Review Syllabus
• Two texts plus supplementary reading
• 11 lectures- one chapter/week
• https//guinness.cs.stevens-tech.edu/lbernste/
• Two Exams 20 each
• Final - 40
• Log book - 20
• Testing will be from books, supplemental readings
  and lectures

5
Log Book/Homework/Projects

• Email me lecture summary, homework problem,
  article/reading summary, web site review, etc.
• email me logbook entries every week on Tuesday
  mornings by 800 AM.
• Logbooks should be part of your professional
  life, it is time to start!

6
Lecture Topics

• Think Like an Engineer Overview of QSE
• People, Projects, Products Software management
• Requirements
• Prototyping
• Architecture
• Estimation
• Risk Management
• Human Factors
• Implementation
• Testing

7
Birth of Software Engineering

• The software crisis, NATO conference, autumn
  1968, Garmisch, Germany
• Origin of term software engineering
• My thesis is that the software industry is
  weakly founded, and that one aspect of this
  weakness is the absence of a software components
  subindustry MD McIlroy
• https//guinness.cs.stevens-tech.edu/lbernste/
• select Trustworty Systems radial then NATO

8
Software Crisis Persists

• 250B spent on 175,000 projects with
• Average cost of projects large company 2.3M,
  medium 1.3M small .4M
• Almost a third will be cancelled before they are
  completed
• Over half will cost twice their current estimates
• Only 15 will be finished on time and on budget
• FAA Air Traffic Control project,
• Mars missions
• London Ambulance Dispatch System
• Airbus

9
Customers do not get what want
The National Software Council found this
situation largely unchanged in 1995 and 2005.
200,000 Used after rework
Abandoned or reworked
100,000 Used as delivered
Delivered but not used
A 1979 U.S. Government Accounting office report
(FGMSD-80-4), which breaks down results from
6.8 million in nine federal software projects,
shows that only 2 of the software was used as
delivered.
INFORMATION PROVIDED BY ACM SICSOFT SOFTWARE
ENGINEERING NOTES, VOL 10 NO. 5, OCTOBER 1985.
10
Viewpoint

• Bernstein and Yuhas ..think like an engineer,
  especially for software
• SE practices make development of software
• Less chaotic
• Reliably repeatable
• More humane
• Emphasis on simplification, trustworthiness, risk
  assessment and architecture

11
Views of Software Engineering

• SEI
• Engineering is the systematic application of
  scientific knowledge in creating and building
  cost-effective solutions to practical problems in
  the service of mankind.
• Software engineering is that form of engineering
  that applies the principles of computer science
  and mathematics to achieving cost-effective
  solutions to software problems.

12
Quantitative Software Engineering

• Quantitative Software Engineering is an
  analytical approach to producing reliable
  software products within budget and on time -
  Stevens QSE program
• Which matches the IEEE definition
• The application of a systematic, disciplined,
  quantifiable approach to the development,
  operation and maintenance of software that is
  the application of engineering to software

13
Software Engineering Knowledge (SWEBOK)

• Software requirements analysis
• Software design
• Software construction
• Software testing
• Software maintenance
• Software configuration management
• Software quality analysis
• Software engineering management
• Software engineering infrastructure
• Software engineering process

14
Reality check

• There is theory
• There are empirical models
• There is engineering
• There is a state-of-the-practice
• There is a state-of-the-art
• Why does the state-of-the-practice lag the
  state-of-the-art?

15
Software Process Models

• The cost of constructing most software occurs
  during development and not during production
• Process is a series of predictable steps, a
  roadmap
• We will cover
• Hacking
• Waterfall
• Prototyping
• Incremental
• RAD
• Spiral
• Agile

16
Hacking

• Code and Fix, Do Until Done Models
• No planning, general idea of product, informal
  design mostly through code
• Code, use, debug, test until ready for release
• No way to tell you are done or if requirements met

17
HACKING
Simplified Model
System
PROBLEM
Reqts Eng
Reqts Spec
Test
Maintain
Design
Code
Tech Spec
Implement
18
Royces Waterfall Model

• Phases in lockstep
• Encourages narrow focus
• Mistakes found late
• Generates tightly coupled systems

19
Waterfall Model with feedback
Reqts Eng
Design
Implementation
Test VV
Maintenance
20
Waterfall document-driven milestones

• Baselined Requirements Specification
• Baselined Test Plan
• Baselined Design Specification
• Baselined Code
• Test Results report

21
Waterfall process

• Change intolerant
• Document-driven
• Customer must state all requirements upfront, but
  fully 40 of requirements evolve
• Features unavailable until implementation phase
• Strong distinction between Development and
  Maintenance
• Came from an era when coding was difficult and
  computing was expensive
• Still in use

22
Why is Waterfall still used?

• Easy to understand
• Familiar to customers, steps make intuitive sense
• Natural Structure for new staff or teams
• Tight control by project management
• Requirements are stable
• Forces documentation

23
Prototyping by Barry Boehm
Build/revise mockup
Listen to customer
Customer test drives mockup
When finished Design, Implement, Test, Maintain
24
Development approach comparison
TRADITIONAL SOFTWARE PROCESS
PROTOTYPE BASED PROCESS
Systems Engineering Prototype
Systems Engineering
20
Final Development
Design, Develop, Test, Install
80
Deployment
Final Development, Deployment
40 REDUCTION
40
25
On prototyping

• Evolutionary versus throwaway prototypes
• Prototyping takes advantage of high level
  languages, sacrifices efficiency for speed
• Great when few initial requirements
• People (dev and users) like prototypes
• Danger of feature creep
• Documentation, performance of final system may
  suffer - perceived lack of discipline
• Customer and management may think it is done
• Quality can go either way
• Requires experienced developers

26
Incremental

• Functionality of system is produced and delivered
  in small increments
• prototyping waterfall - but focuses on
  delivery of operational product
• Focuses on assigning priorities to features for
  each release - Rolling Stones
• Especially useful with small staff, to manage
  technical risks and to build to current
  capability (e.g., hardware)
• Not good when delivery is expensive

27
Rapid Application Development (RAD)

• Incremental development
• Focus is on time to market
• JRPs (Joint Requirements Planning) - requirements
  triaged and JADs (Joint Application
  Design)-developers and users work together
  through prototyping to a finalized design
• Product developers are SWAT (Skilled with
  Advanced Tools) team
• Cutover- final testing of system takes place,
  users trained, system installed
• Best used in information systems where technical
  risks are low
• Typically 60-90 days

28
RAD advantages

• Customer involvement
• Tools reduce cycle time
• Project team usually knows problem domain, key
• Developers are willing to dive deeply into domain
  - key success factor in any model
• Time-box, usually 60 days, bounds development
• Installation and user training are an explicit
  part of the process

29
Spiral Development -Boehm

• Drives to reduce risks
• Recognizes that at each iteration you go through
  most phases
• At each iteration you pinpoint sub-problem with
  highest risk and solve
• Other models are subsumed

30
Boehms Spiral Model
Analysis
Design

• Incremental and iterative
• Evolutionary
• Prototyping quick feedback
• Continuous integration

Coding
Testing
31
Spiral Model
32
WinWin adds

• Life Cycle Objectives - goals for each major
  software activity
• Life Cycle architecture
• Initial Operation Capability - (site plan)
  preparation for software installation/distribution
  , site preparations before install (even for PCs)
  and assistance required by all relevant parties.

33
Spiral advantages

• Risk analysis may uncover show stoppers early
• Chunks development so that it is affordable
• Waterfall like characteristics add some
  discipline, management control
• Lots of feedback from all stakeholders

34
Spiral disadvantages

• Expensive for small projects
• Requires risk assessment expertise
• Development is on again/off again so the other
  stages can be accomplished - in prototyping
  development is continuous.
• It is a custom. More honored in the breach than
  the observance. William Shakespeare

35
Development plans (5ws and h)

• Every Project must have a development
• Who will do what?
• What will be done and what do you depend on?
• When will it be done?
• Where will it be done?
• Why will you do it?
• How will you do it?

36
Maintenance vs. Continuing Development

• Fix bugs
• Add features
• Improve structure and maintainability
• Zero defect philosophy
• End Support
• During the product lifecycle there is a tension
  between progressive and antiregressive activities

37
Software Engineering
Client Personal Computer
Client Workstation
Application Server
Large Data Server
38
Requirements issues(
Requirements Water Proto Spiral RAD Inc
Well known - - -
Defined early - -
Change often - - -
Proof of concept - -
Complex system - -
Early Functionality -
39
Software Engineering Institute

• http//www.sei.cmu.edu/
• The SEI promotes the evolution of software
  engineering from an ad hoc, labor intensive
  activity to a discipline that is well managed and
  supported by technology.
• Three themes
• Move to the left
• Reuse everything
• Never make the same mistake twice

40
Capability Maturity Model

• A roadmap for software process improvement
  (Paulk 1999)
• Describe an evolutionary process from ad hoc to
  maturity and discipline
• Used in conjunction with the SEIs IDEAL model
• Initiating the improvement program
• Diagnosing the current state of practice
• Establishing the plans for the improvement
  program
• Acting on the plans and recommended improvement
• Learning from it

41
CMM (Paulk, 1999)
LEVEL FOCUS KEY PROCESS AREAS
5 Optimizing Continual Process Improvement Defect prevention, Technology change management, Process change management
4 Managed Product and process quality Quantitative process management,Software quality management
3 Defined Engineering processes and organizational support Organization process focus, Organization process definition, Training program, Integrated software management, Software product engineering, Intergroup coordination, Peer reviews
2 Repeatable Project management processed Requirements management, Software project planning, software project tracking and oversight, Software subcontract management, Software QA, Software configuration management
1 Initial Competent people And heroics
42
Software Engineering Ethics

• TSQSE describes disasters due to failures in
  software engineering.
• Software projects are pressure cookers
• Software projects rely on relationships and trust
• IEEE Computer Society and ACM have developed a
  software engineering code of ethics with eight
  principles

Memorize the short form
43
Assignments

• Read Chapter 1TSQSE
• Read preface and chapter 1 of MMM
• Download SWEBOK
• Email me (ogden_at_cs.stevens.edu) 2-3 paragraphs
  summary of lecture 1
• Read Wikipedia article on Software Engineering

Memorize the short form
44
Key Question for Software Engineers

• Whats the problem?