Upstream Prerequisites
“Measure Twice, Cut Once”
Before construction, preparations must be
made.
 These preparations are custom built to the
projects specific needs
 The success or failure of the project is
determined before the construction
begins.
 “Measure twice, cut once”: construction
can account for up to 65% of total project
cost.

“Blueprints”

High quality practices = high quality
software.
◦ Quality start: Focus on planning
◦ Quality middle: Focus on construction
◦ Quality End: Focus on testing
The goal of preparation is risk reduction.
Most common project risks are poor
requirements and planning.
 Preparation for construction is not an
exact science.


Importance of Prerequisites

Causes of Incomplete preparation
◦ Developers with lack of expertise.
◦ “I want to code now!!!!” : Coding ASAP
◦ “I want to SEE code now!!”: Unsympathetic
managers
 Refuse, Trick, Educate, Relocate

Educate people about the development
process.
◦ Appeal to logic
◦ Use Analogies
◦ Show the data
Importance of Prerequisites

Boss Test
◦ We’d Better start coding right away because
we’re going to have a lot of debugging to do.
◦ We haven’t planned much time for testing
because we’re not going to find many defects.
◦ We’ve investigated requirements and design so
much that I can’t think of and major problems
we’ll run into during coding or debugging.
Importance of Prerequisites
Different kinds of software projects
require different balances between
preparation and construction.
 Projects tend to fall into development
styles.

◦ Business Systems
◦ Mission-Critical Systems
◦ Embedded Life- Critical Systems
“What software am I working
on?”

Business Systems
◦ Internet site, Games, Management information
systems, Payroll
◦ Planning is interleaved with construction
◦ Less quality assurance activities, done in
house.
◦ Informal
“What software am I working
on?”

Mission –Critical Systems
◦ Embedded software, Software tools, Web
services
◦ Up- front planning and semi-formal
requirements
◦ Informal check-ins while coding
◦ Testing with a separate group. (In house
always done)
“What software am I working
on?”

Embedded Life- Critical Systems
◦ Avionics software, Medical devices, Operating
Systems
◦ Formal and extensive planning, requirements,
and design
◦ Formal check-ins while coding
◦ Extensive out of house testing.
◦ Everything must go correctly
“What software am I working
on?”

Sequential approach
◦ Upfront prerequisites
 Requirements are stable
 Design is straightforward
 Low risk project
 Long term predictability
 High change cost.
“What software am I working
on?”

Iterative approach
◦ As you go prerequisites
 Unclear requirements
 Complex design
 Lots of risks
 Long term is not important
 Low change cost.

Adapt approaches based on your specific
project.
“What software am I working
on?”
“Mission Statement”
 Problem definition defines what the
problem is without a reference to a
solution.
 If it sounds like a problem it is a good
problem definition.
 “GGC students have a hard time
managing all they have to do at the
school.”

Problem-Definition Prerequisite
Problem definition lays the foundation of
the programming process.
 State the definition in the users language
and not in computer terms.

◦ The best solution may not require
programming.

Exception: When it deals with computers
◦ Programming tools are buggy, compile times
are slow, ect.
Problem-Definition Prerequisite






Requirements describe in detail what a
software system is supposed to do.
First step toward a solution.
Allows the user to determine system
functionality.
Minimizes changes mid project.
Stable requirements don’t really happen
but must be strived for.
On average a 25% change in
requirements is bound to happen.
Requirements Prerequisite

How to handle requirement changes.
◦ Requirement checklist at the end of each
section
◦ Make the change cost known to everyone
◦ Set up a change-control procedure
◦ Use development approaches that can
accommodate changes.
◦ If all else fails: Dump the project. (Or at least
think about it)
Problem-Definition Prerequisite
Software architecture is the high-level
part of software design.
 The frame that holds the detailed parts
together.
 A single document that defines constraints
that apply system wide.
 Provides guidance to programmers
because it is detailed to the skills of the
coders.

Architecture Prerequisite

Architectural Components
◦ Program Organization
 How many subsystems, what are the building
blocks
◦ Major Classes
◦ Data Design
 Major files and tables
◦ Business Rules
◦ User Interface Design
◦ Input/Output
Problem-Definition Prerequisite

Architectural Components Con’t
◦
◦
◦
◦
Resource Management
Security
Performance
Scalability
 Growth?
◦ Interoperability
◦ Localization
◦ Error Processing
Problem-Definition Prerequisite

Architectural Components Con’t
◦
◦
◦
◦
◦
◦
◦
Fault Tolerance
Architectural Feasibility
Overengineering
Buy vs Build
Reuse Decisions
Change Strategy
General Architectural Quality
Problem-Definition Prerequisite
10 to 20% of its effort and 20 to 30% of
its time.
 Allow time to consult the requirements
and for revisions.
 Treat requirements as its own project if
necessary.
 Smaller the project, less time necessary.

How much time to spend on
upstream prerequisites






Main goal is risk reduction
Educate everyone about the development
process.
Different projects means different
prerequisites. (Iterative vs Sequential)
Problem definition
Requirements
Architectural design
Key Points