290 likes | 384 Views
Explore the Ada Lovelace historical perspective, good practices in design, testing methods, and development approaches. Learn the Waterfall, Iterative, and Common methods in FIO software development, alongside recommendations for a successful project approach.
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 ?