Feature driven development
- 1. Feature Driven Development Presented by Gayal G.S. MS14904356 Ruhaim Izmeth MS14901218 I.D.I.P.KUMARA MS13904142
- 2. Agenda •Background •Roles in FDD •FDD Practices •FDD Processes •Project Reporting •Advantages and Disadvantages •Conclusion & Summery •Q/A
- 3. Introduction Feature Driven Development (FDD) is one of the Agile Software Development Methodologies. Came into view in last 15 years as an alternative to traditional Waterfall development.
- 4. Birth of FDD Jeff De Luca Peter Coad Introduced in 1997 Published in a book in 1999, by Peter Coad
- 5. Why do we have to use FDD ? 1. Communication Consider developers as nodes in a communication network, all potentially linked to each other by communication channels. The number of potential communication channels increase dramatically as more number of developers are added 2. Complexity FDD decomposes the entire problem domain into tiny problems, which can be solved in a small period of time, usually 2 weeks decomposed problems independent to each other reduces the need of communication. FDD splits the project into iterations so that the distance in time between analysis and test is reduced early discovery of errors reduces the cost of fixing the errors. 3. Quality Different persons have different perception of software quality This makes necessary to view quality as a spectrum, with internal quality at one end and external quality at other end.
- 6. Roles in FDD Key Roles 1. Project Manager (PM) 2. Chief Architect (CA) 3. Development Manager (DM) 4. Chief Programmers 5. Class Owners 6. Domain Experts Supporting Roles 1. Release Manager 2. Language Guru 3. Build Engineer 4. Toolsmith 5. System Administrator Additional Roles 1. Testers 2. Deployers 3. Technical Writer
- 7. FDD - Practices Domain Object Modeling The Problem is broken down into the significant objects involved. The design and implementation of each object or class identified in the model is a smaller problem to solve. Completed classes are combined, Form the solution to the larger problem Best technique for domain object modeling is, M o d e l i n g I n C o l o r
- 8. FDD - Practices UML in Color All classes are divided into different categories with its own color code. a role being played. by a person or an organization, example: a user of an online auction may play different roles as a buyer or seller. a catalogue like description. example: a description of smart phones that sells in auction. a party, place or thing. example: the smart phones in stock would be modeled as green. This class usually has some identifying attributes such as serial no, persons name, etc. a moment in time or time associated with some business process. example: the fact of purchase may be shown a pink class, since it has a time of sale which is tracked by the online store,
- 9. FDD - Practices UML in Color All classes are divided into different categories with its own color code. a role being played. a catalogue like description. a party, place or thing. a moment in time or time associated with some business process.
- 10. FDD - Practices What is a Feature ? A feature is a small, client valued function that can be implemented in two weeks Any function that is too complex to be implemented within two weeks is further decomposed into smaller functions until each sub-problem is small enough to be called a feature. Major Feature Feature set Feature
- 11. FDD - Practices Developing by Feature The feature naming template <action> the <result> <by | for | of | to><a(n)><object> Example of features: Calculate <action> the total <result> of a sale <object> Calculate the total of a sale
- 12. FDD - Practices Class (code) Ownership In a development process, class (code) ownership is indicates who is ultimately responsible for the content of a class (piece of code). Feature Team Implementation of a feature may involve more than one class and more than one class owner
- 13. Processes FDD consist five processes Process
- 14. Processes Entry Criteria Domain experts, Chief Programmers and the Chief Architect have been selected. Exit Criteria ● Class diagrams focusing on model shape. That is, what classes are in the domain, how are they connected to one another and under what constraints. ● Methods and attributes identified are placed in the classes. ● Sequence Diagram(s), if any. ● Model notes to capture why a particular model shape was chosen and/or what alternatives were considered
- 15. Processes ● A team consist of Chief Programmers from process 1 are formed to decompose the domain functionality. ● The team breaks the domain into a number of areas (major feature Sets), based on the partitioning of the domain by the Domain Experts in process 1 ● Each area is further broken into a number of activities (feature sets). ● Each step within an activity is identified as a feature. Exit Criteria ● A list of subject areas ● For each subject area, a list of the business activities within that subject area ● For each business activity step, the feature to satisfy the step
- 16. Processes The project Manager, Development Manager, and Chief Programmers plan the order that the features are to be implemented, based on feature dependencies, load across the development team, and the complexity of the features to be implemented. Exit Criteria ● Business activities with completion dates (month and year) ● Chief programmers assigned to business activities ● Subject areas with completion dates (month and year) derived from the last completion date of their respective business activities ● The list of classes and the developers that own them (the class owner list)
- 17. Processes Feature Team Exit Criteria ● A covering memo, or paper, that integrates and describes the design package such that it stands on its own for reviewers. ● The referenced requirements (if any) in the form of documents and all related confirmation memos and supporting documentation. ● The Sequence diagram(s). ● Design alternatives (if any) ● The object model with new/updated classes, methods and attributes.
- 18. Processes Class owners implement the items necessary for their class to support the design for the feature(s) in the work package, based on the design package produced during the Design by Feature process. The developed code which is determined by the Chief Programmer is tested and inspected. After a successful code inspection, the code is permitted to build. Exit Criteria ● Class(es) and/or method(s) that have been successfully code inspected. ● Class(es) that have been promoted to the build. ● The completion of a client-valued function (feature)
- 19. Processes Guidelines for time spent in each process Process
- 20. Progress Reporting to Chief programmers and Project Manager Major Feature Set – “Workshop Management Area” Feature Set No of features No of Not started No of In progress No of Completed % completed
- 21. Progress Reporting to Chief programmers and Project Manager Every week, the rate of progress is shown by plotting a graph for the number of features completed each week
- 22. Progress Reporting to Sponsors and Upper Management Progress of the feature set “Scheduling a Service” Scheduling a Service (19) 27% DEC 2012 Work in progress Attention (behind Schedule) Completed Not yet started Completion Percentage Progress bar Completion Status Completed MY Targeted completion month Feature Set Name No of Features in the Features Set Feature set name - Scheduling a service Features are consist – 19 Currently complete – 27% Due date – Dec 2012
- 23. Progress Reporting to Sponsors and Upper Management Progress of the feature sets Scheduling a Service (19) 27.7% DEC 2012 Performing a Service (15) 30.1% DEC 2012 Billing a Service (6) 16.6% DEC 2012 Booking in a Repair (13) 75% DEC 2012 Feature Set No of features No of Not started No of In progress No of Completed % completed
- 24. Progress Reporting to Sponsors and Upper Management Major feature set
- 25. Major Usage of FDD FDD can be implemented with Up to 500 developers More critical projects Bigger projects More novice developers Environments that demand Waterfall
- 26. Advantages and Disadvantages of FDD Advantages Supports multiple teams working in parallel All aspects of a project tracked by a feature Design by feature and build by a feature aspects are easy to understand and adopt Scales to large teams or projects well Better in teams where developers’ experiences varies Offers well defined progress tracking and reporting capabilities
- 27. Advantages and Disadvantages of FDD Disadvantages Promotes individual code ownership as opposed to shared/team ownership Iterations are not well defined by the process as other agile methodologies The model-centric aspects can have huge impacts when working on existing systems that have no models.
- 28. Summary and Conclusion FDD is a process that begins with high level planning to define the scope of the project, which then moves into incremental delivery. FDD defines the overall scope of the project at the beginning, but does not define the details. FDD tries to combine good planning with the continuous improvement through iteration. There are five phases in an FDD process; the first three phases are planning phases and the last two phases are iterative phases Main Advantages: Easy to understand the feature based process, Scalability Main Disadvantages: Promotes individualism, Undefined iterations, Potential Model- Centric failures
- 29. References & Links Weinberg, G. Quality Software Management vols. NJ:Prentice Hall PTR, 2002. Coad, Peter, et al. Java modeling in Color with UML.Upper Saddle River, NJ:Prentice Hall PTR, 1999. Stephen R. Palmer, 2002. A Practical Guide to Feature-Driven Development. 1 Edition. Prentice Hall. Sadhna Goyal. “Agile Techniques for Project Management and Software Engineering”, Major Seminar on Feature Driven Development, Technical University-Munich, 2007-2008. Internet links, http://www.nebulon.com http://www.petercoad.com http://www.featuredrivendevelopment.com http://www.featuredrivendevelopment.com/certification/list http://en.wikipedia.org/wiki/Feature_Driven_Development
- 30. Q & A