What is Feature Driven Development (FDD)

Zia

2 Followers

Follow

May 30, 2024

-

0 sec read

448

0

0

0

FDD is a type of software development methodology, ideal for use by big teams, who undertake assignments involving object-oriented technology. The methodology description includes certain instructions regarding the tasks that are to be carried out and which roles should be assigned to them.

Corporations that are looking forward to switching to an iterative approach from a phase-based approach, without foregoing task and role assignments would benefit from FDD.

Given that FDD is a short-iteration process:

• It starts with creating an overall model shape
• Once a model shape is created, a two-week series of 'design by feature, build by feature' iterations is launched

The main goal is to create features that should be useful in the eyes of the client. This is challenging as a majority of the iterative processes are lengthy and do not feature on the client's priorities; for example, 'build the accounting system' and 'build the persistence layer' iterations.

FDD is a highly adaptive software development process, which:

• It is highly and short iterative
• Pay attention to quality at all steps
• Provide working results at the end of each step
• Managers, developers, and Users favor it,
  
  
  

1. FDD - Practices

FDD is a process that is a combination of several best practices. Some of the practices are explained as follows:

1. Domain Object Modeling:

This best practice involves creating class diagrams that show the important objects and their types in a specific problem area and how they relate to one another. Since the problem gets divided into important objects/classes, it becomes easier to find solutions. Finally, once all the classes are put together, they form the solution to the larger problem. There are several techniques under Domain Object Modeling, among which 'Modeling in Color' is considered to be the best.


2. UML in color:

Regular UML with color-coded classes defines the UML in the Color process. Classes are classified into different color categories. This makes it easier for the user to understand the dynamics of the problem domain. Do note that the auxiliary classes and interfaces are not assigned any colors.

Each color has a different meaning.

• Yellow: Denotes the role assumed by a person in an organization. A user can have many different roles. For example, a user can participate in an online auction as a buyer, seller, or system administrator.
  
  
• Blue: Used for description, often similar to catalogs. This description helps classify or label an object, providing extensive details. An example would be a car dealership brochure.
  
  
• Green: Stands for a party, place, or thing, with something unique or particularly identifiable about it. People, organizations, and objects can be used as examples of the green category.
  
  
• Pink: Refers to a point in time or an interval of time, which can be traced. The sale of an item, such as a car, can be traced as per the time stamp on the bill; therefore, it falls under the Pink category.
  
  
  

3. Developed by Feature:

A complex function, which spans over two weeks, is broken down into smaller functions, which can be completed within two weeks. The smaller functions are called features. In a business system, a feature can be traced to an activity that forms part of a business process.

The feature name template is:

<action>the <result>< by | for | of | to |><a (n)><object>

Some examples of features are as follows:

• Calculation of [action] is the total (result) of a sale (object)
• Evaluation of [action] the fulfillment timeliness (result) of a sale (object)
• Calculation of [action] the total purchases made [result] by a customer [object].

A Feature Set is a group of business-related features. An example of a feature set is as follows:

• Making a product sale
• A major feature of the Set
• <object>Management
  
  

4. Class (Code) of Ownership:

Class code ownership represents the person who has ultimate responsibility for the contents of a class. It could also be a role, which is assigned ownership of the contents of a class. FDD uses individual ownership, a concept where developers are given ownership of a set of classes, based on the domain object model.

5. Featured Team:

Since the implementation of a feature could involve multiple classes, it could have multiple classes such as a scenario, and the feature owner will be required to coordinate the efforts of multiple developers.

6. Inspections:

This practice aims at publicizing good practices, conventions, and development culture. As it is a combination of several people within a team, it helps generate better ideas, without fear of embarrassment on any individual's part. Best-known defect detection techniques are applied and the resulting opportunities are leveraged to promote best practices.

7. Regular build schedule:

At regular points in time, a system is built using the source code of the completed features as well as the components and libraries it is dependent on. This way, a system is always ready for exhibition.

8. Configuration management:

The main purpose of this best practice is the identification of the latest versions of the completed source code files. This also provides historical data relating to information artifacts in a project.

9. Progress Reporting:

Frequent reporting is an essential part of the process as it helps identify the status of the completion of the project. Reporting should be regular, apt, and accurate, spanning all levels. It should also consider the internal and external factors of the project for reporting purposes.

2. Roles in FDD

The most significant part of a project is people, followed by process and technology. Six key roles are defined by FDD, and some more roles are implied as follows:

• Project Manager: Serves as the administrative head of the project. The Project Manager would be in charge of reporting, budgeting, and procuring the required headcount in addition to overhead management (managing equipment, space, resources, and so on).
  
  
• Chief Architect: Responsible for the overall design of the system. This includes conducting workshop design sessions and team management as design involves team collaboration and problem-solving. In addition to this, the Chief Programmer is required to possess excellent technical skills, modeling skills, and facilitation skills.
  
  
• Development Manager: Manages the day-to-day development activities. This role requires a fair amount of facilitation and problem-solving when it comes to dealing with team issues, in case the Chief Programmers are unable to do so.
  
  
• Chief Programmers: The Chief Programmers are developers who have extensive experience in the entire software development life cycle. They contribute to high-level analysis and project design activities. Their responsibilities include leading the teams through design, development, and low-level analysis of the new software's features. The teams are populated by three to six people.
  
  
• Class Owners: They are developers who design, code, test, and record the features required by the new software system. They work as members of small development teams and are supervised by a Chief Programmer.
  
  
• Domain Experts: They represent the knowledge database. They can be users, sponsors, business analysts, or a combination of these roles. Developers depend on domain experts to deliver the correct system. Good verbal, written, and presentation skills are prerequisites for a domain expert. It is their knowledge and participation that is important to the success of the system being built.
  
  

Supporting roles are as follows:

• Release Manager: Reports directly to the Project Manager and is in charge of the progress of Ponorts and has other responsibilities. The progress reports are sent by the Chief Programmer.
  
  
• Language Guru: An expert in a programming language or a specific technology. In projects where a particular programming language or technology is used for the first time, the role of a language guru is vital.
  
  
• Build Engineer: The Build Engineer is in charge of setting up the regular build process, maintaining it, and running it as well.
  
  
• Tool Smith: Since the development team, test team, and data conversion teams are required to create small development tools, Tool Smith is charged with creating the necessary tools.
  
  
• System Administrator: Responsible for configuration, management, and troubleshooting of any servers and network of workstations specific to the project team.

3. Need of FDD

FDD is useful because it shows that in a project of an iterative and incremental type, attention can be paid to domain modeling. It also explains what agile-like methodologies can scale. Most essentially, FDD demonstrates how planning and a clear understanding of the domain at the beginning of the project, helps in drafting a plan to see it through to completion. This also helps work around 'analysis and design paralysis'.

FDD is usually used for large projects. However, it is an iterative and incremental approach. The method is useful for a large team. The large team can be split into smaller, feature-focused teams. Earlier approaches divided a team based on skill sets or roles.