290 likes | 428 Vues
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’
E N D
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’ • 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”
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…
Example: The Database • Single, consistent access method • Hide implementation details • Good performance • Ease of maintenance • Access control • Pre-compilation • Connection pooling
“Spend time on architecture not maintenance.” - Jean-Claude Wipple “Good and clear interfaces reduce bugs. Avoiding complexity reduces bugs.” - Linus Torvald
Testing • Apply principles of engineering to software • Bottom-up unit testing • Catch errors early • Cheaper • Less embarrassing • Saves time
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)
“For a successful technology, reality must take precedence over public relations, for nature cannot be fooled” - Feynman
Methods • Waterfall • Iterative • Common depends on scale of project…
Advantages Simple Stability - harder to introduce late changes Testers get early specifications to work from Project planning is easier Waterfall Method 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…
4. Programmer Implemented: 1. Customer requested: 2. Analyst Specified: 5. Installed: 6. Customer really needed: 3. Designer Specified:
Advantages Can calibrate and refine plan more accurate Working releases all through lower risk Allow reappraisal Whole development process regularly performed Iterative Method Disadvantages • Developers may keep writing fresh code, not bug fixing • Core product may need re-architecting with new functionality • Planning more complex • More chaotic
"A complex system that works is invariably found to have evolved from a simpler system that worked" - Gall 1986
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
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
…which we can evolve • Document templates • Code templates • Coding standards • Libraries • Reviews • Quality plans, testing • DevTestProduction environments • Release procedures • Widen scope beyond FIO ?