Feature-driven development

From CEOpedia | Management online

Feature-Driven Development (FDD) - is one of the methods of adaptive project management. It pays for quick delivery of visible work results and accurate information on the current state of the project with minimal involvement of programmers. FDD combines the best practices of managing IT projects into a coherent whole. The recommendations included in the methodology are characterized by focusing on the functionality of the application valued by the client. The FDD methodology also describes individual project participants, their roles, subsequent software development processes and methods of measuring results. The creators of the approach are Jeff De Luca and Peter Coad, who, working together on a large programming undertaking in Singapore, were forced to develop a more effective than traditional project management method. The term "Feature-Driven Development" appeared for the first time in the book "Java Modeling in Color with UML" by Peter Coad in 1999.

5 processes of Feature-Driven Development

  • The first process - developing a general model: The FDD model assumes that teams will make enough effort at the beginning of the project to build an object model that emphasizes the domain problem. FDD modeling is time-limited and largely based on collaboration. Domain models should be created by small groups and then presented for evaluation. It should be assumed that the proposed model or combination of models will be used for each domain area. Then they will be merged to create a generic model.
  • The second process - creating a list of functions. From the knowledge obtained during the modeling process, a list of functions is determined by dividing domains into thematic areas that contain information about business activities. The steps that are used for each business activity are a categorized list of functions. Functions are expressed, for example, as: result, action, object. It is required that the completion of the function does not last longer than two weeks. If it is impossible then you should divide these functions into smaller sections,
  • Third process - plan by function. After the function lists have been created, the following process involves assigning different sets of functions to programmers.
  • The fourth process - design by function. Programmers together with the main programmer create a design package for each function by selecting a function group that should be created within two weeks. The main programmer also creates detailed diagrams for each function, while improving the model. After this stage, prologues are created and project control is carried out.

The fifth process - build by function. After the project inspection is completed, the designers plan the operation for each function and develop the code for the respective classes. The next step after completing the control and performing the unit test is adding the function to the main version.

Good FDD practices

Feature-Driven Development includes a number of good practices supporting the management of an IT project. The most important of them are:

  • The object model of the system

In the FDD approach, it is very important to determine the general object model of the designed system. Based on it, all subsequent product decisions are made. The way of presenting the developed model is also important. For this purpose, it is recommended to use color UML modeling, as the FDD approach was based on this technology.

  • Create based on requirements

Specific functionalities provided at a specific time are essential for the customer. For this reason, it is necessary to ensure the creation of an exact list of required functions. All of them that are impossible to implement in a two-week period are broken down into other, smaller ones.

  • Responsibility for the code

It is implemented by assigning each class resulting from the application project to a specific programmer who is fully responsible for it from a given moment.

  • Dynamic teams of programmers

If a given functionality requires more classes, the team responsible for the whole element is assembled. The team consists of programmers, each of whom develops a given class. One of them is the main programmer, whose task is also to coordinate the activities of the entire team. In the FDD approach, there is often a situation in which one programmer belongs to many teams.

  • inspections

Regular inspections are carried out to ensure quality control and code integrity. Due to the fact that each programmer belongs to many teams, the inspection does not evaluate the employees, but the entire functionality and the way they are performed.

  • Incremental product construction

At regular intervals, all code that performs specific functions is downloaded and all work necessary to run it is performed. This provides the opportunity to conduct tests and present the subsequent versions of the system to the client.

  • Configuration management

In addition to storing only the source code of the project, it is also recommended to pay attention to all events affecting its final form. Such noteworthy events are, for example, changes in requirements, results of analyzes, errors detected.

  • Reporting progress

At all levels of product creation, data about its current status and changes are collected. This information is then used to create summary reports, supporting project managers.

  • Feature-Driven Development and other agile methodologies

All adaptive methodologies have certain areas in which they are very similar to each other. The most-known of them, such as Extreme Programming or Scrum, as well as Feature-Driven Development, are based on an incremental approach to software production. These methodologies focus on providing the client with running versions of the program as quickly as possible and communication between people participating in the project. However, the method of achieving these goals is different for each methodology.

Differences start at the system design stage. Extreme Programming recommends software development based only on functional requirements analysis, implementing each set of functions in turn. Feature-Driven Development advises on the other hand to create a general object model of the product being created. This approach extends the time of the preparation phase, but has its advantages. Creating a general model before starting work allows you to reduce later changes in the code and easier project management. Another distinguishing feature of FDD compared to other methodologies is the approach to programming and responsibility for the code. In FDD, specific developers are responsible for the classes assigned to them, and the quality of the code is maintained by means of periodic inspections. In the extreme programming methodology, however, programming in pairs is recommended as a method of code inspection. FDD, unlike other adaptive methodologies, does not put much emphasis on testing. The method and accuracy of their implementation depends on the main programmer. Other agile methodologies approach this problem much more accurately by requiring writing tests for a given functionality before creating it, which ensures a high degree of code reliability.

Examples of Feature-driven development

  • Agile Development - Agile development is a process of developing software in small increments. In this method, software is developed in a collaborative manner, with frequent feedback from stakeholders. Agile development teams focus on delivering a working product as quickly as possible, and continuously refining it based on customer feedback. This approach allows for quick and frequent changes to the software, which makes it well-suited for Feature-Driven Development.
  • Iterative Development - Iterative development is a process of building software in phases. During each phase, the team develops a specific feature and tests it to ensure that it works correctly. This type of development is well-suited for Feature-Driven Development because it allows teams to quickly and easily test new features and make changes as needed.
  • Test-Driven Development - Test-driven development is a process of writing test cases before starting to code. This approach allows teams to ensure that the software they are developing meets the requirements of the customer. By writing test cases in advance, teams can avoid costly errors during development and ensure that the software meets the customer's expectations. This makes it well-suited for Feature-Driven Development, as teams can quickly and easily test new features and make changes as needed.

Advantages of Feature-driven development

One of the main advantages of Feature-Driven Development is its focus on delivering value to the customer quickly. The following are some of the other advantages of FDD:

  • It promotes clear communication between stakeholders and the development team, ensuring that everyone is on the same page.
  • It provides a structured approach to software development that helps teams organize and track their progress.
  • It encourages collaboration among team members, allowing them to share ideas and work together to create the best product possible.
  • It provides a method of tracking scope changes, allowing teams to adjust their plans and strategies as needed.
  • It reduces the risk of developing software that does not meet customer requirements by breaking down the project into smaller, manageable pieces.
  • It provides measurable metrics to evaluate the progress of the project, helping teams stay on track and make informed decisions.

Limitations of Feature-driven development

  • Feature-Driven Development may not be suitable for projects with high complexity due to its emphasis on simplicity and quick results.
  • It is possible that developers lack the necessary skills and knowledge to successfully use the FDD approach.
  • FDD requires a high degree of collaboration and communication between all stakeholders, which can be difficult to achieve in a large project.
  • The methodology does not provide a mechanism to assess project risk or manage the technical aspects of the project.
  • The methodology focuses on the development of small increments of functionality, which may lead to a lack of customer satisfaction with the final product.
  • The methodology does not allow for the integration of design changes during the development process, which can lead to inadequate testing and a lack of quality assurance.

Other approaches related to Feature-driven development

  • Agile Development - is a software development methodology that promotes adaptive planning, evolutionary development and delivery, early time-to-market and continuous improvement. It promotes customer collaboration, fast delivery of functioning software and a high degree of developer team self-organization and responsibility.
  • Test-Driven Development (TDD) - is a software development process that uses short development cycles to ensure that the code meets customer requirements. It focuses on writing automated tests before the code is written and then refactoring the code to ensure that the tests pass.
  • Behavior-Driven Development (BDD) - is an agile software development process that encourages collaboration between developers, QA and non-technical business people. It focuses on the behavior of the system, rather than the implementation details.
  • Extreme Programming (XP) - is a software development methodology that promotes rapid development and delivery of software. It emphasizes communication, simplicity, feedback, and courage in order to produce high quality software.

In summary, Feature-Driven Development is just one of several approaches that have been developed to improve software development processes. Other approaches such as Agile Development, Test-Driven Development, Behavior-Driven Development, and Extreme Programming also have their own merits and can be used as a complement to FDD or as an alternative in certain scenarios.


Feature-driven developmentrecommended articles
CMM modelProduct backlogBehavior driven developmentPMBOK frameworkMoSCoW techniqueScrum of scrumsProject lifecycleLean product developmentNetwork charts

References