FIO Development Process

17 Dec 2002

FIO Development Process

Bill Tomlin

17 Dec 2002/BT 2

Introduction

Historical perspective Good practice

Design Testing

Development methods compared Recommendations

17 Dec 2002/BT 3

Ada – Enchantress of Numbers Born December 10, 1815 1842 plan to calculate Bernoulli

numbers using Babbage’s ‘Difference Engine’

First programmer 1979 ADA language

“I am much annoyed at your having altered my Note. You know I am always willing to make any required alterations myself, but that I cannot endure another person to meddle with my sentences”

17 Dec 2002/BT 4

Good Practice: Design Top-down, Use Case driven Identify high-level components Decide interfaces Apply to sub-components Low coupling, high cohesion A simple model says a lot…

17 Dec 2002/BT 5

: BuyerSeller : GoI : Aggregator

Create Socket

Listen

Select Escrow

Escrow Application Form

Completed Form

Socket Connection

Send Fields (XML)

Confirmation (XML)

Close Socket

Confirmation (HTTP)

17 Dec 2002/BT 6

Example: The Database

Single, consistent access method Hide implementation details Good performance Ease of maintenance Access control Pre-compilation Connection pooling

17 Dec 2002/BT 7

“Good and clear interfaces reduce bugs. Avoiding complexity reduces bugs.” - Linus Torvald

“Spend time on architecture not maintenance.” - Jean-Claude Wipple

17 Dec 2002/BT 8

Testing

Apply principles of engineering to software Bottom-up unit testing Catch errors early

Cheaper Less embarrassing Saves time

17 Dec 2002/BT 9

January 28, 1986

17 Dec 2002/BT 10

An “O-ring” fails

17 Dec 2002/BT 11

“Major malfunction”

17 Dec 2002/BT 12

What went wrong…

Rubber used to seal joints failed to expand at 0ºC

The component wasn’t tested in the right way

The engineer wasn’t listened to The risk assessment was wrong

(1/100 000 vs. 1/100)

17 Dec 2002/BT 13

“For a successful technology, reality must take precedence over public relations, for nature cannot be fooled” - Feynman

17 Dec 2002

Methods

Waterfall

Iterative

Common

depends on scale of project…

17 Dec 2002/BT 15

2

Architecting a dog house

Can be built by one personRequires

Minimal modelingSimple processSimple tools

2

Architecting a dog house

Can be built by one personRequires

Minimal modelingSimple processSimple tools

…can be a lot of dogs to house

17 Dec 2002/BT 16

3

Architecting a house

Built most efficiently and timely by a teamRequires

ModelingWell-defined processPower tools

3

Architecting a house

Built most efficiently and timely by a teamRequires

ModelingWell-defined processPower tools

17 Dec 2002/BT 17

4

Architecting a high rise

4

Architecting a high rise

17 Dec 2002/BT 18

Waterfall MethodRequirements

Design

Implementation

Test

Analysis

17 Dec 2002/BT 19

Waterfall Method

Advantages Simple Stability - harder to

introduce late changes Testers get early

specifications to work from

Project planning is easier

Disadvantages Risky - no early working releases Inflexible – can’t change

requirements or design Cannot respond to changing

circumstance Testing late and on critical path Projects usually too late and too

expensive Communications can break

down…

17 Dec 2002/BT 20

1. Customer requested:

2. Analyst Specified:

3. Designer Specified:

4. Programmer Implemented:

5. Installed:

6. Customer really needed:

17 Dec 2002/BT 21

Iterative Method

ProjectInitiation

Elaboration

increment #1

increment #2

increment #n

... ... ...

TransitionProjectClosure

Maintenance

Construction

17 Dec 2002/BT 22

Iterative Method

Advantages Can calibrate and

refine plan more accurate

Working releases all through lower risk

Allow reappraisal Whole development

process regularly performed

Disadvantages Developers may keep

writing fresh code, not bug fixing

Core product may need re-architecting with new functionality

Planning more complex More chaotic

17 Dec 2002/BT 23

"A complex system that works is invariably found to have evolved from a simpler system that worked" - Gall 1986

17 Dec 2002/BT 24

Common Method

17 Dec 2002/BT 25

Development in FIO…

Lack of clear method Good people but high turnover Assumed knowledge Fragmented information Interesting production environments Sporadic use of CVS, SourceSafe Eclectic, wordy document content, if they exist High coupling between components

17 Dec 2002/BT 26

Recommendations…

17 Dec 2002/BT 27

Start with a simple process… An “FIO project approach” document Standard set of project artifacts

Requirements - what Design (UML) - how Code, makefiles, sql Instructions: how to build & deploy

All artifacts in CVS/SourceSafe Single repository for FIO Obvious location Consistent naming All DB access via stored procedures

17 Dec 2002/BT 28

…which we can evolve

Document templates Code templates Coding standards Libraries Reviews Quality plans, testing DevTestProduction environments Release procedures Widen scope beyond FIO ?

17 Dec 2002/BT 29

Questions/Comments ?