Feature driven development

Feature driven development ( FDD , functionality- driven development ) is an iterative software development methodology, one of the agile flexible development methodologies. FDD is an attempt to combine the most recognized techniques in the software development industry, taking as a basis for the customer-important functionality (features) of the software being developed. The main goal of this methodology is to develop real, working software systematically, in the set time frame.

Story

FDD was originally proposed by Jeff De Luca for the project (designed for 15 months and 50 people) for developing software for one large Singapore bank in 1997. De Luc singled out a set of five processes, covering both the development of a general model and the list maintenance, planning, design and implementation of the elements of functionality.

The first description of FDD appeared in 1996 in Chapter 6 of the book Java Modeling in Color with UML ^[1] . In the book A Practical Guide to Feature-Driven Development ^[2] (2002), the description of FDD was generalized, and in particular free from bindings to a specific programming language.

Overview

FDD includes five basic activities:

1. development of a general model;
2. drawing up a list of necessary functions of the system;
3. planning work on each function;
4. function design;
5. implementation of the function.

The first two processes relate to the start of the project. The last three are carried out for each function. Developers in FDD are divided into "class owners" and "main programmers." The main programmers attract the owners of the classes involved to work on the next property. Work on the project involves frequent assembly and is divided into iterations, each of which involves the implementation of a specific set of functions.

Development of a general model

Development begins with a high-level, end-to-end analysis of the breadth of the range of tasks to be solved and the context of the system. Further, for each simulated area a more detailed end-to-end analysis is done. Cross-sectional descriptions are compiled in small groups and submitted for further discussion and peer review. One of the proposed models or their combination becomes a model for a specific area. The models of each task area are combined into a common final model, which changes during the course of the work.

List of features (functions

The information collected when building a general model is used to compile a list of functions. This is done by dividing the regions ( domain ) into subregions (subject areas, subject areas ) in terms of functionality. Each individual subdomain corresponds to a business process whose steps become a list of functions (properties). In this case, functions are small parts of user-understood functions, represented as “<action> <result> <object>”, for example, “checking user password”. The development of each function should take no more than 2 weeks, otherwise the task must be divided into several subtasks, each of which can be completed within a two-week period.

Plan for properties (functions)

After making a list of basic functions, it is the turn of drawing up a software development plan. Class ownership is distributed to leading programmers by organizing and organizing properties (or sets of properties) into classes.

Function design

For each property, a design package is created. The lead programmer selects a small group of properties for development within two weeks. Together with the developers of the corresponding class, the lead programmer creates detailed sequence diagrams for each property, specifying the overall model. Further “blanks” of classes and methods are written, and a critical review of the design takes place.

Function implementation

After a successful review of the design, this functionality visible to the client is implemented to a state of readiness. For each class program code is written. After unit testing of each block and verification of the code, the completed function is included in the main project (English build ).

Stages

Since the functions are small, their development is a relatively easy task. To monitor a software development project and provide accurate data on project development, it is necessary to log the development of each property (function). FDD allocates six consecutive stages for each function (property). The first three are fully completed in the design process, the last three - in the implementation process. For the convenience of monitoring the implementation of work at each stage shows the percentage of its readiness (execution). The table below summarizes the main steps. The function, which is still under development, is 44% complete (Area Analysis 1% + Design 40% + Design Verification 3% = 44%)

Best Practices [edit | edit wiki text]

FDD is based on a set of best practices (a set of best practices), recognized in the industry and derived from software engineering. These practical methods are built from the point of view of the functionality important for the client. Below is a brief description of each method:

• Object modeling area. Object modeling consists of research and clarification of the scope of the problem domain. The result is a common framework, which can be further enhanced by functions.

• Development by function. Any function that is too complex to develop in two weeks is broken down into smaller subfunctions until each subtask can be called a property (that is, it can be implemented in 2 weeks). This facilitates the creation of correctly working functions, the expansion and modification of the system.

• Individual ownership of the class (code). Means that each code block is assigned to a specific owner-developer. The owner is responsible for the consistency, performance and conceptual integrity of their classes.

• The team to develop functions (properties) . The function (property) development team is a small, dynamically formed development team dedicated to a small subtask. Allows several developers to participate in the design of properties, as well as evaluate design decisions before choosing the best.

• Check code (English code review ) Checks provide good quality code, primarily by identifying errors.

• Configuration management It helps with the identification of the source code for all functions (properties), the development of which is currently completed, and with the logging of changes made by the developers of classes.

• Regular build. Regular assembly ensures that there is always a product (system) that can be presented to the customer, and helps to find errors when combining parts of the source code in the early stages.

• Visibility of the work and results. Frequent and accurate progress reports at all levels inside and outside the project of the work done help managers manage the project properly.