EEEGEF492 Midterm Review

1
EEE/GEF492Midterm Review
Royal Military College of Canada Electrical and
Computer Engineering

• Dr. Terry Shepard
• shepard_at_rmc.ca
• 1-613-541-6000 ext. 6031

Major JW Paul Jeff.Paul_at_rmc.ca 1-613-541-6000
ext. 6091
2
Software Wisdom

• The software industry is a race between software
  engineers striving to build bigger and better
  idiot-proof programs, and the Universe trying to
  produce bigger and better idiots. So far, the
  Universe is winning
• "Imagine if every Thursday your shoes exploded if
  you tied them the usual way. This happens to us
  all the time with computers, and nobody thinks of
  complaining." (Jeff Raskin)

3
Course Premise

• The basic premise of the course is that a better
  understanding of software processes and work
  products, both at the personal and at the
  organizational level, will make you a more
  effective contributor to improving the quality of
  software at a reasonable cost
• And if you never do that, at least you will have
  more sympathy for those who do
• What does this mean?

• How to control a large software project
• software processes and work products
• How to make quality software
• ilities
• Keeping these points in mind helps give focus to
  this course

4
Software planning

• What are these telling us?
• The bigger the project the more likely we are to
• underestimate the time (and resources) required
• fail

5
Practice vs Theory
6
What is Software Engineering?

• multi-person multi-version programming (Parnas)
• Software Engineering
• people/process/product oriented
• explores the limits of computing practice
• Computer Science
• artifact/algorithm oriented
• explores the limits of computing

7
Work Products
GENERIC
HOFFMAN STROOPER

• requirement
• outline solution
• detailed specs
• build the solution
• confirm

• Requirements Specification
• Module Guide
• Module Interface Specification
• Module Internal Design
• Module Implementation
• Test Plan
• Test Implementation

planning
coding
verification
only a small part of this is writing code (and
some consider that design) yet what have most of
your courses focus on?
There are many other work products - why?
8
Waterfall model

• Key Feature - Transition points
• completion of a defined work product
• formal evaluation and acceptance of the work
  product
• establishment of an official baseline

• Cons
• getting requirements right at start
• do one to throw away
• Momentum inhibits rework
• the volume of documentation
• transition implies consent and completion
• Can work well in small projects
• requirements generally better understood
• possible keep more of process active

System requirements
Analysis
Design

• Pros
• Encourages periodic review
• validation and verification,
• results in higher performance product,
• more closely matches the requirements
• Each phase results in document
• helps clarify decisions,
• provides an audit trail,
• serves as concrete milestone
• Formal transition from each phase
• results in a progressive setting of the
• product reduces unnecessary changes

Testing
Maintenance
9
Waterfall

• Economic Rational
• We have to do all these steps anyway
• (Barry Boehm, Software Engineering Economics,
  4.3, 1981)
• for small systems, the first 4 steps can be very
  light weight
• for larger systems, putting too little effort
  into the first four steps can be very costly
• Would doing the steps in any other order cost
  more?

10
Other options

• Incremental Waterfall
• build in small increments providing some
  fuctionalility
• Iterative (prototyping)
• refining solutions to a given work produce
• Evolutionary
• doing all parts multiple times

11
Incremental Waterfall Model
Can be used during conceptualisation, and/or
implementation phases
Requirements
Pros
Cons
Building small increments provides some immediate
functionality Flatter staffing curve
Still requires that requirements be fully defined
12
Iterative (prototyping)
Requirements
customer defines general objectives but unable to
identify detailed input, processing, or output
requirements
customer sees a working system, that is
probably buggy and unmaintainable
Analysis Design
some aspects of the design are poorly understood
and are therefore high risk
to solve key issues, compromises, short cuts are
taken and these can be implemented in the final
design
Implementation
customer wants too many features per cycle,
refactoring must be part of the cycle IOC may
require traditional approach
customer asks for too much, problems in
estimating effort, long development time-frames
13
Evolutionary Prototyping
Rapidly develop simple models of system get
rapid feedback clarify requirements reduce
uncertainty about design aspects (risk
reduction) some deliverables have no capability
Cons
missing comprehensive design phase conceptual
integrity may suffer may be impossible to
adequately tune performance once system is
complete management will be tempted to skip
design derivation and tuning phases without
strong management control, possible to iterate
endlessly difficult to schedule
14
Spiral Model
software lifecycle model that explicitly
recognizes risk as key driver
Key Features
Five key phases
Off-ramp
Work product development is non-uniform (what
else does this)
Spiral Essentials (why)
Concurrent Determination of Key Artifacts Each
Cycle Does all Five Phases Level of Effort Driven
by Risk Considerations Degree of Detail Driven by
Risk Considerations Use Anchor Point Milestones
LCO, LCA, IOC Emphasis on System and Life Cycle
Activities Artifacts
http//www.sei.cmu.edu/cbs/spiral2000/february2000
/Boehm/Boehm.PPT
Cons
Contracting may be difficult
Expertise in risk assessment critical
15
RUP
Framework that iterates the workflows
microprocesses across Engineering Construction
macroprocesses
RUP core concepts
Artifacts are output of process
Project Management Approach
Best Practices
Develop software iteratively Manage
requirements Use component-based
architectures Visually model software UML Verify
software quality Control changes to software
Match process to project
Integrated support tools
16
The Planning Spectrum
Milestone Risk- Driven Models
Adaptive Sw Devel.
Milestone Plan-Driven Models
Inch- Pebble Ironbound Contract
XP
Hackers


Agile Methods
Software CMM
CMMI
17
Lightweight Methods
Examples
RAD, Agile, XP
This part of the curve supports lighter weight
methods. It is not as important to get it
right initially
Why?
Reaction to documentation heavy methods
Generally, all lightweight methods come from
Need for faster development cycle
Successes on small projects
18
Agile and Plan-Driven Home Grounds
Agile Home Ground
Plan-Driven Home Ground

• Plan-oriented developers mix of skills
• Mix of customer capability levels
• requirements knowable early largely stable
• Architected for current and foreseeable
  requirements
• Refactoring expensive
• Larger teams, products
• Premium on high-assurance

• Agile, knowledgeable, collaborative developers
• Dedicated, knowledgeable, collaborative,
  representative, empowered customers
• Largely emergent requirements, rapid change
• Architected for current requirements
• Refactoring inexpensive
• Smaller teams, products
• Premium on rapid value

19
XP A set of interlocking practices

• Programming
• Team

• Process

Why?
The practices are designed to mutually support
one another. Each, in isolation, couldnt
possibly work.
20
(No Transcript)
21
Software Failures

• So, now we know how to make software, but how do
  we know if we got it right ( ?quality?)
• What is right
• does what the user wants, does what the user
  asked for, can be fixed to do what the user
  really needs, on time, on budget, first to market

Loss of life
Loss of data
Loss of money
22
What does quality software mean
-ilities
often these conflict!!!
all have a cost !!!
Usability, Flexibility, Adaptability,
Testability, Readability, Portability, Integrity,
Device independence, Self containedness,
Reusability, Interoperability, Efficiency,
Clarity, Device efficiency, Security, Robustness,
Cost, Completeness, Consistency, Accountability,
Accessibility, Safety, Understandability,
Reliability, Validity, Timeliness, Human
Engineered, Functionality, Self descriptive,
Fault tolerant, Accuracy, Structuredness,
Conciseness, Legibility, Augmentability,
Modifiability, Maintainability, Correctness,
Resilience, Generality, Minimality, Modularity,
Expandability, Trustworthiness,...
Cost
Reliability
Timeliness
Maintainability
Correctness
sometimes they can be grouped, but and why so
many?
23
if that is right, what is wrong?
a flaw in a work product
incorrect run-time behaviour
What has this course focused on and why?
24
Inspections

• What can you inspect?
• Any work product (not the worker)
• Big advantage

- do not need an executable work product
25
Testing

• What can you test?
• Any executable work product
• Big advantage

- can be automated
May need to touch certain statements with
different values
26
More Testing

• What is a Test Plan (what is wrong with Ad Hoc
  testing)
• a systematic approach to testing
• Ad Hoc testing is inefficient, non-repeatable
• What is the difference between black box and
  white box testing? Which is better?
• Black box functional testing (based on
  specifications)
• White box structural testing (based on
  implementation)
• How do you select test cases? Can you test
  everything?
• Interval testing, boundary conditions
• What is the importance of automated tools? Give
  examples of two.

http//www.cs.uvic.ca/ruskey/Publications/RedBlac
k/RedBlack.pdf
27
Time to get formal
http//www.ferg.org/papers/description_is_our_busi
ness.html

• Do we need a formal language to define
  specifications?
• The english language is too ambiguous

• Options
• set theory (MIS, MID, MSM)
• predicate logic
• specialized languages (SCR)

How does this relate to TDD
28
Specification Trichotomy
Critical to establish all behaviors
abnormal
normal
assumptions
exceptions
normal case
controlled behaviour
uncontrolled

• Characteristics of abnormal processing
• Illegal requests, e.g., trying to pop an empty
  stack.
• Resource limitations, e.g., running out of system
  memory while trying to create a new object.
• Difference between assumptions and exceptions
• if abnormal situations occur we will not handle
  them as the cost is too high, the chance too low,
  etc
• eg array pointers in C

29
Triple purpose documents
focus of design effort record design decisions
Design
what must be coded correctness baseline
Implementation
support change request structure for changes
Maintenance
When do they work?
When they are built to be used
When they feed directly into the next activity
When they capture why vice how
30
OSS

• What is it?
• Open does not mean free
• Why is it successful?
• largely (nearly all??) infrastructure software
  (developers are users)
• widespread freedom to question and drive changes
• many eyeballs make all bugs shallow (Linuss
  Law)
• common goals and expected evolution paths
• globally respected taboos/behaviours
• special processes unique to project (Mozilla
  super-review)
• personal stake
• What is the Cathedral and the Bazaar

31
COTS

• What are the critical difference between COTS
  processes and other processes
• Requirements must be flexible (why)
• You do not control/prioritize releases of
  features
• immediate functionality, cheaper initial cost
• integration issues
• increased post-purchase operational costs
• you do not control all your risks

32
KP Software Quality The Elusive Target

• What is the fundamental message of this paper?
• Quality depends on what you mean
• Transcendental View
• something that can be recognized but not defined.
• User View
• fitness for purpose
• Manufacture View
• conformance to specification.
• Product View
• dependent on the amount a customer is willing to
  pay for it.
• Measuring Quality is thus dependant on...

33
Baseli et al Evaluating COTS Component
Dependability in Context

• What is the Unified Model of Dependability?

34
PC A Rational Design Process How and why to
Fake It

• What was Parnas trying to say?
• What is a rational process
• Why would we want to fake it

35
Brooks Mythical Man Month

• What is a Mythical Man Month?
• Why is Brooks still relevant?
• Has he been wrong on any points?

36
Rodenberry
37
Top 12 Things Said By Klingon Programmers

• "Specifications are for the weak and timid!"
• "This machine is a piece of GAGKH! I need dual
  Pentium processors if I am to do battle with this
  code!"
• "You cannot really appreciate Dilbert unless
  you've read it in the original Klingon."
• "Indentation?! - I will show you how to indent
  when I indent your skull!"
• "What is this talk of 'release?' Klingons do not
  make software 'releases.' Our software 'escapes',
  leaving a bloody trail of designers and quality
  assurance people in its wake."
• "Klingon function calls do not have 'parameters'
  - they have 'arguments' -- and they ALWAYS WIN
  THEM."
• "Debugging? Klingons do not debug. Our software
  does not coddle the weak."
• "I have challenged the entire quality assurance
  team to a bat'leth contest. They will not concern
  us again."
• "A TRUE Klingon Warrior does not comment his
  code!"
• "By filing this SPR you have challenged the honor
  of my family. Prepare to die!"
• "You question the worthiness of my code? I should
  kill you where you stand!"
• "Our users will know fear and cower before our
  software! Ship it! Ship it and let them flee like
  the dogs they are!"

38
Questions?

• Good Luck