Feature Driven Development Or Fdd Information Technology Essay

Feature driven development or FDD was further developed by Jeff De Luca to lead a software development project for a large bank in Singapore in the year 1997. The project needs to be done by 15 month and 50 employees were involved for completing the project. Another person that introduced features into the FDD development was Peter Coad. Peter Coad used object modeling and feature list as an approach to make the project meet the requirements and develop the tasks for completing the project.

FDD emphasizes on starting a project by first having a detailed plan of conducting the overall process by including the main planning, object model and feature list at the starting point of the project. These items can evolved freely because each process does not affect greatly on each other.

The project manager serves as the administrative leader for the project. He or she makes sure that the project operates systematically and ensures that all the participants are focused on the task.

Chief Architect

The chief architect holds the responsibility for designing the overall system. They also need to consider all the design issues and make critical decisions.

Development Manager

The role for the development manager is to handle the day to day activities in the progress of the project and ends the conflict between that happens within the team.

Chief Programmer

The chief programmer is usually an experienced developer. They are mainly involved in leading smaller teams for the analysis, design and development of new features. The chief programmer also needs to identify the characteristics of the feature team so that he can choose the right classes and owners that are appropriate. Sometimes the chief programmers will need to work together to solve problems such as resourcing issues and report on the progress of the team.

Class Owners

Class owners are responsible for the class that has been assigned to. They are under the guidance of the chief programmer. Their work responsibilities include designing, coding, testing and documenting.

Domain Experts

The domain experts have the probability of a user, client, a sponsor, a business analyst or a combination of the previously mentioned. The developers rely on the knowledge of the domain expert on the requirements of the undeveloped system should perform.

The next other roles below are roles that does not dominate the important roles but rather acts as a supporting role and additional roles in the structure of FDD methodology.

?

Domain Object Modeling

The main motive of this practice is to make all the stakeholders voice out there ideas so that the project has a guideline or a road map to where it is going. The object model is a continuously updated process for rooms of correction.

Developing By Feature

This practice emphasize that the FDD development is done by completing each feature before moving to the next. This feature works by collecting the point of views from the client which will be evaluated and take into consideration. It can be expressed in the form of <action><result>,<object> and achieving equilibrium between these actions. This feature usually can be completed within hours or days and have a maximum 2 weeks for completing the task.

Class (code) Ownership

Each developer or class owner is responsible for his/her class, hence it is very important that the class owner knows what are the goals that need to be achieved and he or she must understand the characteristics and behavior of the class. This is in order that the class owner will be the first one to inform and update the class for any changes that needs to be implemented on the project so that the class can adapt much faster to the situation. There is the risk of losing a team member in the class which might be a danger to the project. Hence involvement from the class owner is very important in this practice to make sure he or she has control of the class.

Feature Teams

In a feature team, the owner of the feature or also known as the chief programmer works with the class owners as a team. The implementation of the feature should be done very quick and effectively. This practice also has the characteristic of flexibility when changes occur. The required class owner is just added to the feature team depending on the requirements.

The feature teams are combined and then breaks up after the feature has been completed. Sometimes the feature teams works together with other feature teams and a time and an individual maybe working for a few feature teams at a time. The work of a feature team ends when their feature has been integrated to the product.

Inspections

This practice in FDD is to make sure that the quality and the design and code are up to standard. Besides that, there are 2 other main purpose for this practice which is to make sure the team members understands the other classes that are involved and the other purpose is to act as a forced function to maintain the consistency of the project¿½¿½s coding standards.

Regular Build Schedule

This practice is encouraged to be done often and continuously based on the need of the project. It should be a practice that is done at more than once in a week. When a new feature has been updated to the current system baseline, it can then be tested and then be documented after demonstration to the customers or the project sponsors.

Configuration Management

This practice in FDD is dependent on the size, scope and complexity of the project. There is no unique structure for the configuration management for the FDD development but the team must make sure that they manage their artifacts well.

Reporting/Visibility of Results

The FDD uses a project tracking methodology to prevent that the project is done half way before entering the next task. The feature list is referred to build the milestones that need to be achieved and some weighing factors of it. The FDD mile stones can be defined as follow:

Domain walkthrough¿½¿½complete;

Design¿½¿½ready for inspection;

Design inspection¿½¿½and any rework and reinspection complete;

Code¿½¿½ready for inspection;

Code inspection¿½¿½and any rework and reinspection complete;

Promote to build¿½¿½all feature code checked in and ready for the next build;

The weight for each milestone uses a simple computation method. It is simply the time required for that feature to be completed divide by the overall time needed to complete the overall feature. For example, if the design walkthrough requires 5% of their time to complete, then the weight for the milestone is to be 0.05(5% divide by 100).

For computing the project status, it is the total milestones that have been completed divide by the number of features. For example, the current completed milestones are 183 in weight and the features are 200. Then the completion of the project is:

Project status =(sum of currently completed milestones)/(the total number feature in the product)¿½¿½100%

= 183/200¿½¿½100%

= 91.5%

Advantages and Disadvantages of the Feature Driven Development

Advantages Disadvantages

It is better defined and measured by its 8 practices rather then the process flow.

Create efficiency of individuals at making changes to a class The lost of the individual will bring a negative effect on the feature team.

Owns the dynamic and flexible characteristics at adding required owners to a feature team. Lack emphasis on the configuration management. Should be a more detailed structure.

Inspections are emphasized to ensure quality of design and codings.

Sets milestones and ensures that the feature is done before continuing the next.

Discussions:

The feature driven development requires the owner of each class is fully involved in the feature and take responsibility for his or her class.

Motivation is instill to the owner to work efficiently.

The overall assumption from the stakeholders is very important to develop the object model of the project.

The features must be first identified to make the project flow more smoothly.

The milestones make sure that the previous progress is done before moving on to the next. This step is smart to prevent continuous work an unfinished task.

Conclusion:

The feature driven development provides good flexibility when a feature needs to be developed. Class owners are able to combine and disband based on the needs when developing the feature makes this methodology a very dynamic characteristic.