1 / 29

FIO Development Process

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’

lillith-gray
Download Presentation

FIO Development Process

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. FIO Development Process Bill Tomlin

  2. Introduction • Historical perspective • Good practice • Design • Testing • Development methods compared • Recommendations

  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”

  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…

  5. Example: The Database • Single, consistent access method • Hide implementation details • Good performance • Ease of maintenance • Access control • Pre-compilation • Connection pooling

  6. “Spend time on architecture not maintenance.” - Jean-Claude Wipple “Good and clear interfaces reduce bugs. Avoiding complexity reduces bugs.” - Linus Torvald

  7. Testing • Apply principles of engineering to software • Bottom-up unit testing • Catch errors early • Cheaper • Less embarrassing • Saves time

  8. January 28, 1986

  9. An “O-ring” fails

  10. “Major malfunction”

  11. 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)

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

  13. Methods • Waterfall • Iterative • Common depends on scale of project…

  14. …can be a lot of dogs to house

  15. Waterfall Method

  16. 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…

  17. 4. Programmer Implemented: 1. Customer requested: 2. Analyst Specified: 5. Installed: 6. Customer really needed: 3. Designer Specified:

  18. Iterative Method

  19. 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

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

  21. Common Method

  22. 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

  23. Recommendations…

  24. 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

  25. …which we can evolve • Document templates • Code templates • Coding standards • Libraries • Reviews • Quality plans, testing • DevTestProduction environments • Release procedures • Widen scope beyond FIO ?

  26. Questions/Comments ?

More Related