1 / 58

Feature Driven Development

Feature Driven Development. Reid S. Carlberg SE470 http://www.fivesticks.com/info/fdd. Feature Driven Development. Abstract Historical background Description Usage guidelines Marketplace analysis References. Abstract.

keane-byers
Download Presentation

Feature Driven Development

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. Feature Driven Development Reid S. Carlberg SE470 http://www.fivesticks.com/info/fdd

  2. Feature Driven Development • Abstract • Historical background • Description • Usage guidelines • Marketplace analysis • References

  3. Abstract • Feature Driven Development focuses on regular delivery of client-valued features • More structure than XP and fewer requirements than RUP—a middle ground • Embraces software development as a human activity, subject to human limitations and benefiting from human strengths

  4. Feature Driven Development • Abstract • Historical background • Description • Usage guidelines • Marketplace analysis • References

  5. The Players • Jeff De Luca, principle, Nebulon Pty. Ltd. (Australia) • Peter Coad, TogetherSoft Corporation (now Borland)

  6. Genesis: Singapore, 1997-98 • A large bank had a failed software project • 2 years of work • 3,500 pages of use cases • complex object model • no functioning code • concluded it couldn’t be done

  7. Genesis: Singapore, 1997-98 • De Luca comes in, hires Coad • delivered 2000 functioning features • took 15 months with 50 programmers • came in under budget • all this an “un-doable project” !

  8. How? • De Luca brought a methodology used for 20 years • Coad brought his ideas about features. • FDD was born. • First published in 1999, Java Modeling in Color with UML

  9. Feature Driven Development • Abstract • Historical background • Description • Usage guidelines • Marketplace analysis • References

  10. Description: Primary Components • Core values • Six roles • Five processes • Project tracking methodology

  11. Description: Primary Components • Core values • Six roles • Five processes • Project tracking methodology

  12. Process Pride Core Values • “Process pride” focuses on the process rather than tangible results

  13. Core Values • A system for building systems is necessary • Simple is better • Process steps should be obviously valuable to each team member • Good processes move to the background

  14. Description: Primary Components • Core values • Six roles • Five processes • Project tracking methodology

  15. Six Roles • Every publication on FDD emphasizes people • People’s strengths and weaknesses have a huge impact on any project’s outcome • Surprisingly: how to attract, recognize, motivate and keep good people

  16. Six Roles • Project Manager • Chief Architect • Development Manager • Chief Programmers • Class Owners (aka Developers) • Domain Experts

  17. Six Roles: Project Manager • Administrative lead for the project • budget, headcount, progress reports • Operates project system • e.g. TogetherSoft Control Center • Shields participants from external distractions

  18. Six Roles: Chief Architect • Responsible for the overall design of the system • Runs design workshops (more on that in process) • Steers project through technical obstacles.

  19. Six Roles: Development Manager • Leads day to day development activities • Resolves resource conflicts • Often combined with either the PM or CA

  20. Six Roles: Chief Programmers • Experienced developers • Leads smaller teams of individual developers • Key role: needs to be respected by both developers and managers.

  21. Six Roles: Class Owners • Individual developers • Design, code, test and document features

  22. Six Roles: Domain Experts • Users, clients, sponsors, etc. • Knowledge base for developers

  23. Supporting Roles Domain manager Release manager Language guru Build engineer Toolsmith System administrator Sometimes Helpful Testers Deployers Technical writers Six Roles: OK—More than six!

  24. Description: Primary Components • Core values • Six roles • Five processes • Project tracking methodology

  25. Five Processes Per project Per feature

  26. 1. Develop an overall model Who? domain experts, chief architect, chief programmers

  27. 1. Develop an overall model • Establishes the shape of the system • Defines classes, how classes related to each other • Creates the base object model • Includes internal and external reviews, model notes

  28. 1. Develop an overall model

  29. 1. Develop an overall model

  30. 2. Build a features list Who? Feature List Team: domain experts, chief programmers, chief architect (inspired by surgical teams)

  31. 2. Build a features list • Functional decomposition of model developed in step 1 • Subject area to business activity to business activity step • Feature is a business activity step, customer centric not technology centric • Nomenclature: <action> <result> <object> • “Generate an account number for the new customer”

  32. 2. Build a features list

  33. 2. Build a features list http://www.nebulon.com/articles/fdd/DevView.html

  34. 3. Plan By Feature Who? The Planning Team: the project manager, the development manager, and chief programmers.

  35. 3. Plan By Feature

  36. 3. Plan By Feature • Group features into feature sets (one or more business activities) • Prioritize based on customer need • Establish completion dates (MM/YYYY)

  37. 3. Plan By Feature http://www.nebulon.com/articles/fdd/planview.html

  38. 4. Design by feature Who? The Feature Team: chief programmer, class owners

  39. 4. Design by feature • Work package level—now based on the technical architecture • Two weeks or less of work • Fleshes out class and object design, create sequence diagrams as necessary • Feature teams are very fluid • Updates object model created in process #1.

  40. 4. Design by feature

  41. 5. Develop by feature Who? Class owners, chief programmers

  42. 5. Develop by feature • Implement • Code inspection • Unit test • Promote to build

  43. 5. Develop by feature

  44. Primary Components • Core values • Six roles • Five processes • Project tracking methodology

  45. Project Tracking Methodology Process 1’s 10% is the most significant. Other numbers are fungible.

  46. Project Tracking Methodology walkthrough + design = 41% complete

  47. Project Tracking Methodology http://www.nebulon.com/articles/fdd/SummaryTables.html

  48. Project Tracking Methodology http://www.nebulon.com/articles/fdd/linereport.html

  49. Feature Driven Development • Abstract • Historical background • Description • Usage guidelines • Marketplace analysis • References

  50. Usage Guidelines: Use When… • 10-250 developers • Handy pool of talented workers (above average)

More Related