Lecture
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.
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.
FDD includes five basic activities:
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 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.
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.
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.
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.
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 ).
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%)
Area analysis | Design | Design check | Code | Code check | Assembly Build |
one % | 40% | 3% | 45% | ten % | one % |
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:
Comments
To leave a comment
Software and information systems development
Terms: Software and information systems development