Module V

Topics
• 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
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
Incremental Software Development

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
Incremental Software Development
Incremental Software Development

• Figure depicts the spiral nature of this approach to software development. here each
iteration around the spiral is a mini-software development project.
• 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
• The iterations within XP projects tend to be between 1 and 3 weeks, with new releases at
the end of most iterations
• An iterative approach may still be relevant, but the iterations may be in terms of months
rather than weeks
Feature-Driven Development
• FDD stands for Feature-Driven Development. It is an agile iterative
and incremental model that focuses on progressing the features of the
developing software.

• The main motive of feature-driven development is to provide timely

updated and working software to the client.

• In FDD, reporting and progress tracking is necessary at all levels.

FDD Lifecycle
• Build overall model
• Build feature list
• Plan by feature
• Design by feature
• Build by feature
Characteristics of FDD

• Short iterative: FDD lifecycle works in simple and short iterations to

efficiently finish the work on time and gives good pace for large projects.
• Customer focused: This agile practice is totally based on inspection of
each feature by client and then pushed to main build code.
• Structured and feature focused: Initial activities in lifecycle builds the
domain model and features list in the beginning of timeline
• Frequent releases: Feature-driven development provides continuous
releases of features in the software and retaining continuous success of the
project.
Advantages of FDD
• Reporting at all levels leads to easier progress tracking.
• FDD provides continuous success for larger size of teams and projects.
• Reduction in risks is observed as whole model and design is build in smaller
segments.
• FDD provides greater accuracy in cost estimation of the project due to feature
segmentation

Disadvantages of FDD
• This agile practice is not good for smaller projects.
• There is high dependency on lead programmers, designers and mentors.
• There is lack of documentation which can create an issue afterwards
Regaining Control :The Motivation Behind FDD
• To manage such a project in an agile manner?
----------This is where feature-driven development will come-in.

• The Motivation Behind FDD

• 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. 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
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.”
• Feature-driven development (FDD) uses features in this way.
• Features are closely related to use cases and to the realisation of use cases in the
standard Unified Process.
• A feature is a schedulable piece of functionality, something that delivers value to the
user.
• The emphasis on schedulable. That is, 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:
• a priority (so that they can be ordered),
• a cost (so that they can be accounted for),
• 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
Test-Driven Development

Feature specifications

Test case design

Write source code

Bug fixing
Unsuccessful
Code change Run

Successful
Refactoring

Software
14
Test-Driven Development
• Developed software goes through a repeated maintenance process due to lack of
quality and inability to satisfy the customer needs.
• System functionality is decomposed into several small features.
• Test cases are designed before coding.
• Unit tests are written first for the feature specification and then the small source
code is written according to the specification.
• Source code is run against the test case.
• It is quite possible that the small code written may not meet the requirements, thus it
will fail the test.
• After failure, we need to modify the small code written before to meet the
requirements and run it again.
• If the code passes the test case implies the code is correct. The same process is
repeated for another set of requirements specification
Levels of Testing
• Testing is a defect detection technique that is performed at various levels. Testing
begins once a module is fully constructed.
• Although software engineers test source codes after it is written, but it is not an
appealing way that can satisfy customer’s needs and expectations.
• Software is developed through a series of activities, i.e., customer needs,
specification, design, and coding.
• Each of these activities has different aims. Therefore, testing is performed at
various levels of development phases to achieve their purpose.

Continue.. 16
Unit test
• Unit means a program unit, module, component, procedure, subroutine of a system
developed by the programmer.
• The aim of unit testing is to find bugs by isolating an individual module using test
stub and test drivers and by executing test cases on it.
• The unit testing is performed to detect both structural and functional errors in the
module.
• Therefore, test cases are designed using white-box and black-box testing strategies
for unit testing.
• Most of the module errors are captured through white-box testing
Unit test envirnoment
Integration Testing

• Integration testing is another level of testing, which is performed

after unit testing of modules.
• It is carried out keeping in view the design issues of the system into
subsystems.
• The main goal of integration testing is to find interface errors
between modules.
• There are various approaches in which the modules are combined
together for integration testing.
• Big-bang approach
• Top-down approach
• Bottom-up approach
• Sandwich approach
Big-bang approach

• The big-bang is a simple and straightforward integration testing.

• In this approach, all the modules are first tested individually and then these
are combined together and tested as a single system.
• This approach works well where there is less number of modules in a system.
• As all modules are integrated to form a whole system, the chaos may occur.
If there is any defect found, it becomes difficult to identify where the defect
has occurred.
• Therefore, big-bang approach is generally avoided for large and complex
systems.
Top-down approach

• Top-down integration testing begins with the main module and move
downwards integrating and testing its lower level modules.
• Again the next lower level modules are integrated and tested.
• Thus, this incremental integration and testing is continued until all
modules up to the concrete level are integrated and tested.
• The top-down integration testing approach is as follows:
• main system -> subsystems -> modules at concrete level.
• In this approach, the testing of a module may be delayed if its lower
level modules (i.e., test stubs) are not available at this time.
• Thus, writing test stubs and simulating to act as actual modules may be
complicated and time-consuming task.
Integration Testing
Top-down approach
M

S1 S2 S3

M1.1 M1.2 M2.1 M3.1 M3.2 M3.3

Figure 9.14: Top-down integration

Continue.. 23
Bottom-up approach
• As the name implies, bottom-up approach begins with the individual testing of
bottom-level modules in the software hierarchy.
• Then lower level modules are merged function wise together to form a
subsystem and then all subsystems are integrated to test the main module
covering all modules of the system.
• The approach of bottom-up integration is as follows:
concrete level modules -> subsystem –> main module.
• The bottom-up approach works opposite to the top-down integration
approach.
Sandwich approach

• The sandwich testing combines both top-down and bottom-up

integration approaches.
• During sandwich testing, top-down approach force to the lower level
modules to be available and bottom-up approach requires upper level
modules.
• Thus, testing a module requires its top and bottom level modules.
• It is the most preferred approach in testing because the modules are
tested as and when these are available for testing
End To End Testing
End To End Testing

• End-to-end testing is a Software testing methodology to test an application

flow from start to end.
• The purpose of this testing is to simulate the real user scenario and validate
the system under test and its components for integration and data integrity.
• It is performed from start to finish under real-world scenarios like
communication of the application with hardware, network, database, and
other applications.
• The main reason for carrying out this testing is to determine various
dependencies of an application as well as ensure that accurate information is
communicated between various system components. It is usually performed
after the completion of functional and system testing of any application.
End To End Testing example of Gmail:

End to End Verification of a Gmail account will include the following steps:
1. Launching a Gmail login page through URL.
2. Logging into Gmail account by using valid credentials.
3. Accessing Inbox. Opening Read and Unread emails.
4. Composing a new email, reply or forward an email.
5. Opening Sent items and checking emails.
6. Checking emails in the Spam folder
7. Logging out of Gmail application by clicking ‘logout
Customer test/Acceptance Testing

The user involvement is important during acceptance testing of the software as it

is developed for the end-users.
Acceptance testing is performed at two levels, i.e.,
Alpha testing
Beta testing.
Alpha testing is a pilot testing in which customers are involved in exercising test
cases.
o In alpha testing, customer conducts tests in the development environment. The users perform
alpha test and tries to pinpoint any problem in the system.
o The alpha test is conducted in a controlled environment.
o After alpha testing, system is ready to transport the system at the customer site for deployment
Beta testing
Beta testing is performed by a limited and friendly customers and end-users.
Beta testing is conducted at the customer site, where the software is to be
deployed and used by the end-users.
o The developer may or may not be present during beta testing.
o The end-users operate the system under testing mode and note down any problem
observed during system operation.
o The defects noted by the end-users are corrected by the developer.
o If there are any major changes required, then these changes are sent to the
configuration management team.
o The configuration management team decides whether to approve or disapprove the
changes for modification in the system
Shadow testing

• Shadow testing is conducted in case of maintenance or

reengineering type of projects.
• In this testing, the new system and the legacy system are run
side-by-side and their results are compared.
• Any unusual results noted by end-user are informed to the
developers that they take corrective actions to remove the
problems.
Benchmark testing
• In benchmark test, client prepares test cases to test the system
performance. The benchmark test is conducted either by end-users
or testers.
• Before performing benchmark test, tester or end-users must be
familiar with the functional and nonfunctional requirements of the
system.
• Benchmark testing helps to assess product’s performance against
other products in a number of areas including functionality,
durability, quality, etc.
version control
• A version control system to handle the frequent and rapid changes introduced into the
software and to allow the software to roll back when necessary.
• Version control, also known as source control, is the practice of tracking and managing
changes to software code. Version control systems are software tools that help software
teams manage changes to source code over time.
• As development environments have accelerated, version control systems help software
teams work faster and smarter.
• They are especially useful for DevOps teams since they help them to reduce development
time and increase successful deployments.
• Version control software keeps track of every modification to the code in a special kind of
database.
• If a mistake is made, developers can turn back the clock and compare earlier versions of
the code to help fix the mistake while minimizing disruption to all team members.
Version control

•
Advantages of version control systems

• Using version control software is a best practice for high performing software and DevOps
teams.
• Version control also helps developers move faster and allows software teams to preserve
efficiency and agility as the team scales to include more developers.
• Version Control Systems (VCS) have seen great improvements over the past few decades and
some are better than others.

• VCS are sometimes known as SCM (Source Code Management) tools or RCS (Revision
Control System).
• One of the most popular VCS tools in use today is called Git. Git is a Distributed VCS, a
category known as DVCS
Main benefits you should expect from version control are

• A complete long-term change history of every file. This means every change made by
many individuals over the years. Changes include the creation and deletion of files as
well as edits to their contents.

• Different VCS tools differ on how well they handle renaming and moving of files.
This history should also include the author, date and written notes on the purpose of
each change.
• Having the complete history enables going back to previous versions to help in root
cause analysis for bugs and it is crucial when needing to fix problems in older
versions of software. If the software is being actively worked on, almost everything
can be considered an "older version" of the software
Advantages of version control systems

• Traceability: Being able to trace each change made to the software and connect it to
project management and bug tracking software such as Jira, and being able to annotate
each change with a message describing the purpose and intent of the change can help not
only with root cause analysis and other forensics.
• Having the annotated history of the code at your fingertips when you are reading the
code, trying to understand what it is doing and why it is so designed can enable
developers to make correct and harmonious changes that are in accord with the intended
long-term design of the system.
• This can be especially important for working effectively with legacy code and is crucial
in enabling developers to estimate future work with any accuracy.
Continuous Integration
• Continuous integration. New code is integrated and the system rebuilt every time a task is
completed (which may be many times a day).
• The aim when trying to implement “continuous integration” it not to integrate every 5 min,
but between one and several times per day.
• The aim is to avoid the problems encountered with big bang integrations. Big bang
integrations happen when a period of time (typically days or weeks rather than hours) has
elapsed. In many situations, the act of integrating all the code can take days in itself.
• In one project, the integration took a week just to get to the point that all the code compiled
(it had yet to be tested!). One developer, in particular, seemed to have gone off on their own
causing chaos.
• Big bang integrations slow development projects down and can help to create a culture of
blame.
Continous integration
The reason for regular integration (every few hours) is to help you find out:

1. Have you broken anything?

2. Has anyone broken anything you have done with his or her changes?
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.