Embed Size (px)
DESCRIPTION
FIO Development Process. Bill Tomlin. Introduction. Historical perspective Good practice Design Testing Development methods compared Recommendations. Ada – Enchantress of Numbers. Born December 10, 1815 1842 plan to calculate Bernoulli numbers using Babbage’s ‘Difference Engine’ - PowerPoint PPT Presentation
Citation preview
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 ?
