Feature Driven Development

1. Feature Driven Development Satish, Arjun

2. Contents • What & Why of FDD • Feature Definition • Project Roles & Responsibilities • FDD Process • FDD Project Progress • Conclusions

3. What is FDD ? • Highly Iterative • Emphasizes Quality at each step • Delivers frequent, tangible, working results • Accurate & meaningful Project Progress Tracking

4. Why FDD? • Many non-trivial Projects fail • Heavy process approach doesn’t work • Inflexible and slow to adapt • Concentration is on process, not results • FDD supports • Building complex software systems • Large development teams

5. Definition of Feature • SmallClient-valued function which can be delivered in 2 weeks A Major Feature Set • <object> Management Ex 1 – Product Sales Management Feature Set is a group of business related features • <action> <-ing> <a(n)> <object> Ex 1 – Making a product sale • Feature Naming Template • <action> the <result> <by [of|to|from|for]> a(n) <object> Ex 1 - Calculate [ action] the total [result] of a sale [ object ] Ex 2- Calculate the total purchases by a customer

6. FDD – How it works ? Individual Features Feature Set Major Feature Set Feature Set Feature Set Feature Set Major Feature List Major Feature Set Feature Set Feature Set Feature Set Major Feature Set Feature Set Feature Set

7. Roles & Responsibilities (1/3) • Key Roles • Project Manager (PM) • Administrative Head of the Project • Responsible for Reporting Progress , Managing Budgets • Chief Architect (CA) • Responsible for the overall design of the system • Runs design workshops • Steers project through technical obstacles • Development Manager • Leads day to day development activities • Resolves resource conflicts • Often combined with either the PM or CA

8. Roles & Responsibilities (2/3) • Key Roles • Chief Programmers (CP) • Experienced developers • Leads smaller teams of individual developers • Class Owners (aka Developers) • Individual developers • Design, code, test and document features • Domain Experts • Users, clients, sponsors, etc. • Knowledge base for developers

9. Roles & Responsibilities (3/3) Supporting Roles • Domain Manager • Release Manager • Language Guru • Build Engineer • Toolsmith • System Administrator Additional Roles • Testers • Deployers • Technical writers

10. FDD Process Template Entry – Tasks – Verification – Exit : (ETVX) • Entry: A brief description of the process, and all pre-conditions that should hold before the process starts • Tasks: A list of all tasks that should be done during the process. • Verification: Conditions which clarify if the process has been completed successfully • Exit: A list of all outputs from the process

11. 5.Build By Feature 1.Develop an Overall Model 3.Plan By Feature 2.Build a Feature List 4.Design By Feature FDD Process (1/8) • Activities within each Process follow ETVX Template • FDD – A 5 Step Process Fig Source: Palmer, SR., Felsing , JM.2002,p.57).

12. Develop an Overall Model (2/8) • Entry Criteria • Domain experts, Chief Programmers and the Chief Architect have been selected. • Tasks • Verification • By users & Domain Experts • Exit criteria • Class diagram (Fig. Source: Palmer, SR., Felsing , JM.2002,p.106)

13. Build a Features List (3/8) • Entry Criteria • Domain experts, CP & CA have been selected • Tasks • Domain decomposed into Major Features Sets • Major Feature Sets comprise of Feature Sets • Feature Sets comprises Features • Verification • Self Assessment of Modeling Team Members • Exit criteria • Features List Source: Palmer, SR., Felsing , JM.2002,p.135

14. Plan by Feature (4/8) • Entry Criteria • Completed Building a Features List • Tasks • To achieve development sequence • Verification • A self-assessment • Exit criteria • Business activities with Completion dates.. • CP assigned to business activities. • Class owner list Source: Palmer, SR., Felsing , JM.2002,p.146

15. Design by Feature (5/8) • Entry Criteria • Planning process has completed. • Tasks • CP, Work Package, Feature Team, Sequence diagram, Update the Object Model. (Next slide) • Verification • Design inspection is made. • Exit criteria • Sequence diagram(s). • Object model with new/updated classes

16. Continued… (6/8) (Fig. Source: Palmer, SR., Felsing , JM.2002,p.160)

17. Build by Feature (7/8) • Entry Criteria • The Design by Feature process has completed. • Tasks • Class owners implement the classes. • Verification • Successful Code Inspection & Unit Testing • Exit criteria • The completion of a client-valued function (feature)

18. Iterations of Design by Feature & Build by Feature Processes (8/8)

19. FDD Project Progress • Features are tracked by 6 milestones • Domain Walkthrough • Design • Design Inspection • Code • Code Inspection • Promote to Build • Reports are done on Feature Sets • At the end of each iteration there can be a report to show the percentage of the work Done

20. Conclusions • Adaptive Agile Method • Successfully utilizes iterative development • Better in team where developers’ experience varies • Offers progress tracking and reporting capabilities

21. References • Stephen R. Palmer and John M. Felsing, A Practical Guide to Feature-Driven Development,“ Prentice-Hall, 2002. • Agile Techniques for Project Management and Software engineering by Sadhna Goyal, Technical University , Munich, WS 2007/08 • Comparing Extreme Programming and Feature Driven development in academic and regulated environments by Serguie Khramtchenko, Harvard University. • www.featuredrivendevelopment.com • http://en.wikipedia.org/wiki/Feature_Driven_Development • Agile Software Development Methods – Review and Analysis by Pekka Abrahamsson , Outi Salo & Jussi Ronkainen