Feature Driven Development
Encyclopedia
Feature-driven development (FDD) is an iterative and incremental
Iterative and incremental development
Iterative and Incremental development is at the liver of a cyclic software development process developed in response to the weaknesses of the waterfall model...

 software development process
Software development process
A software development process, also known as a software development life cycle , is a structure imposed on the development of a software product. Similar terms include software life cycle and software process. It is often considered a subset of systems development life cycle...

. It is one of a number of Agile methods
Agile software development
Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams...

 for developing software and forms part of the Agile Alliance. FDD blends a number of industry-recognized best practices into a cohesive whole. These practices are all driven from a client-valued functionality (feature
Feature (software design)
The Institute of Electrical and Electronics Engineers defines the term feature in IEEE 829 as "A distinguishing characteristic of a software item ." - Feature-rich :...

) perspective. Its main purpose is to deliver tangible, working software repeatedly in a timely manner.

History

FDD was initially devised by Jeff De Luca
Jeff De Luca
Jeff De Luca is a global information technology strategist and an author in the field of software development methodology. He is considered the primary architect of Feature Driven Development circa 1999 [^JDLBIO], a lightweight methodology for developing computer software with reduced management...

 to meet the specific needs of a 15 month, 50 person software development project at a large Singapore
Singapore
Singapore , officially the Republic of Singapore, is a Southeast Asian city-state off the southern tip of the Malay Peninsula, north of the equator. An island country made up of 63 islands, it is separated from Malaysia by the Straits of Johor to its north and from Indonesia's Riau Islands by the...

 bank in 1997. Jeff De Luca delivered a set of five processes that covered the development of an overall model and the listing, planning, design and building of features. The first process is heavily influenced by Peter Coad
Peter Coad
Peter Coad is a software entrepreneur and author of books on programming. He is notable for his role in defining what have come to be known as the UML colors, a color-coded notation chiefly useful for simplifying one's understanding of a design or model.-Education:Coad received a Bachelor of...

´s approach to object modeling. The second process incorporates Peter Coad's ideas of using a feature list to manage functional requirements and development tasks. The other processes and the blending of the processes into a cohesive whole is a result of Jeff De Luca's experience. Since its successful use on the Singapore project there have been several implementations of FDD.

The description of FDD was first introduced to the world in Chapter 6 of the book Java Modeling in Color with UML by Peter Coad, Eric Lefebvre and Jeff De Luca in 1999. In Stephen Palmer
Stephen Palmer
Stephen Palmer or Steve Palmer may refer to:* Stephen Palmer * Stephen Palmer of The High Strung* Steve Palmer, footballer...

 and Mac Felsing´s book A Practical Guide to Feature-Driven Development (published in 2002) a more general description of FDD, decoupled from java modeling in color, is given.

The original and latest FDD processes can be found on Jeff De Luca´s website under the ´Article´ area. There is also a Community website available at which people can learn more about FDD, questions can be asked, and experiences and the processes themselves are discussed.

Overview

FDD is a model-driven short-iteration process that consists of five basic activities. For accurate state reporting and keeping track of the software development project, milestones that mark the progress made on each feature are defined. This section gives a high level overview of the activities.

Activities

FDD describes five basic activities that are within the software development process. In the figure on the right the meta-process model
Meta-Process Modeling
Meta-process modeling is a type of metamodeling used in software engineering and systems engineering for the analysis and construction of models applicable and useful to some predefined problems....

 for these activities is displayed. During the first three sequential activities an overall model shape is established. The final two activities are iterated
Iteration
Iteration means the act of repeating a process usually with the aim of approaching a desired goal or target or result. Each repetition of the process is also called an "iteration," and the results of one iteration are used as the starting point for the next iteration.-Mathematics:Iteration in...

 for each feature. For more detailed information about the individual sub-activities have a look at Table 2 (derived from the process description in the ´Article´ section of Jeff De Luca´s website). The concept
Concept
The word concept is used in ordinary language as well as in almost all academic disciplines. Particularly in philosophy, psychology and cognitive sciences the term is much used and much discussed. WordNet defines concept: "conception, construct ". However, the meaning of the term concept is much...

s involved in these activities are explained in Table 3.

Develop Overall Model

The project starts with a high-level walkthrough
Walkthrough
A walkthrough may refer to one of the following topics:* Strategy guide* Software walkthrough* Tutoring* Rehearsal* Audit* Virtual tour-See also:* Classroom walkthrough* Cognitive walkthrough* List of gaming topics...

 of the scope of the system and its context. Next, detailed domain walkthroughs are held for each modeling area. In support of each domain, walkthrough models are then composed by small groups which are presented for peer review
Peer review
Peer review is a process of self-regulation by a profession or a process of evaluation involving qualified individuals within the relevant field. Peer review methods are employed to maintain standards, improve performance and provide credibility...

 and discussion. One of the proposed models or a merge of them is selected which becomes the model for that particular domain area. Domain area models are merged into an overall model, the overall model shape being adjusted along the way.

Build Feature List

The knowledge that is gathered during the initial modeling is used to identify a list of features. This is done by functionally decomposing the domain into subject areas. Subject areas each contain business activities, the steps within each business activity form the categorized feature list. Features in this respect are small pieces of client-valued functions expressed in the form , for example: ´Calculate the total of a sale´ or ´Validate the password of a user´. Features should not take more than two weeks to complete, else they should be broken down into smaller pieces.

Plan By Feature

Now that the feature list is complete, the next step is to produce the development plan. Class ownership is done by ordering and assigning features (or feature sets) as classes
Class (computer science)
In object-oriented programming, a class is a construct that is used as a blueprint to create instances of itself – referred to as class instances, class objects, instance objects or simply objects. A class defines constituent members which enable these class instances to have state and behavior...

 to chief programmer
Programmer
A programmer, computer programmer or coder is someone who writes computer software. The term computer programmer can refer to a specialist in one area of computer programming or to a generalist who writes code for many kinds of software. One who practices or professes a formal approach to...

s.

Design By Feature

A design package is produced for each feature. A chief programmer selects a small group of features that are to be developed within two weeks. Together with the corresponding class owners, the chief programmer works out detailed sequence diagrams for each feature and refines the overall model. Next, the class and method prologues are written and finally a design inspection
Software inspection
Inspection in software engineering, refers to peer review of any work product by trained individuals who look for defects using a well defined process...

 is held.

Build By Feature

After a successful design inspection a per feature activity to produce a completed client-valued function (feature) is being produced. The class owners develop the actual code for their classes. After a unit test
Unit test
In computer programming, unit testing is a method by which individual units of source code are tested to determine if they are fit for use.A unit is the smallest testable part of an application. In procedural programming a unit could be an entire module but is more commonly an individual function...

 and a successful code inspection
Code review
Code review is systematic examination of computer source code. It is intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers' skills...

, the completed feature is promoted to the main build.

Milestones

Since features are small, completing a feature is a relatively small task. For accurate state reporting and keeping track of the software development project it is however important to mark the progress made on each feature. FDD therefore defines six milestones per feature that are to be completed sequentially. The first three milestones are completed during the Design By Feature activity, the last three are completed during the Build By Feature activity. To help with tracking progress, a percentage complete is assigned to each milestone. In the table below the milestones (and their completion percentage) are shown. A feature that is still being coded is 44% complete (Domain Walkthrough 1%, Design 40% and Design Inspection 3% = 44%).
|+ Table 1: Milestones
! | Domain Walkthrough
! | Design
! | Design Inspection
! | Code
! | Code Inspection
! | Promote To Build
|-
| | 1%
| | 40%
| | 3%
| | 45%
| | 10%
| | 1%
|}>

Best practices

Feature-Driven Development is built around a core set of industry-recognized best practices, derived from software engineering
Software engineering
Software Engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software...

. These practices are all driven from a client-valued feature perspective. It is the combination of these practices and techniques that makes FDD so compelling. The best practices that make up FDD are shortly described below. For each best practice a short description will be given.
  • Domain Object Modeling. Domain Object Modeling consists of exploring and explaining the domain of the problem to be solved. The resulting domain object model provides an overall framework in which to add features.

  • Developing by Feature. Any function that is too complex to be implemented within two weeks is further decomposed into smaller functions until each sub-problem is small enough to be called a feature. This makes it easier to deliver correct functions and to extend or modify the system.

  • Individual Class (Code) Ownership. Individual class ownership means that distinct pieces or grouping of code are assigned to a single owner. The owner is responsible for the consistency, performance, and conceptual integrity of the class.

  • Feature Teams. A feature team is a small, dynamically formed team that develops a small activity. By doing so, multiple minds are always applied to each design decision and also multiple design options are always evaluated before one is chosen.

  • Inspections. Inspections
    Software inspection
    Inspection in software engineering, refers to peer review of any work product by trained individuals who look for defects using a well defined process...

     are carried out to ensure good quality design and code, primarily by detection of defects.

  • Configuration Management. Configuration management helps with identifying the source code for all features that have been completed to date and to maintain a history of changes to classes as feature teams enhance them.

  • Regular Builds. Regular builds ensure there is always an up to date system that can be demonstrated to the client and helps highlighting integration errors of source code for the features early.

  • Visibility of progress and results. By frequent, appropriate, and accurate progress reporting at all levels inside and outside the project, based on completed work, managers are helped at steering a project correctly.

Metamodel (MetaModeling)

Metamodeling
Metamodeling
Metamodeling, or meta-modeling in software engineering and systems engineering among other disciplines, is the analysis, construction and development of the frames, rules, constraints, models and theories applicable and useful for modeling a predefined class of problems...

 helps visualizing both the processes and the data of a method, such that methods can be compared and method fragments in the method engineering process can easily be reused. The advantage of the technique is that it is clear, compact, and consistent with UML
Unified Modeling Language
Unified Modeling Language is a standardized general-purpose modeling language in the field of object-oriented software engineering. The standard is managed, and was created, by the Object Management Group...

 standards.

The left side of the metadata model, depicted on the right, shows the five basic activities involved in a software development project using FDD. The activities all contain sub-activities that correspond to the sub-activities in the FDD process description on Jeff De Luca´s website. The right side of the model shows the concepts involved. These concepts originate from the activities depicted in the left side of the diagram. A definition of the concepts is given in Table 3.

Tools used for Feature Driven Development

  • CASE Spec. CASE Spec is a commercial enterprise tool for Feature-Driven development.
  • TechExcel DevSuite. TechExcel DevSuite is a commercial suite of applications to enable Feature-Driven development.
  • FDD Project Manager Application. FDDPMA is a web-based effort that aims to facilitate iterative development by reducing FDD management overhead, producing graphical progress reports, and providing a workplace where all the FDD related documentation is collected.
  • FDD Tools. The FDD Tools project aims to produce an open source, cross-platform toolkit supporting the Feature Driven Development methodology.
  • FDD Viewer. FDD Viewer is a utility to display and print parking lots.

See also

  • Agile Software Development
    Agile software development
    Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams...

  • Project lifecycle
  • Software architecture
    Software architecture
    The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both...

  • Software development process
    Software development process
    A software development process, also known as a software development life cycle , is a structure imposed on the development of a software product. Similar terms include software life cycle and software process. It is often considered a subset of systems development life cycle...

  • Software engineering
    Software engineering
    Software Engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software...


External links


|+ Table 2: Activities and sub-activities
! | Activity
! | Sub-activity
! | Description> | rowspan="7" | Develop Overall Model
| | Form Modeling Team
| | The MODELING TEAM comprises permanent members from the domain and development areas, specifically the domain experts and the chief programmers. Other project staff members are then rotated through the modeling sessions so that everyone gets a chance to participate and to see the process in action.> | | Conduct Domain Walk-through
| | A domain expert gives a DOMAIN OVERVIEW of the domain area to be modeled. This should also include information that is related to this DOMAIN AREA but not necessarily a part of its implementation.> | | Study Documents
| | Optionally the team studies available REFERENCE or REFERENCED REQUIREMENTS documents such as object models, functional requirements (traditional or use-case format), data models, and user guides.> | | Develop Small Group Models
| | Forming groups of no more than three, each SMALL GROUP will compose a SMALL GROUP MODEL in support of the domain area. The Chief Architect may propose a ´strawman
Straw man proposal
A "straw-man proposal", also known as an Aunt Sally, is a brainstormed simple proposal intended to generate discussion of its disadvantages and to provoke the generation of new and better proposals. Often, a straw man document will be prepared by one or two people prior to kicking off a larger...

´ model to facilitate the progress of the teams. A member from each small group presents that groups proposed model for the domain area. The Chief Architect may also propose further model alternatives.> | | Develop Team Model
| | The MODELING TEAM selects a proposed TEAM MODEL or composes a model by merging ideas from the proposed models.> | | Refine Overall Object Model
| | Every so often, the OVERALL MODEL, consisting of an overall SEQUENCE DIAGRAM and a CLASS DIAGRAM, is REFINED with the new model shapes produced by iterations of the ‘Develop Team Model’ task above.> | | Write Model Notes
| | EXPLANATORY NOTES on detailed or complex model shapes and on significant model alternatives are made for future reference by the project.> | rowspan="2" | Build Feature List
| | Form Features List Team
| | The FEATURE LIST TEAM comprises the chief programmers from the MODELING TEAM in the process ‘Develop Overall Model’.> | | Build Features List
| | The FEATURE LIST TEAM shall identify the FEATURE LIST using the knowledge obtained from the process ‘Develop Overall Model’. This is a simple functional decomposition into SUBJECT AREAS that come from the partitioning of the domain by the domain experts for their domain area walkthroughs in the process ‘Develop Overall Model’. It is decomposed into SUBJECT AREAS that comprise BUSINESS ACTIVITIES that comprise BUSINESS ACTIVITY steps (FEATURES).> | rowspan="4" | Plan By Feature
| | Form Planning Team
| | The PLANNING TEAM comprises the development manager plus the chief programmers.> | | Determine Development Sequence
| | The main tasks in the process ‘Plan By Feature’ are not a strict sequence. Like many PLANNING activities they are considered together, with REFINEMENTS made from one or more tasks and then considering the others again. The PLANNING TEAM shall assign a DATE (month and year only) for completion of each BUSINESS ACTIVITY. The identification of the BUSINESS ACTIVITY and the completion DATE (and thus the DEVELOPMENT SEQUENCE) is based on:
  • Dependencies between FEATURES in terms of CLASSES involved;
  • Balancing load across CLASS OWNERS;
  • The complexity of the FEATURES to be implemented;
  • Bringing forward high-risk or complex BUSINESS ACTIVITIES;
  • Consideration of any external (visible) milestones such as betas, previews, feedback checkpoints and the "whole products" that satisfy such milestones.>

| | Assign Business Activities to Chief Programmers
| | The PLANNING TEAM shall assign chief programmers as owners of BUSINESS ACTIVITIES. The assignment is based on:
  • The DEVELOPMENT SEQUENCE;
  • Dependencies between FEATURES in terms of CLASSES involved;
  • Balancing load across CLASS OWNERS (remember that chief programmers are also CLASS OWNERS);
  • The complexity of the FEATURES to be implemented.>

| | Assign Classes to Developers
| | The PLANNING TEAM shall assign developers as CLASS OWNERS. Developers own multiple CLASSES. The assignment of CLASSES to developers is based on:
  • Balancing load across developers;
  • The complexity of the CLASSES;
  • The usage (e.g. high-use) of the CLASSES;
  • The DEVELOPMENT SEQUENCE.>

| rowspan="7" | Design By Feature
| | Form Feature Team
| | The Chief Programmer identifies the CLASSES likely to be involved in the design of this set of FEATURES and updates the FEATURE database accordingly. From the CLASS OWNER LIST, the Chief Programmer identifies the developers needed to form the FEATURE TEAM. As part of this step, the Chief Programmer creates a new DESIGN PACKAGE for the FEATURES(S) as part of the work package.>
| | Conduct Domain Walk-through
| | The domain expert gives a DOMAIN OVERVIEW of the domain area for the FEATURE to be designed. This should also include domain information that is related to the FEATURE but not necessarily a part of its implementation. This is an optional task based on the complexity of the FEATURE and/or its interactions.> | | Study Referenced Documents
| | The FEATURE TEAM studies the REFERENCED REQUIREMENT(S) for the feature to be designed, all COVERING MEMOS, screen designs, external system interface specifications and any other supporting documentation. This is an optional task based on the complexity of the FEATURE and/or its interactions.> | | Develop Sequence Diagram(s)
| | Develop the SEQUENCE DIAGRAM(S) required for the FEATURE to be designed. The diagram files should be checked into the version control system. Any ALTERNATIVE DESIGNS, design decisions, requirements clarifications and EXPLANATORY NOTES are also recorded and written up in the DESIGN ALTERNATIVES section of the DESIGN PACKAGE.> | | Refine Object Model
| | The Chief Programmer creates a FEATURE TEAM Area for the FEATURE(S). This area is either a directory on the file server or a directory on their PC
Personal computer
A personal computer is any general-purpose computer whose size, capabilities, and original sales price make it useful for individuals, and which is intended to be operated directly by an end-user with no intervening computer operator...

 that is backed up to the server by the Chief Programmer as required or utilizes work area support in your version control system. The purpose of the FEATURE TEAM Area is that work in progress by the FEATURE TEAM can be shared and is visible amongst the FEATURE TEAM but is not visible to the rest of the project. The Chief Programmer makes some REFINEMENTS on the model to add new / updated CLASSES, methods, attributes and/or to make changes to existing CLASSES, methods or attribute
Attribute (computing)
In computing, an attribute is a specification that defines a property of an object, element, or file. It may also refer to or set the specific value for a given instance of such....

s based on the SEQUENCE DIAGRAM(S) defined for the FEATURE(S). This results in the implementation language source files being updated in the FEATURE TEAM Area. The Chief Programmer creates model diagrams in a publishable format. These files should be checked into the version control system and submitted for publishing on the project intranet
Intranet
An intranet is a computer network that uses Internet Protocol technology to securely share any part of an organization's information or network operating system within that organization. The term is used in contrast to internet, a network between organizations, and instead refers to a network...

.> | | Write Class and Method Prologue
| | Using the updated implementation language source files from the ‘Refine Object Model’ task in the shared FEATURE TEAM Area, the development owner of each CLASS writes the CLASS AND METHOD PROLOGUE for each item defined by the FEATURE and SEQUENCE DIAGRAM(S). This includes parameter
Parameter
Parameter from Ancient Greek παρά also “para” meaning “beside, subsidiary” and μέτρον also “metron” meaning “measure”, can be interpreted in mathematics, logic, linguistics, environmental science and other disciplines....

 types, return type
Return type
In computer programming, the return type defines and constrains the data type of value returned from a method or function...

s, exceptions and messages. Once each developer has completed this task, the Chief Programmer generates the API documentation using and submits it for publication on the project intranet.> | | Design Inspection
| | A design inspection with the FEATURE TEAM members or with other project members is held. The decision to inspect within the FEATURE TEAM or with other project team members is that of the Chief Programmer. On acceptance a TODO TASK LIST is generated per affected CLASS, and each team member adds their tasks to their calendar task list. The Chief Programmer must also merge changes from the shared FEATURE TEAM Area into the change control system.> | | Inspect Code
| | A CODE INSPECTION with the FEATURE TEAM members or with other project members is held either before or after the unit test task. The decision to inspect within the FEATURE TEAM or with other project team members is that of the Chief Programmer. The decision to inspect before or after unit test is that of the Chief Programmer.> | | Conduct Unit Test
| | The development CLASS owner tests their code to ensure all requirements of their CLASS are satisfied. The Chief Programmer determines what FEATURE TEAM-level unit testing is required (if any). That is, if any testing across the CLASSES developed for this FEATURE is required.> | | Promote to Build
| | PROMOTION to the BUILD of CLASSES is only possible after a successful CODE INSPECTION. The Chief Programmer tracks the individual CLASSES being promoted, through feedback from the developers, and is the integration point for the entire FEATURE.>
Build By Feature
| | Implement Classes and Methods
| | The development CLASS owners will perform the IMPLEMENTATION of the items necessary to satisfy the requirements of their CLASS for this FEATURE.


{| class="wikitable"
|+ Table 3: Concepts
! | CONCEPT
! | Definition (source)
|-
| | BUILD PROMOTION
| | Wiki: Software build
Software build
In the field of computer software, the term software build refers either to the process of converting source code files into standalone software artifact that can be run on a computer, or the result of doing so...


|-
| | BUSINESS ACTIVITY
| | Activity undertaken as part of a commercial enterprise. (http://www.thefreedictionary.com/)
|-
| | CLASS
| | Wiki: Class
Class (computer science)
In object-oriented programming, a class is a construct that is used as a blueprint to create instances of itself – referred to as class instances, class objects, instance objects or simply objects. A class defines constituent members which enable these class instances to have state and behavior...


|-
| | CLASS AND METHOD PROLOGUE
| | The main goal of a class and method prologue is to explain the purpose of the class or method. (http://www.featuredrivendevelopment.com/files/fddprocessesA4.pdf)
|-
| | CLASS DIAGRAM
| | Wiki: Class diagram
Class diagram
In software engineering, a class diagram in the Unified Modeling Language is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, operations , and the relationships among the classes.- Overview :The class diagram is the main...


|-
| | CLASS OWNER
| | A class owner is someone responsible for the design and implementation of a class. (http://www.hst.fhso.ch/Archiv/2000/swe/otherResources/ch03/fdd.PDF)
|-
| | CLASS OWNER LIST
| | A class owner list is a list of class owners. (http://www.hst.fhso.ch/Archiv/2000/swe/otherResources/ch03/fdd.PDF)
|-
| | CODE INSPECTION
| | Wiki: Code review
Code review
Code review is systematic examination of computer source code. It is intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers' skills...


|-
| | COVERING MEMO
| | A paper that integrates and describes the design package such that it stands on its own for reviewers. (http://www.featuredrivendevelopment.com/files/fddprocessesA4.pdf)
|-
| | DATE
| | Wiki: Calendar date
Calendar date
A date in a calendar is a reference to a particular day represented within a calendar system. The calendar date allows the specific day to be identified. The number of days between two dates may be calculated. For example, "24 " is ten days after "14 " in the Gregorian calendar. The date of a...


|-
| | DESIGN ALTERNATIVE
| | Section of the Design Package containing the diagram files in the version control system, alternative designs, design decisions, requirements clarifications and notes. (http://www.featuredrivendevelopment.com/files/fddprocessesA4.pdf)
|-
| | DESIGN PACKAGE
| | Package containing:
  • A covering memo, or paper, that integrates and describes the design package such that it stands on its own for reviewers.
  • The referenced requirements (if any) in the form of documents and all related confirmation memos and supporting documentation.
  • The Sequence diagram(s).
  • Design alternatives (if any)
  • The object model with new/updated classes, methods and attributes.
  • The generated output for the class and method prologues created or modified by this design.
  • Calendar/To-Do task-list entries for action items on affected classes for each team member.

(http://www.featuredrivendevelopment.com/files/fddprocessesA4.pdf)
|-
| | DEVELOPMENT SEQUENCE
| | The planned order for completion of each business activity. The planning team shall assign a date (month and year only) for completion of each business activity. (http://www.featuredrivendevelopment.com/files/fddprocessesA4.pdf)
|-
| | DOMAIN OVERVIEW
| | The domain expert gives an overview of the domain area for the feature to be designed. This should also include domain information that is related to the feature but not necessarily a part of its implementation. This is an optional task based on the complexity of the feature and/or its interactions. (http://www.featuredrivendevelopment.com/files/fddprocessesA4.pdf)
|-
| | EXPLANATORY NOTE
| | Notes made on detailed or complex model shapes and on significant model alternatives are made for future reference by the project. (http://www.featuredrivendevelopment.com/files/fddprocessesA4.pdf)
|-
| | FEATURE
| | Features are granular functions expressed in client-valued terms using this naming template: . For example, calculate the total of a sale, calculate the total quantity sold by a retail outlet for an item description. Features are granular in accordance with the rule that a feature will take no more than two weeks to complete, but not so granular as to be at the level of getters and setters. Two weeks is an upper limit; most features take less than this time. When a business activity step looks larger than two weeks, the step is broken into smaller steps that then become features. (http://www.featuredrivendevelopment.com/files/fddprocessesA4.pdf)
|-
| | FEATURE DRIVEN DEVELOPMENT
| | Wiki: Feature Driven Development
|-
| | FEATURE LIST
| | A Feature list is intended as a potentially client deliverable piece of work. (http://www.uidesign.net/2001/papers/fddui.html)
|-
| | FEATURE LIST TEAM
| | The team comprises the chief programmers from the modeling team in process. Their task is to make a Feature list. (http://www.featuredrivendevelopment.com/files/fddprocessesA4.pdf)
|-
| | FEATURE TEAM
| | A feature team is a small, dynamically formed team that develops the feature(s) that a Chief Programmer selects for development. (http://www.featuredrivendevelopment.com/files/fddprocessesA4.pdf)
|-
| | IMPLEMENTATION
| | Wiki: Implementation
Implementation
Implementation is the realization of an application, or execution of a plan, idea, model, design, specification, standard, algorithm, or policy.-Computer Science:...


|-
| | MODELING TEAM
| | The modeling team comprises permanent members from the domain and development areas, specifically the domain experts and the chief programmers. (http://www.featuredrivendevelopment.com/files/fddprocessesA4.pdf)
|-
| | OVERALL MODEL
| | A merged domain area model. (http://www.featuredrivendevelopment.com/files/fddprocessesA4.pdf)
|-
| | PLANNING
| | Wiki: Planning
Planning
Planning in organizations and public policy is both the organizational process of creating and maintaining a plan; and the psychological process of thinking about the activities required to create a desired goal on some scale. As such, it is a fundamental property of intelligent behavior...


|-
| | PLANNING TEAM
| | The planning team comprises the development manager plus the chief programmers for making a planning. (http://www.featuredrivendevelopment.com/files/fddprocessesA4.pdf)
|-
| | REFERENCE
| | Wiki: Reference (work)
|-
| | REFERENCED REQUIREMENT
| | Need or expectation that is stated, generally implied or obligatory. (www.finnevo.fi/eng/contents/iso9000_terms.htm)
|-
| | REFINEMENT
| | Wiki: Refinement
Refinement
In formal methods, program refinement is the verifiable transformation of an abstract formal specification into a concrete executable program. Stepwise refinement allows this process to be done in stages...


|-
| | SEQUENCE DIAGRAM
| | Wiki: Sequence diagram
Sequence diagram
A sequence diagram in Unified Modeling Language is a kind of interaction diagram that shows how processes operate with one another and in what order. It is a construct of a Message Sequence Chart....


|-
| | SMALL GROUP
| | Group of no more than three that will compose a model in support of the domain area. (http://www.featuredrivendevelopment.com/files/fddprocessesA4.pdf)
|-
| | SMALL GROUP MODEL
| | A model for the domain area made by a group of no more than three. (http://www.featuredrivendevelopment.com/files/fddprocessesA4.pdf)
|-
| | SUBJECT AREA
| | An area of major interest or importance to the enterprise. It is centered on a major resource, product or activity. The subject areas provide reference information when conducting detailed requirements gathering. (www.georgetown.edu/uis/ia/dw/GLOSSARY0816.html)
|-
| | TEAM MODEL
| | A proposed model selected by the modeling team or composed by merging ideas from the proposed models. (http://www.featuredrivendevelopment.com/files/fddprocessesA4.pdf)
|-
| | TODO TASK LIST
| | Wiki: Todo list
|}
The source of this article is wikipedia, the free encyclopedia.  The text of this article is licensed under the GFDL.
 
x
OK