[Link], DEPT.

OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM

AGILE SOFTWARE DEVELOPMENT – MODULE-5

19ECS451: Agile Software Development

Module V: Feature-Driven Development:

Feature-Driven Development: Introduction, incremental software development,
Regaining Control, motivation behind FDD, planning an iterative project,
architecture centric, FDD and XP.
Test Driven Development: Unit Tests, Integration Tests, End-to-End Tests, Customer
Tests.
Release Management: Version Control, Continuous Integration.
Learning Outcomes:
After completion of this unit, the student will be able to:
1. Define Feature-Driven Development(L1)
2. Demonstrate incremental software development(L2)
3. Apply regaining control techniques(L3)
4. Develop application using TDD (L4)
5. Understand Versions, Version control and Integration of Application. (L1)
INTRODUCTION
• Planning, managing and monitoring projects that are agile, adaptive and incremental can
be very difficult.
• Adaptive, iterative projects are more complex to control, and to plan, than more traditional,
linear, waterfall models.
• One solution to control the complexity inherent in agile, incremental projects is to apply a
feature-centric process.
• A feature-centric process is one that tries to provide a way for management to handle
questions such as:
o What must we do next to add value to the client?
o How are we progressing against time and budgets?
o What issues and risks does the project face?
o How can the issues and risks be addressed or mitigated?
o What should we do next?
• Feature-centric processes do this while retaining the motivations behind the agile
movement such as:
1. Individuals and interactions over processes and tools.
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation.
4. Responding to change over following a plan.
• With the key aims being:
1. To satisfy the customer.
2. Deliver working software that adds value to the customer.
3. Working software is the primary measure of progress.
4. Promote sustainable development.
5. Keep any process as simple as is reasonably possible.

1
[Link], DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-5

• The term feature-centric refers to development processes that attempt to focus on

combining the units of requirements, with the units of planning and the units of work.
• This allows:
o the things users want,
o to be planned for and monitored,
o and to be used as the basis of work allocation.
• The big advantage of using a feature-centric approach is the potential for managing an
agile project, for handling the uncertainties that an agile approach introduces, for getting
to grips with monitoring and reporting on the project.
• A feature is a schedulable requirement associated with the activity used to realise it. These
requirements may be user-related requirements (i.e., be able to open a bank account),
application behaviour requirements (make a backup every 10 min) or internal requirements
(provide the ability to turn on debugging for system support).
• Features should have the following attributes:
- Features should be small and “useful in the eyes of system stakeholders.”
- Features can be grouped into business-related groupings (called various feature sets
or work packages).
- Features focus developers on producing elements within the system that are of tangible
benefit to system stakeholders.
- Features are prioritised.
- Features are schedulable.
- Features have an associated (estimated) cost.
- Can be grouped togetherinto shortiterations (possibly as short as twoweeks).
- Given that agile approaches are trying to keep things simple (or at least as simple as
possible without
- undermining the overall goal of producing a working system), we need some way of
managing the
- uncertainty inherent in an agile approach.
- Feature-centric management of agile projects offers this element of control.
• In FDD, Coad (1999) and Palmer and Felsing (2002) present a five-step process that
outlines how a feature-centric approach works, these five processes are:
- Process 1: Develop an overall model of the domain and create an initial feature list.
- Process 2: Build a detailed, prioritised feature list.
- Process 3: Plan by feature.
- Process 4: Design by feature.
- Process 5: Build by feature

2
[Link], DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-5

INCREMENTAL SOFTWARE DEVELOPMENT

• An incremental software development process is one that does not try to complete the whole
design task in one go. This is in contrast to the more traditional waterfall model of software
development.
• When applying some form of iterative approach, the intention is that each iteration adds
something to the evolving system. Some iterations may lead to a release of the software
system, while others may not.
Each iteration:
1. Determines what will be done during the iteration.
2. Designs and implements the required functionality.
3. Tests the new functionality
4. (Optionally) Creates a new release.
5. Reviews what has been done before moving to the next iteration.

• The end result is that you incrementally produce the system being designed. While you do
this, you explicitly identify the risks to your design/system upfront and deal with them early
on.
• One of the features of the waterfall model of software engineering used by many design
methods (see Figure 1) is that it primarily assumes that you will complete the requirements
analysis before you start the design phase.
• In turn, you will complete the design phase before you start the implementation phase, and
so on.

Figure 1. The Waterfall Model

• Figure 2 depicts the spiral nature of this approach to software development. Note that in
effect, each iteration around the spiral is a mini-software development project.
• The end result is that you incrementally produce the system being designed.

3
[Link], DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-5

• While you do this, you explicitly identify the risks to your design/system upfront and deal
with them early on.

Figure 2 Spiral Model of Software Development

THE MOTIVATION BEHIND FDD

• The iterative lifecycle model is more complex than a linear waterfall lifecycle to plan and
manage.
• Given that our goal is to simplify the lifecycle in order to deal with the risks and complexities
as well as uncertainties of the development process, we need to regain some control of the
planning and management aspects of such a project.
• A key strategy for this is feature-centric planning.
• Feature centric is not the only aspect of regaining control of an iterative project; another
feature is that of time boxing each iteration. The final aspect is being adaptive.
REGAINING CONTROL
Thus, to regain control of an iterative project the guidelines are:
• The process should be feature-centric. This means that the units of requirements (e.g., use
cases, user stories) should be unified with the units of planning (e.g., work packages and
tasks).
• Project planning should be based around timeboxes (rather than phases) so that the
length of each iteration is known.
• The project plan should be adaptive that is responsive to the changing risks and benefits
of the system and business environment.

4
[Link], DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-5

Feature-Centric Development
• The term feature-centric is used to refer to development processes that combine
the expression of requirements with the units of activity for planning purposes.
• A feature in such a process can be viewed as a unit of “plannable functionality.” A feature
is a schedulable piece of functionality, something that delivers value to the user.
• a feature is derived from a planning perspective rather than from the user perspective or
indeed the requirements perspective.
• To aid in planning, features go further, they must also be associated with:
o a priority (so that they can be ordered),
o a cost (so that they can be accounted for),
o resources (so that they can be scheduled).
• Costs and resources can be determined by examining the number of person days
taken to accomplish the feature. Priority can be harder to determine but should
take into account:
o Architectural importance of the feature.
o Utility to the user.
o Risk involved.
o Requirements of the system/use cases.
• There are other sources of information which can lead to features including
(but not limited to):
o Bug fixes.
o Maintenance enhancements (for example, due to changing to a new version
of a language or operating system).
o General tidying operations.
• These can all lead to features being added to a feature list without associated
requirements or user stories.
• Another issue is how big should a feature be? The exact size depends on the size of the
project, the nature of the work and the size of the team.
Timeboxing Iterations
• Formal development processes focus on project phases and iterative steps within them,
encompassing both modern and traditional methods like the Unified Process and waterfall
process.
• Iterative processes can be flexible but less clear for subsequent iterations, making it
difficult for budget planning, release planning, and project management. This conflict
arises between the flexible nature of iterative approaches and the constraints of budgets
and timescales, affecting fixed release dates.
• Timeboxing allows iterations to be defined by the time period and the ordered list of
features, with lower-priority features only attempted if time permits, relegating them to a
later iteration.
• Timeboxing iteration has a number of benefits including the ability to:
o schedule and plan for incremental releases of the software,
o schedule and implement features,
o manage budgets,
o monitor progress within fixed time constraints.
• All within a flexible and responsive process.

5
[Link], DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-5

Being Adaptive but Managed

• A flexible management process is necessary to adapt to changing business and user requirements,
uncertainties, and monitoring progress.
• Traditional management styles set project timelines, but iterative projects acknowledge change
and ongoing management, allowing for better resource allocation, quality assurance, and delivery
guarantee.
• An iterative project is effectively planned and re-planned at each stage of the spiral, with overall
planning activities before the process starts and weekly reviews affecting the current plan.
• Weekly monitoring of person days for tasks is crucial for managing project activity and comparing
progress with the planned effort, including holidays and sick leave.

PLANNING AN ITERATIVE PROJECT

• Before any project embarks on an iteration development process there are a number of
steps that should be followed.
• These steps are:
• Identify and prioritise features (the feature list should be continually revised throughout
the project).
• Roughly identify iterations and allocate features.
• Timebox iterations/calculate costs.
• For each iteration
◦ Plan iterations (which should be continually revised during lifetime of project).
◦ Identify tasks required to implement features.
◦ Allocate tasks to resources (that is, allocate tasks to project members).
◦ Implement iteration.

• The key here is that iterations are based on “timeboxes” so that their length is known and
can be managed.
• Iterations are also based on tasks constructed around features so that they can be responsive
to user feedback and to changing business requirements.
Iterations, Timeboxes and Releases
• At the start of the project, the project team along with various project stakeholders create
a prioritised feature list. Note that this cannot be done without the collaboration of those
project stakeholders who can state what the priorities of the features should be.
• Providing priorities like High, Medium, and Low is sufficient at this stage. Costs are related
to implementation time, typically using a Three-Point estimation approach.
• Includes, requires a best estimate, an average estimate and a worst-case estimate to be
given. The overall cost is derived from these three estimates.
• Finally, the number of software engineers involved with the feature is also estimated.
• The process involves determining the expected number of iterations, duration, and features,
requiring the involvement of business representatives with the necessary knowledge and
authority.

6
[Link], DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-5

• From this, we emerge with an outline plan for what will be done when and at what point we
will be completing various iterations of the end system (see Figure 3)

Fig. 3 Overall structure of an FDD project

Planning an Iteration
Each iteration will be comprised of a similar set of steps. These steps are presented graphically
in Figure 4.

7
[Link], DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-5

Fig. 4 The steps within an iteration

The key steps in any iteration are:

1. Iteration initiation meeting. The iteration's length, features, and resources should be revised
and confirmed, with all stakeholders involved in a meeting to ensure a comprehensive project.
2. Plan features for iteration. Having agreed the features to be addressed, a detailed plan
should be produced mapping features to work packages and work packages to tasks. The tasks
in turn should be allocated to actual resources, etc. This plan must be accepted by the key
stakeholders (including the clients).
3. Analyse the requirements associated with the features. The process may involve revising a use
case document, designing new GUI displays, and determining user interaction sequence, while
also identifying and agreeing on acceptance criteria for this iteration.

8
[Link], DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-5

4. Analyse impact on the architecture. The architecture serves as the foundation for the iterative
process, and iterating on it is crucial to assess the impact of new features and identify significant
entities.
5. (Optionally) Revise architecture as required. The process involves reevaluating and modifying
the application architecture to accommodate the necessary features, potentially involving core
feature design and analysis to assess their architectural impact.
6. new acceptance test plan and specification A new acceptance test plan and specification should
be written for this iteration, addressing specific features within the work package.
7. implementing the features The features are implemented through tasks, monitored as usual,
and each feature should have associated unit tests passed before being considered completed.
8. Once the features are implemented, the new system should be tested (this includes the
generation of a test report). This includes unit tests and acceptance tests.
9. All tests should pass before the iteration is allowed to proceed. If any tests fail, then the
release cannot be deployed and the problems must be corrected.
10. The new application should then be deployed to the client who should then perform any
agreed user acceptance tests. This may lead to the revision of the deployed system, if and when
deficiencies are identified.
10. A post iteration meeting should review the progress made during the iteration, it should
consider any issues that arose and re-prioritise any features that were not addressed. Again,
this should involve all project stakeholders.
11. At this point, a decision should also be made regarding the validity of the next iteration and
whether any further iterations are required.
• One outstanding issue for this iterative approach is what comprises the acceptance
tests at the end of an iteration.
An Aside on Planning within an FDD Project
• The author discusses their experience with feature-driven development (FDD) and a client's
surprise at the high level of planning involved in a successful project.
• They mention that the iterative and incremental approach was the only project they had
successfully delivered on time and within budget, despite the client's initial belief that it
would have less planning.
• The author's recent approach to estimating feature cost is heavily influenced by Carmichael
and Haywood's three-point estimating method, which involves producing three estimates of
the required effort.
o The best-case scenario. This represents the situations where everything goes as well
as it could and there are absolutely no surprises or problems encountered.
o The best guess at what it will really take. This represents the situation where mostly
everything goes okay, but one or two unexpected situations occur which take a little
longer than originally expected to handle.
o The worst-case scenario. This represents the situation where major issues were
overlooked
• The overall estimate for each feature is derived by applying a formula

9
[Link], DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-5

(Best case + (4 × likely case) + worst case)/6

• Finally, the other technique, producing reasonable estimates is to involve the best and most
experienced developers, designers, managers working on the project

ARCHITECTURE CENTRIC
• Feature-driven development or feature-centric development (FCD) is only feasible (and
successful) if there is a solid architecture on which each iteration can be built.
Why Architecture Centric?
• One problem with an iterative and incremental approach is that if no order or structure
was defined for the application it could grow more and more unwieldy and more and
more disorganized as each iteration progressed.
• Architecture is the skeleton of a system, ensuring functionality (muscles) and user interface
(skin). It's resilient to change and evolving design and implementation.
• The Unified Process is architecture-centric, identifying and designing necessary components
for an architecture.
Architecture Defined
• A software architecture encompasses.
the overall plan for the structure of the system. That is, it is the blueprint for the system. It should
be possible to read the architecture and gain an appreciation for how the system was structured
(without needing to know the details of the structural elements).
the key structural elements and their interfaces. That is what with which elements makeup the
system, their interfaces and how they are plugged together.
How those elements interact (at the top level). That is, when the various elements of the
architecture interface, what do they do and why do they do it.
how these elements form subsystems and systems. This is a very important aspect of the
architecture. Early identification of the core systems and subsystem of the design not only helps
organise future design (and implementation) work, it helps promote reuse and the
comprehensibility of the system. architectural style that guides this project.
the software architecture also involves:
o How the system will be used?
o What the functionality of the final system is expected to be?
o Any performance issues that need to be addressed
o Resilience to further development.
o Economic and technology constraints and trade-offs.
Why Have an Architecture?
• architecture is a critical element of the object-oriented design process.

10
[Link], DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-5

• understand the system. An architecture is a blueprint or model for large, complex software
systems, abstracting implementation details while positioning elements for functional
requirements.
• organise development. This system organizes "plumbers" and "electricians" by separating
concerns, focusing on plumbing issues, and identifying their interconnectedness, ensuring well-
documented and clearly specified points.
• promote reuse. Reusable code requires identifying its reusable nature. Repeated design and
implementation can make it easier to produce reusable code. Class-level reuse is common in
many systems, but architecture can help identify critical systems and subsystems early on.
Common subsystems can then be made reusable at the reusable level.
• promote continued development. A system's evolution over time is common, with new
requirements and functionality added or modified. The original architecture helps control
this evolution, controlling it within and between releases. A good architecture requires
minimal change but is instrumental to future releases, providing a structure for new additions
or modifications. It minimizes potential misinterpretation or ignore of design.
Architecture Myths
• it is important to realise that the architecture and the design are not the same thing, but it is
important to re-iterate this.
• The architecture highlights the most significant elements of the design. These include the major
systems and subsystems, their interfaces, how the system will be deployed, etc. It
does not include many details of the systems and subsystems and how they are implemented
– that is the job of the design.
• Another myth to be debunked is that the architecture and the infrastructure are the same
thing.
• the architecture only captures those elements of the design that are necessary to provide an
understanding of the overall design of the system.
• for the infrastructure of the system, i.e. the essential functionality of the system
Plan Incremental Build of Software
• Having architecture in place allows for an incremental, feature-centric approach to
implementation and extension. This involves identifying appropriate subsystems, active
classes, and interfaces, with approaches like FDD managing development.
FDD AND XP
• Focusing on iterative project planning and FDD, agile methods like Agile Modelling and
eXtreme Programming can be used for modeling and implementing solutions.
• Feature-driven development provides a way of controlling the iterative and incremental
nature of agile projects. It does not really have anything to say about how you implement
those features.
• Features can be implemented in a variety of different ways using a variety of techniques.
However, taking an agile approach means that applying the techniques can work extremely
well
• Within a development model in which FDD is used to plan the details of iterations and in
which features are treated as the tasks to be performed, then applying Agile Modelling
and XP practices can result in a workflow resembling that presented in Figure 5.

11
[Link], DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-5

• we are using Agile Modelling to allow any modelling activities to take place and XP
practices to implement the required behaviour
• an explicit analysis step that involves some design and/or modelling work in order to
determine how the feature should be implemented or broken down into tasks.

Fig. 5 Combining FDD with Agile Medelling and XP

12
[Link], DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-5

TEST DRIVEN DEVELOPMENT

• Test-driven development (TDD), also called test-driven design, is a method of implementing
software programming that interlaces unit testing, programming and refactoring on source
code.
• Test-driven development was introduced as part of a larger software design paradigm
known as Extreme Programming (XP), which is part of the Agile software development
methodology.
• Before any new code is written, the programmer must first create a failing unit test. Then,
the programmer -- or pair, or mob -- creates just enough code to satisfy that requirement.
Once the test is passing, the programmer may refactor the design, making improvements
without changing the behavior.
• While TDD focuses on the programmer interactions at the unit level, there are other popular
methods, such as acceptance-test-driven development (ATDD) or behavior-driven
development (BDD), which focus on tests that can be understood by customers.
• These methods involve creating concrete examples as tests in collaboration between the
technical staff and customer before the code is created, and then running the tests after the
code is created to demonstrate the code is implemented.
• Having the tests known upfront improves first-time quality. ATDD and BDD require
developers, testers and the business side to collaborate to imagine and discuss the software
and its implications before the code is created
TYPES OF TESTING
UNIT TESTING
• Unit Testing is a type of software testing where individual units or components of a
software are tested.
• The purpose is to validate that each unit of the software code performs as expected.
• Unit Testing is done during the development (coding phase) of an application by the
developers. Unit Tests isolate a section of code and verify its correctness. A unit may be
an individual function, method, procedure, module, or object.
• In SDLC, STLC, V Model, Unit testing is first level of testing done before integration
testing. Unit testing is a WhiteBox testing technique that is usually performed by the
developer. Though, in a practical world due to time crunch or reluctance of developers
to tests, QA engineers also do unit testing
INTEGRATION TESTING
• Integration testing (sometimes called integration and testing, abbreviated I&T) is the
phase in software testing in which individual software modules are combined and tested
as a group.
• Integration testing is conducted to evaluate the compliance of a system or component
with specified functional requirements. It occurs after unit testing and before system
testing.
• Integration testing takes as its input modules that have been unit tested, groups them in
larger aggregates, applies tests defined in an integration test plan to those aggregates,
and delivers as its output the integrated system ready for system testing.

13
[Link], DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-5

END TO END TESTING

• End-to-end testing is a technique that tests the entire software product from beginning to
end to ensure the application flow behaves as expected. It defines the product’s system
dependencies and ensures all integrated pieces work together as expected.
• The main purpose of End-to-end (E2E) testing is to test from the end user’s experience by
simulating the real user scenario and validating the system under test and its components for
integration and data integrity.
• Software systems nowadays are complex and interconnected with numerous subsystems. If
any of the subsystems fails, the whole software system could crash. This is a major risk and
can be avoided by end-to-end testing.
CUSTOMER TESTING/ USER TESTING
• User testing is the practice of putting end users into contact with your products or services
and taking note of their responses and reactions.
• By conducting user testing, you can gauge how positive the average customer experience is
and whether or not the product or service is performing as you intend. This is invaluable for
finding flaws and targeting improvements. It can also help you discover ways of using your
products that you may not have had in mind at first, but that users find beneficial.
• User testing can be done even before you have a real product prototype or service design
in hand. To do this successfully involves testing at the product prototyping stage, or even as
part of product concept testing when ideas first emerge.
• The practice of user testing can also be used once a product is live and on sale. Instances of
this include general user feedback, which can guide and influence a re-release or upgrade.
RELEASE MANAGEMENT
• The Agile approach to release management is called continuous development. Continuous
development is the ability to get changes of all types—such as new features, configuration
changes, bug fixes, and experiments—into production or into the hands of users safely and
quickly in a sustainable way.
• Just as in the Agile development process, releases also consist of small bundles of high-
priority, high-value features (or sometimes a single feature). So agile teams have smaller
and more frequent releases than traditional ones.
VERSION CONTROL
• Version managers devise procedures to ensure that versions of a system may be retrieved
when required and are not accidentally changed by the development team.
• For products, version managers work with marketing staff and for custom systems with
customers, to plan when new releases of a system should be created not distributed for
deployment.
• A system instance is an instance of a system which can be different from other instances in
some way. There is a chance in which versions of the system may have different functionality,
enhanced performance or repaired software faults.
• Some versions may be functionally equivalent but designed for different hardware or
software configuration. Versions with only small differences are sometimes called variants.

14
[Link], DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-5

• CVS is the Concurrent Versions System, the dominant open-source networktransparent

version control system. CVS is useful for everyone from individual developers to large,
distributed teams:
• Its client–server access method let developers access the latest code from anywhere if there
is an Internet connection.
• Its unreserved check-out model to version control avoids artificial conflicts common with the
exclusive check-out model.
• Its client tools are available on most platforms. CVS is used by popular open-source projects
like Mozilla, the GIMP, XEmacs, KDE and GNOME.
CONTINUOUS INTEGRATION
• The practice of continuous integration advises developers to merge their code with the main
repository as often as possible.
• An automated build is extracted for each check-in and goes through automated test cases,
which helps catch integration errors early. This ensures the main code branch stays updated
at all times.
• The benefits of an effortless release without the integration hassles outweigh the costs of
setting up automated tests.
• The key to continuous integration is that pair programmers should work in small steps and
that these small steps can be integrated. Remember the way in which pair programmers
should work:
1. Write a test.
2. Write the code stubs.
3. Make sure everything compiles so far.
4. Run the test – it should fail. That’s okay.
5. Implement stubs.
6. Make sure the test is passed before continuing.
7. Make sure all tests can pass before continuing further.
8. Integrate the now working code into the current build.
9. Return to step 1 until complete.

15