1 / 25

Understanding Software Development Styles: A Comparative Case of Bob and Joe

In this lecture, we explore the contrasting software development styles of Bob and Joe, focusing on the importance of models and requirements in the software development lifecycle. Bob relies on minimal planning and often writes project-specific code that cannot be reused, leading to delays. In contrast, Joe uses a structured approach, prioritizing client needs and building a well-defined system design. The lecture emphasizes the pitfalls of neglecting models and requirements, illustrating how both programmers' strategies ultimately impact project outcomes.

dylan
Download Presentation

Understanding Software Development Styles: A Comparative Case of Bob and Joe

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. Lecture 2:Software Life cycle

  2. Lazy

  3. Contemplative

  4. Always Using Imagination

  5. Most Important Trait

  6. Why Do Models Matter? • Client has 2 programmers with different styles Bob Joe

  7. More about Bob & Joe… Bob codes likeJoe paid attention & like he did in collegeuses a proper model

  8. Starting the Project • Both look at notes from project executive • Bob then writes test cases & starts coding • Joe determines client’s needs in meetings

  9. Project Getting Going • Bob duplicates code, but with minor tweaks • Slows progress & requires expensive reworking • Design minimizing code created by Joe • Client’s requirements examined; bugs found & fixed

  10. Passing the Halfway Point • Bob works from scratch & does not reuse code • Lacks plan to incorporate existing code • Joe uses design to write comments & outlines • Finds majority of errors during this process • When possible, merges classes & simplifies design

  11. Project Nearing Completion • Bob’s code is project-specific& cannot be reused • Getting concerned as project starts falling behind • Joe writes test cases from his system design

  12. Final Rush to the Deadline • Bob cannot describe system to get extra help • Completing system takes lots of all-nighters • Joe’s coding is easy with well-defined tests • Code could be written by (cheap) trained monkeys Bob Joe

  13. Final Rush to the Deadline • Bob cannot describe system to get extra help • Completing system takes lots of all-nighters • Joe’s coding is easy with well-defined tests • Code could be written by (cheap) trained monkeys Bob Joe Joe’s Team

  14. Final Accounting

  15. What’s The End Result? • Bob barely finishes • Most goalsare met • Occasionally crashes • Close to original goal • Joe is tanned & rested • Met stated goals • Reliable & robust • Follows design perfectly

  16. What’s The End Result? • Client fires them both • Neither met requirements • Bob barely finishes • Most goals are met • Occasionally crashes • Close to original goal • Joe is tanned & rested • Meets all needs • Reliable & robust • Exactly follows design

  17. Models Matter • Client valued original concept above all else • Joe and Bob both forgot about this main point • Joe gets better chair in unemployment line • To survive, life cycle models must succeed • Nobody records failures or the merely adequate • But common saying is “There is no silver bullet” • One shared weakness no matter your choices • Need to keep your focus on requirements • Keep in mind when being lazy

  18. Classroom Development • Always start from scratch • Know all requirements from the start • And requirements will not change • Coding begins immediately at start • Projects are trivial jokes in real-world • If lasts 3 weeks, projects “very large” • Code cannot be reused • Never look at again, anyway

  19. Why These Phases Matter

  20. Waterfall Model • Shows steps project goes through • Can compress, but steps never skipped • Assumes steps not revisited once done • Each step ends with some result • Evidence process followed correctly • Begin by testing results of previous

  21. Moving Target Problem • During development, requirements may change • Changes may be important, but… • …disrupts flow & introduces dependencies • Regression faults occur without good testing • Error (“fault”) usually in unrelated portion of project • Major pain to fix • As changes continue, faults will build up • Redesign & reimplementation ultimately needed • Change is inevitable • Your plans must handle gracefully

  22. Waterfall Model Is Iterative Waterfall Model Is Iterative

  23. Waterfall Model Is Iterative Waterfall Model Is Iterative Heck of a job, Brownie.

  24. Incremental Development • Waterfall improved by working incrementally • Focus on most important piece at the moment • Follow waterfall model to develop that piece • Focus on new most important piece once complete • Method also called stepwise refinement • Best of both worlds is incremental methods goal • Amount of duplicative work minimized • Improved reaction to change using smaller chunks • But handling changes requires good design & plans

  25. For Next Lecture • Reading for Mondayavailable on Angel • Will be discussing software requirements • What are they? • How do we figure them out? • Can they be discussed in our teams? • Weekly activity problem #2 due at start of class • Discussed at start of lecture, just like today • Available on weekly assignment page

More Related