Your SlideShare is downloading. ×
Lecture 5
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Lecture 5

356
views

Published on

Feature Driven Development

Feature Driven Development

Published in: Technology, Business

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
356
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
45
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Existing Agile Methods-Feature Driven Development (FDD)
  • 2. • Feature Driven Development (FDD) is an agileand adaptive approach for developing systems.• The FDD approach does not cover the entiresoftware development process, but ratherfocuses on the design and building phases.
  • 3. Feature Benefits
  • 4. Feature Benefits (Cont.)
  • 5. FDD Process• FDD consists of five sequential processes andprovides the methods, techniques and guidelinesneeded by the project stakeholders to deliver thesystem.• Further more, FDD includes the roles, artifacts, goalsand timelines needed in a project.
  • 6. ProcessDevelop anOverallModelBuild aFeaturesListPlan byFeatureDesign byFeatureBuild byFeature
  • 7. Develop an Overall Model• When the development of an overall model begins,the domain experts are already aware of the scope,context and requirements of the system to be built.• Documented requirements such as use cases orfunctional specifications are likely to exist at thisstage.
  • 8. • The domain experts present a so called“Walkthrough” in which the team members and thechief architect are informed of the high leveldescription of the system.• The development team then discusses and decidesupon the appropriate object models for each of thedomain areas.• Simultaneously, an overall model shape isconstructed for the system.
  • 9. Build a Featured List• The walkthroughs, object models and existingrequirement documentation give a good basis forbuilding a comprehensive features list for the systembeing developed.• In the list, the development team presents each ofthe client valued functions included in the system.
  • 10. • The major feature sets are further divided intofeature sets. These represents different activitieswithin specific domain areas.• The feature list is reviewed by the users andsponsors of the system for their validity andcompleteness.
  • 11. Plan by Feature• Planning by feature includes the creation of a high-level plan, in which the feature sets are sequencedaccording to their priority and dependencies andassigned to Chief Programmers.• Furthermore, the classes identified in thedevelopment of an overall model process areassigned to individual developers, i.e, class owners.
  • 12. Design by Feature and Build byFeature• A small group of features is selected from the featureset (s) and feature teams needed for developing theselected features are formed by the class owners.• The design by feature and build by feature processesare iterative procedures, during which the selectedfeatures are produced.
  • 13. • One iteration should take from a few days to amaximum of two weeks.• There can be multiple feature teams concurrentlydesigning and building their own set of features.• This iterative process include such tasks as designinspection, coding, unit testing, integration and codeinspection.
  • 14. • After a successful iteration, the completedfeatures are promoted to the main build whilethe iteration of designing and building beginswith a new group of features taken from thefeature set.
  • 15. Roles and Responsibilities• The FDD classifies its roles into three categories:– Key Roles (6)– Supporting Roles (5)– Additional Roles (3)
  • 16. • The Six key roles in a FDD project are– Project Manager– Chief Architect– Development Manager– Chief Programmer– Class Owner &– Domain Expert.
  • 17. • The five supporting roles are– Release Manager– Language Lawyer/Language Guru– Build Engineer– Toolsmith &– System Administrator
  • 18. • The three further roles that are needed in anyproject are– Testers– Deployers &– Technical Writers
  • 19. • One team member can play multiple roles and asingle role can be shared by several people.
  • 20. Project Manager• Project Manager is the administrative and financialleader of the project.• One of his tasks is to protect the project team fromoutside distractions and to enable the team to workalong with providing it with appropriate workingconditions.
  • 21. Chief Architect• The Chief Designer is responsible for the overalldesign of the system and running the workshopdesign sessions held with the team.• The Chief Architect also makes the final decisions onall design issues.
  • 22. Development Manager• The Development Manager leads dailydevelopment activities and solves any conflictsthat may occur within the team.• In addition, this role includes the responsibilityof solving resourcing problems.
  • 23. Chief Programmer• The Chief Programmer is an experienced developer,who participates in the requirements analysis anddesign of the projects.• The Chief Programmer is responsible for leadingsmall teams in the analysis, design anddevelopment of new features.
  • 24. Class Owner• Class Owners work under the guidance of the ChiefProgrammer in the tasks of designing, coding,testing, and documenting.• He is responsible for the development of the classhe has been assigned to be the owner of.
  • 25. Domain Expert• The Domain Expert may be a user, a client, asponsor, a business analyst or a mixture of these.• His task is to possess the knowledge of how thedifferent requirements for the system underdevelopment should perform.• Domain Experts pass this knowledge to thedevelopers in order to ensure that the developersdeliver a competent system.
  • 26. Domain Manager• Domain Manager leads the domain experts andresolves their differences of opinion concerningthe requirements for the system.
  • 27. Release Manager• Release Manager controls the progress of theprocess by reviewing the progress reports of ChiefProgrammers and holding short progress meetingswith them.• He reports the progress to the Project Manager.
  • 28. Language Lawyer/Language Guru• A Team Member responsible for possessing athorough knowledge of, for example, a specificprogramming language or technology.• This role is particularly important when the projectteam is dealing with some new technology.
  • 29. Build Engineer• A person responsible for setting up, maintaining andrunning the build process, including the tasks ofmanaging the version control system and publishingdocumentation.
  • 30. Toolsmith• Toolsmith is a role for building small tools fordevelopment, test and data conversion teams in theproject.• Also a Toolsmith may be working with setting upand maintaining databases and Websites for projectspecific purposes.
  • 31. System Administrator• The task of a system administrator is to configure, tomanage and to troubleshoot the servers, network ofworkstations and development and testingenvironments used by the project team.• The system administrator may be involved in theproductionizing of the system being developed.
  • 32. Tester• Testers verify that the system being producedwill meet the requirements of the customer.• May be an independent team or a part of theproject team.
  • 33. Deployer• Deployers’ work is concerned with convertingexisting data to the format required by the newsystem and participating in the deployment of newreleases.• May be an independent team or a part of the projectteam.
  • 34. Technical Writer• The user documentation is prepared by technicalwriters, who may form an independent team or be apart of the project team.
  • 35. Practices• Domain Object Modeling:-– Exploration and explanation of the domain of theproblem. Results in a framework where thefeatures are added• Developing by Feature:-– Developing and tracking the progress through alist of small functionally decomposed and client-valued functions.
  • 36. • Individual Class Ownership:-– Each class has a single person nominated to be the oneresponsible for the consistency, performance andconceptual integrity of the class.• Feature Teams:-– Refers to small, dynamically formed teams
  • 37. • Inspection:-– Refers to the use of the best-known defect-detectionmechanisms.• Regular Builds:-– Refers to ensuring that there is always a running,demonstrable system available. Regular builds form thebaseline to which new features are added.
  • 38. • Configuration Management:-– Enables the identification and historical tracking of thelatest versions of each completed source code file.• Progress Reporting:-– Progress is reported based on complete work to allnecessary organizational levels.