Feature Driven development

From Amachu
Jump to: navigation, search

Feature Driven Development (FDD) is an agile and adaptive approach for developing systems. The FDD approach does not cover the entire software development process, but rather focuses on the design and building phases. . However, it has been designed to work with the other activities of a software development project and does not require any specific process model to be used. The FDD approach embodies iterative development with the best practices found to be effective in industry. It emphases quality aspects throughout the process and includes frequent and tangible deliveries, along with accurate monitoring of the progress of the project.

FDD consists of five sequential processes and provides the methods, techniques and guidelines needed by the project stakeholders to deliver the system. Furthermore, FDD includes the roles, artifacts, goals, and timelines needed in a project. Unlike some other agile methodologies, FDD claims to be suitable for the development of critical systems

FDD was first reported in. It was then further developed on the basis of a work done for a large software development project by Jeff Luca, Peter Coad and Stephen Palmer.

Contents

Process

As mentioned earlier, FDD consists of five sequential processes during which the designing and building of the system is carried out. The iterative part of the FDD processes (Design and Build) supports agile development with quick adaptations to late changes in requirements and business needs. Typically, an iteration of a feature involves a one to three week period of work for the team.

prcesses of FDD

In the following, each of the five processes is described according to Palmer.

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 or functional specifications are likely to exist at this stage. However, FDD does not explicitly address the issue of gathering and managing the requirements. The domain experts present a so called "walkthrough" in which the team members and the chief architect are informed of the high-level description of the system.

The overall domain is further divided into different domain areas and a more detailed walkthrough is held for each of them by the domain members. After each walkthrough, a development team works in small groups in order to produce object models for the domain area at hand. The development team then discusses and decides upon the appropriate object models for each of the domain areas. Simultaneously, an overall model shape is constructed for the system.

Build a Features List

The walkthroughs, object models and existing requirement documentation give a good basis for building a comprehensive features list for the system being developed. In the list, the development team presents each of the client valued functions included in the system. The functions are presented for each of the domain areas and these function groups consist of so-called major feature sets. In addition, the major feature sets are further divided into feature sets. These represent different activities within specific domain areas. The feature list is reviewed by the users and sponsors of the system for their validity and completeness.

Plan by Feature

Planning by feature includes the creation of a high-level plan, in which the feature sets are sequenced according to their priority and dependencies and assigned to Chief Programmers. Furthermore, the classes identified in the "developing of an overall model" process are assigned to individual developers, i.e. class owners. Also schedule and major milestones may be set for the feature sets.

Design by Feature and Build by Feature

A small group of features is selected from the feature set(s) and feature teams needed for developing the selected features are formed by the class owners. The design by feature and build by feature processes are iterative procedures, during which the selected features are produced. One iteration should take from a few days to a maximum of two weeks. There can be multiple feature teams concurrently designing and building their own set of features. This iterative process includes such tasks as design inspection, coding, unit testing, integration and code inspection. After a successful iteration, the completed features are promoted to the main build while the iteration of designing and building begins with a new group of features taken from the feature set.

The Design by feature and Build by feature processes of FDD

Roles and responsibilities

The FDD classifies its roles into three categories: key roles, supporting roles and additional roles. The six key roles in a FDD project are: project manager, chief architect, development manager, chief programmer, class owner and domain experts. The five supporting roles comprise release manager, language lawyer/language guru, build engineer, toolsmith and system administrator. The three further roles that are needed in any project are those of the testers, deployers and technical writers. One team member can play multiple roles, and a single role can be shared by several people.

In the following, the tasks and responsibilities of the different roles, as presented by Palmer, are described in brief.

Project Manager

Project manager is the administrative and financial leader of the project. One of his tasks is to protect the project team from outside distractions and to enable the team to work along with providing it with appropriate working conditions. In FDD, the project manager has the ultimate say on the scope, schedule, and staffing of the project.

Chief Architect

The chief designer is responsible for the overall design of the system and running the workshop design sessions held with the team . The chief architect also makes the final decisions on all design issues. If necessary, this role can be divided into the roles of domain architect and technical architect.

Development Manager

The development manager leads daily development activities and solves any conflicts that may occur within the team. In addition, this role includes the responsibility of solving resourcing problems. The tasks of this role can be combined with those of the chief architect or project manager.

Chief Programmer

The chief programmer is an experienced developer, who participates in the requirements analysis and design of the projects. The chief programmer is responsible for leading small teams in the analysis, design and development of new features. Selecting features from the feature set(s) to be developed in the next iteration of the "design by feature and build by feature" processes and identifying the classes and class owners that are needed in the feature team for the iteration also belong to the responsibilities of the chief programmer, along with cooperation with other chief programmers in solving technical and resourcing issues, and reporting the progress of the team weekly.

Class Owner

Class owners work under the guidance of the chief programmer in the tasks of designing, coding, testing and documenting. He is responsible for the development of the class he has been assigned to be the owner of. Class owners form feature teams. For each iteration those class owners are involved whose class is included in the features selected for the next development iteration.

Domain Expert

The domain expert may be a user, a client, a sponsor, a business analyst or a mixture of these. His task is to possess the knowledge of how the different requirements for the system under development should perform. Domain experts pass this knowledge to the developers in order to ensure that the developers deliver a competent system.

Domain Manager

Domain manager leads the domain experts and resolves their differences of opinion concerning the requirements for the system.

Release Manager

Release manager controls the progress of the process by reviewing the progress reports of chief programmers and holding short progress meetings with them. He reports the progress to the project manager.

Language Lawyer/Language Guru

A team member responsible for possessing a thorough knowledge of, for example, a specific programming language or technology. This role is particularly important when the project team is dealing with some new technology.

Build Engineer

A person responsible for setting up, maintaining and running the build process, including the tasks of managing the version control system and publishing documentation.

Toolsmith

Toolsmith is a role for building small tools for development, test and data conversion teams in the project. Also, a toolsmith may be working with setting up and maintaining databases and Web sites for project-specific purposes.

System Administrator

The task of a system administrator is to configure, to manage and to troubleshoot the servers, network of workstations and development and testing environments used by the project team. Also, the system administrator may be involved in the productionizing of the system being developed.

Tester

Testers verify that the system being produced will meet the requirements of the customer. May be an independent team or a part of the project team.

Deployer

Deployers’ work is concerned with converting existing data to the format required by the new system and participating in the deployment of new releases. May be an independent team or a part of the project team.

Technical Writer

The user documentation is prepared by technical writers, who may form an independent team or be a part of the project team.

Practices

FDD consists of set of “best practices” and the developers of the method claim that even though the selected practices are not new, the specific blend of these ingredients make the five FDD processes unique for each case. Palmer and Felsing also advocate that all the practices available should be used to get the most benefit of the method as no single practice dominates the whole process. FDD involves the following practices:

  • Domain Object Modeling: Exploration and explanation of the domain of the problem. Results in a framework where the features are added.
  • Developing by Feature: Developing and tracking the progress through a list of small functionally decomposed and client-valued functions.
  • Individual Class (Code) Ownership: Each class has a single person nominated to be the one responsible for the consistency, performance and conceptual integrity of the class.
  • Feature Teams: Refers to small, dynamically formed teams
  • Inspection: Refers to the use of the best-known defect-detection mechanisms.
  • Regular Builds: Refers to ensuring that there is always a running, demonstrable system available. Regular builds form the baseline to which new features are added.
  • Configuration Management: Enables the identification and historical tracking of the latest versions of each completed source code file.
  • Progress reporting: Progress is reported based on complete work to all necessary organizational levels.

The project team must put all the above practices into use in order to comply with the FDD development rules. However, the team is allowed to adapt them according to their experience level.

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox
Print/export