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.

Twelve principles underlie the Agile Manifesto, they are:

 Customer satisfaction by rapid delivery of useful software

 Welcome changing requirements, even late in development
 Working software is delivered frequently (weeks rather than months)
 Working software is the principal measure of progress
 Sustainable development, able to maintain a constant pace
 Close, daily co-operation between business people and developers
 Face-to-face conversation is the best form of communication (co-location)
 Projects are built around motivated individuals, who should be trusted
 Continuous attention to technical excellence and good design
 Simplicity
 Self-organizing teams
 Regular adaptation to changing circumstances

There are many specific agile development methods. Most promote development, teamwork, collaboration, and process adaptability
throughout the life-cycle of the project.
Agile methods break tasks into small increments with minimal planning, and do not directly involve long-term planning. Iterations are short
time frames (time boxes) that typically last from one to four weeks. Each iteration involves a team working through a full software development
cycle including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to
stakeholders. This minimizes overall risk and allows the project to adapt to changes quickly. Stakeholders produce documentation as required.
Iteration may not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the
end of each iteration. Multiple iterations may be required to release a product or new features.Well-known agile software development
methods include:

 Agile Modeling

 Agile Unified Process (AUP)

 Dynamic Systems Development Method (DSDM)

 Essential Unified Process (EssUP)

 Extreme Programming (XP)

 Feature Driven Development (FDD)

 Open Unified Process (OpenUP)

 Scrum

 Velocity tracking

Feature Driven Development (FDD) is an iterative and incremental software development process. It is one of a number of Agile methods for
developing software and forms part of the Agile Alliance. Its main purpose is to deliver tangible, working software repeatedly in a timely
manner.
FDD describes five basic activities that are within the software development process

1. 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 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
2. Build Feature List
  Form Features List Team: The FEATURE LIST TEAM comprises the chief programmers from the MODELING TEAM.
 Build Features List: The FEATURE LIST TEAM shall identify the FEATURE LIST using the knowledge obtained from the
process ‘Develop Overall Model’.
3. Plan By Feature
 Form Planning Team: The PLANNING TEAM comprises the development manager plus the chief programmers.
 Determine Development Sequence: The PLANNING TEAM shall assign a DATE (month and year only) for completion of
each BUSINESS ACTIVITY.
 Assign Business Activities to Chief Programmers: The PLANNING TEAM shall assign chief programmers as owners of
BUSINESS ACTIVITIES.
 Assign Classes to Developers: The PLANNING TEAM shall assign developers as CLASS OWNERS. Developers own multiple
CLASSES.
4. 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.
 Conduct Domain Walk-through: The domain expert gives a DOMAIN OVERVIEW of the domain area for the FEATURE to
be designed. 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 Diagrams: Develop the SEQUENCE DIAGRAM(S) required for the FEATURE to be designed.
 Refine Object Model: 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 attributes based on the SEQUENCE
DIAGRAM(S) defined for the FEATURES.
 Write Class and Method Prologue: Owner of each CLASS writes the CLASS AND METHOD PROLOGUE for each item
defined by the FEATURE and SEQUENCE DIAGRAM(S). This includes parameter types, return types, exceptions and
messages. Once each developer has completed this task, the Chief Programmer generates the API documentation  and
submits it for publication.
 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.
5. 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.
 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.
 Conduct Unit Test: The development CLASS owner tests their code to ensure all requirements of their CLASS are satisfied.
 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.
 http://en.wikipedia.org/wiki/Feature_Driven_Development

http://en.wikipedia.org/wiki/Feature_Driven_Development#SMALL_GROUP
http://en.wikipedia.org/wiki/Agile_software_development