UNIT-1

1. Discuss the advantages & Disadvantages of Agile Method?

The advantages of the Agile Model are as follows −

• Is a very realistic approach to software development.
• Promotes teamwork and cross training.
• Functionality can be developed rapidly and demonstrated.
• Resource requirements are minimum.
• Suitable for fixed or changing requirements
• Delivers early partial working solutions.
• Good model for environments that change steadily.
• Minimal rules, documentation easily employed.
• Enables concurrent development and delivery within an overall planned context.
• Little or no planning required.
• Easy to manage.
• Gives flexibility to developers.
The disadvantages of the Agile Model are as follows −
• Not suitable for handling complex dependencies.
• More risk of sustainability, maintainability and extensibility.
• An overall plan, an agile leader and agile PM practice is a must without which it will not work.
• Strict delivery management dictates the scope, functionality to be delivered, and adjustments to
meet the deadlines.
• Depends heavily on customer interaction, so if customer is not clear, team can be driven in the
wrong direction.
• There is a very high individual dependency, since there is minimum documentation generated.
• Transfer of technology to new team members may be quite challenging due to lack of
documentation.

2. What are Challenges in Migrating from Traditional to Agile?

The traditional SDLC models like the waterfall model is based on a predictive approach. Predictive
teams in the traditional SDLC models usually work with detailed planning and have a complete forecast
of the exact tasks and features to be delivered in the next few months or during the product life cycle.
Predictive methods entirely depend on the requirement analysis and planning done in the beginning of
cycle. Any changes to be incorporated go through a strict change control management and prioritization.
Agile uses an adaptive approach where there is no detailed planning and
there is clarity on future tasks only in respect of what features need to be developed. There is feature
driven development and the team adapts to the changing product requirements dynamically. The product
is tested very frequently, through the release iterations, minimizing the risk of any major failures in
future. Customer Interaction is the backbone of this Agile methodology, and open communication with
minimum documentation are the typical features of Agile development environment. The agile teams
work in close collaboration with each other and are most often located in the same geographical location.

Traditional Model Agile Model

1. Follows a top down approach, and making 1. Team conducts experiments on various
changes is not easy as finishing one phase leads techniques and gradually arrives at the best
to another possible solution
2. In agile, there is free flow of communication,
2. It has a leadership style of working
anyone can present their ideas within the team
3. This is more flexible as compared to
3. Pre-planning is done to carry out the various
traditional model, as it can change it's work flow
phases
based on any new request for modifications
4.Customer is involved only in the initial phases 4. Customer involvement is crucial for this model
of requirements gathering to prove its mettle
5. Project work is delivered to the client in small
amount, that is, as and when one module is
5. The project plan is prepared before
prepared, a demonstration is given to the client,
commencing the process of system development
so as to confirm the work progress in a right
direction
6.It has the concept of shared ownership, i.e,
6. The ownership lies on the Project manager every team member is equally responsible for
their individual contribution
7. Believes in one-time delivery of the product 7. Relies on incremental delivery of the product

3. How will you deal with frequently changing requirements?

4 Ways Scrum Helps You Welcome Changing Requirements

1. Empowers the Product Owner

The Product Owner is a very powerful role in Scrum, and part of its power is due to its ability to
determine how and when to adapt to change.

The Product Owner is responsible for deciding the priority and order of the backlog—and what is in it.
This responsibility means that as the Development Team creates a product increment, the Product Owner
can focus on performing market research, engaging with customers, and seeking additional feedback from
stakeholders.
All of this information allows the Product Owner to seek a competitive advantage for the customer. The
Product Owner may learn of new market demands, discover new customer needs, or develop a new
understanding of business direction and strategy that lead to new, emergent requirements. The Product
Owner has the power and authority to prioritize new requirements over existing ones, for example, or
change existing requirements to better reflect what has been learned.The Product Owner is the front line
in harnessing change for competitive advantage .

2. Allows Organizations to Establish a Sprint Cadence that Balances Risk and Change

Each organization can establish a cadence that provides the Development Team the stability it needs to
create a product increment without distraction or interruption, but also mitigates against the volatility of
the marketplace. For environments in which change is not as frequent, a four-week Sprint may work;
however, if planning with a one-month horizon isn’t feasible or is too risky, the organization can opt for a
shorter time frame.

3. Provides a Mechanism for Customer Feedback

One of the fundamental realities of product development is that people often don’t really know what they
want until they start to use the product. The Sprint Review provides regular opportunities for customers
and stakeholders to evaluate what has been built so far and collaborate with the Scrum Team to determine
the most valuable thing to do next. That collaboration often leads to new or changed requirements that the
Product Owner can incorporate into the Product Backlog.

Scrum doesn’t merely allow for changing requirements, it generates them. This is how Scrum “harnesses
change for the customer’s competitive advantage”—by encouraging the customer to collaborate with the
Scrum Team on changing direction.

4. Offers an Escape Route

It’s always possible that an earth-shaking change in circumstance could arise and make the current Sprint
Goal and everything in it obsolete: A competitor releases a product that makes what you’re working on
useless. A new regulation demands immediate attention. A security threat requires an immediate patch
and drastic architectural modifications.

For dramatic situations like these, Scrum has an escape valve: canceling a sprint. If the Sprint Goal is no
longer valid, a Product Owner may decide to cancel the Sprint and start a new one.

4. Differentiate between Incremental and Iterative development in Agile?

INCREMENTAL MODEL ITERATIVE MODEL

1. The Incremental approach is a method of The Iterative Design is a design methodology

software development where the model is based on a cyclic process of prototyping, testing,
designed, implemented and tested analyzing, and refining a product or process.
incrementally (a little more is added each time)
until the product is finished.
2. The Incremental Approach uses a set number The Iterative Approach has no set number of
of steps and development goes from start to steps, rather development is done in cycles.
 finish in a linear path of progression.

3. Incremental development is done in steps from Iterative development is less concerned with
design, implementation, testing/verification, tracking the progress of individual features.
maintenance. These can be broken down Instead, focus is put on creating a working
further into sub-steps but most incremental prototype first and adding features in
models follow that same pattern. development cycles where the Increment
Development steps are done for every cycle.
4. Good design choices are often 'discovered' Instead of investing a lot of time chasing the
during the development process. 'perfect design', the iterative approach is all about
creating something that fit the user's needs.
5. The Waterfall Model is a traditional Agile modelling is a typical iterative approach.
incremental development approach.
6. Incremental means breaking up a project into Iterative means progressively refining some
smaller chunks of functionality and completing given functionality to optimize it based on user
each chunk individually without waiting for the feedback and other inputs.
rest of the functionality to be complete.

5. How is Agile testing different from the traditional waterfall model?

Agile Model Waterfall Model

• Agile method proposes incremental and • Development of the software flows

iterative approach to software design sequentially from start point to end
point.

• The agile process is broken into individual • The design process is not broken into
models that designers work on an individual models

• The customer has early and frequent • The customer can only see the product
opportunities to look at the product and make at the end of the project
decision and changes to the project

• Agile model is considered unstructured • Waterfall model are more secure

compared to the waterfall model because they are so plan oriented

• Small projects can be implemented very • All sorts of project can be estimated
quickly. For large projects, it is difficult to and completed.
estimate the development time.

• Error can be fixed in the middle of the • Only at the end, the whole product is
 project. tested. If the requirement error is
found or any changes have to be made,
the project has to start from the
beginning

• Development process is iterative, and the • The development process is phased,

project is executed in short (2-4) weeks and the phase is much bigger than
iterations. Planning is very less. iteration. Every phase ends with the
detailed description of the next phase.

• Documentation attends less priority than • Documentation is a top priority and

software development can even use for training staff and
upgrade the software with another
team

• Every iteration has its own testing phase. It • Only after the development phase, the
allows implementing regression testing every testing phase is executed because
time new functions or logic are released. separate parts are not fully functional.

• In agile testing when an iteration end, • All features developed are delivered at
shippable features of the product is delivered once after the long implementation
to the customer. New features are usable right phase.
after shipment. It is useful when you have
good contact with customers.

• Testers and developers work together • Testers work separately from

developers

• At the end of every sprint, user acceptance is • User acceptance is performed at the
performed end of the project.

• It requires close communication with • Developer does not involve in

developers and together analyze requirements requirement and planning process.
and planning Usually, time delays between tests and
coding

6. Explain the Agile Software Design Life cycle?

1. Agile methods took over the traditional methods, to overcome the rigidity of the traditional model.
2. Agile follows a dynamic approach to software development.
 3. It is an interactive and team based method that aims to deliver an application in a short span of
time.
4. In agile methodology, tasks are categorised into phases and are 'time-boxed', that is, time frames
are allotted to each task. Each time-boxed phrase is called a sprint. Each sprint has a defined
duration of time, say, a week, few days or month.
A detailed description of how the agile model helps to overcome the shortcomings of the traditional
model.

• Agile is based on empirical process, which provides a control mechanism based on a defined set
of methods. Empirical method is meant for those processes that are not very well defined,
unpredictable or unrepeatable. Agile technique implements control through frequent inspection
and adaptation.

• It is a dynamic approach to software development. That is, this technique is quick in adapting to
changes as requested by the user.

• It has brief iterative life cycles, which reflects periodic changes, and thus integrating small change
cycle to the overall system development process.

• Involves communication with customers consistently, taking their feedback as input, during the
different iterative cycles.

7. Explain the 12 Principles in the Manifesto for Agile Development?

The twelve principles of agile development include:

 1. Customer satisfaction through early and continuous software delivery – Customers are
happier when they receive working software at regular intervals, rather than waiting extended
periods of time between releases.
2. Accommodate changing requirements throughout the development process – The ability to
avoid delays when a requirement or feature request changes.
3. Frequent delivery of working software – Scrum accommodates this principle since the team
operates in software sprints or iterations that ensure regular delivery of working software.
4. Collaboration between the business stakeholders and developers throughout the project –
Better decisions are made when the business and technical team are aligned.
5. Support, trust, and motivate the people involved – Motivated teams are more likely to deliver
their best work than unhappy teams.
6. Enable face-to-face interactions – Communication is more successful when development teams
are co-located.
7. Working software is the primary measure of progress – Delivering functional software to the
customer is the ultimate factor that measures progress.
8. Agile processes to support a consistent development pace – Teams establish a repeatable and
maintainable speed at which they can deliver working software, and they repeat it with each
release.
9. Attention to technical detail and design enhances agility – The right skills and good design
ensures the team can maintain the pace, constantly improve the product, and sustain change.
10. Simplicity – Develop just enough to get the job done for right now.
11. Self-organizing teams encourage great architectures, requirements, and designs – Skilled and
motivated team members who have decision-making power, take ownership, communicate
regularly with other team members, and share ideas that deliver quality products.
12. Regular reflections on how to become more effective – Self-improvement, process
improvement, advancing skills, and techniques help team members work more efficiently.

8. Discuss the Agile documentation practices.

Agile documentation best practices:

1. Only the relevant information: Agile suggests that only the most necessary information should be
documented.Write only the customer documents your customers require. Document your decisions only if
there are alternatives and you need a reminder of what was behind those decisions.There is no need in
extra documents, your time can be spent on something much more useful. Prefer executable specifications
over the theoretical ideas, not grounded in reality. Try to minimize the overlapping. Do not repeat the
same information in a few different papers.

2. Get a tech writer : If you can afford it, get a special person to take care of your documentation. First,
you’ll know that there will always be someone in charge. Second, it will be done properly. Developers are
good in technical part, but they are way too often helpless when it comes to describing it. If you hire
someone with an engineering background, you’ll kill two birds with one stone.

3. Be specific : Keep in mind, that every project has its own requirements and specifics. You cannot
apply the document templates for one project while working with another one. Some fields might not
even exist in a project whilst some important ones are missing.In addition, the customers are different and
what works with one is simply not enough for the other. Let the customers decide on the content and
amount of your documentation. It will save you some extra work and nerves.

4. Keep it all in one place : Technical design documents have to be accessible and transparent. You need
to have them available for anyone who might be in need for them. So as not to have a mess, keep all your
papers in order and in one place.

UNIT-2
1. Discuss the different roles in Scrum?

1. Scrum Master

• A Scrum Master is a facilitator and Servant Leader who encourages and demands self-
organization from the development team.

• A Scrum Master enables close cooperation across all roles and functions, addresses resource
issue and disobedience of scrum practices.
• A Scrum Master protects the team from external and internal distractions.
• A Scrum Master removes impediments so the team can focus on the work at hand and follow
scrum practices.
• A Scrum Master is not typically a manager or lead, but he is an influential leader and coach who
does not do direct command and control.

2. Product Owner

• A Product Owner owns the Product backlog and writes user stories and acceptance criteria.
• A Product Owner is responsible for prioritizing the Product Backlog is prioritized and
decides the release date and the content.
• A Product Owner accepts or rejects product backlog item.
• A Product Owner has the power to cancel the Sprint, if he thinks the Sprint goal is
redundant.
• A Product Owner is the one who is responsible for the Return on Investment (ROI) of the
product.

3. Development team

• The Development Team builds the product that the Product Owner indicates: the application
or website, for example. The Team in Scrum is “cross-functional”
• The Development Team includes all the expertise necessary to deliver the potentially
shippable product each Sprint
 • The Development Team is self-organizing, with a very high degree of autonomy and
accountability.
• The Development Team decides how many items to build in a Sprint, and how best to
accomplish that goal.
• The Development Team is a cross functional, small and self-organizing team which owns the
collective responsibility of developing, testing and releasing the Product increment.
• The Development Team may not appoint any team lead since decisions are taken
collectively by the team.

2. What is the difference between Sprint Planning Meeting and Sprint Retrospective Meeting?

Sprint Review
The sprint review meeting is intentionally kept very informal, typically with rules forbidding the use of
PowerPoint slides and allowing no more than two hours of preparation time for the meeting. A sprint
review meeting should not become a distraction or significant detour for the team; rather, it should be a
natural result of the sprint.
Participants in the sprint review typically include the Product Owner, the Scrum team, the ScrumMaster,
management, customers, and engineers from other projects.
During the sprint review the project is assessed against the sprint goal determined during the Sprint
planning meeting. Ideally the team has completed each product backlog item brought into the sprint, but it
is more important that they achieve the overall goal of the sprint.

Spirit Retrospective
The sprint retrospective meeting is time boxed to 3 hours. It is attended only by the team, the scrum
master and the product owner. The product owner is optional. Start the meeting by having all team
members answer two questions;
1) What went well during the sprint?
2) What could be improved in the next sprint?

a. The scrum master writes down the team’s answers in summary form.
b. The team prioritizes in which order it wants to talk about the potential improvements.
c. The scrum master is not in this meeting to provide answers, but to facilitate the team’s search for better
ways for the scrum process to work for it.

Actionable items that can be added to the next sprint should be devised as high-priority non functional
product backlog. Retrospectives that don’t result in change are sterile and frustrating.

3. How (parameters) to choose the number of resources required to your scrum team?
4. Differentiate between Scrum and Kanban.
Scrum Kanban

• In scrum technique, test must be broken • No particular item size is prescribed

down so that they can be completed within
one sprint

• Prescribes a prioritized product backlog • Prioritization is optional

• Scrum team commits to a particular amount • Commitment is optional

of work for the iteration

• Burndown chart is prescribed • No particular item size is prescribed

• Between each sprint, a scrum board is reset • A Kanban board is persistent. It limits
the number of items in workflow state

• It cannot add items to ongoing iteration • It can add items whenever capacity is
available

• WIP limited indirectly • WIP limited directly

• Timeboxed iterations prescribed • Timeboxed iterations optional

5.Explain eXtreme Programming (XP) and Phases of eXtreme programming:

eXtreme Programming (XP)

Extreme Programming technique is very helpful when there is constantly changing demands or
requirements from the customers or when they are not sure about the functionality of the system. It
advocates frequent "releases" of the product in short development cycles, which inherently improves the
productivity of the system and also introduces a checkpoint where any customer requirements can be
easily implemented. The XP develops software keeping customer in the target.
Business requirements are gathered in terms of stories. All those stories are stored in a place called the
parking lot.

In this type of methodology, releases are based on the shorter cycles called Iterations with span of 14 days
time period. Each iteration includes phases like coding, unit testing and system testing where at each
phase some minor or major functionality will be built in the application.

Phases of eXtreme programming:

There are 6 phases available in Agile XP method, and those are explained as follows:

Planning

• Identification of stakeholders and sponsors

• Infrastructure Requirements
• Security related information and gathering
• Service Level Agreements and its conditions

Analysis

• Capturing of Stories in Parking lot

• Prioritize stories in Parking lot
• Scrubbing of stories for estimation
• Define Iteration SPAN(Time)
• Resource planning for both Development and QA teams

Design

• Break down of tasks

• Test Scenario preparation for each task
• Regression Automation Framework

Execution
 • Coding
• Unit Testing
• Execution of Manual test scenarios
• Defect Report generation
• Conversion of Manual to Automation regression test cases
• Mid Iteration review
• End of Iteration review

Wrapping

• Small Releases
• Regression Testing
• Demos and reviews
• Develop new stories based on the need
• Process Improvements based on end of iteration review comments

Closure

• Pilot Launch
• Training
• Production Launch
• SLA Guarantee assurance
• Review SOA strategy
• Production Supports

6. Explain in brief Crystal Methodologies?

Crystal method is an agile software development approach that focuses primarily on people and their
interactions when working on a project rather than on processes and tools. Alistair believed that the
people’s skills and talents as well as the way they communicate has the biggest impact on the outcome of
the project.

Crystal Method is based on two fundamental assumptions:

• Teams can streamline their processes as their work and become a more optimised team
• Projects are unique and dynamic and require specific methods

History of the Crystal Method

Alistair Cockburn, credited as one of the original popularizers of agile, developed the Crystal method for
IBM in 1991. He decided to focus not on developing specific step-by-step development strategies that
would work across the board for teams involved in any project, but instead to develop guidelines for team
collaboration and communication. The traits of Cockburn’s Crystal method were therefore all based
around the team itself:
 • Human-powered (meaning the project should be flexible and tailored to the needs and the
preferred work modalities of people involved)
• Adaptive (meaning the approach uses no fixed tools but can be altered to meet the team’s specific
needs)
• Ultra-light (meaning this methodology does not require much documentation or reporting)

Strengths and Weakness of Crystal

Crystal’s strengths include:

• Allows teams to work the way they deem most effective

• Facilitates direct team communication, transparency and accountability
• The adaptive approach lets teams respond well to changing requirements

Crystal’s weaknesses include:

• Lack of pre-defined plans can lead to scope creep

• Lack of documentation can lead to confusion

Crystal method family members

One of the things that Cockburn discovered is that the project properties changed depending on the
number of the people involved in the project and the level of criticality of the project at hand.While the
smaller team can handle and build the product without a lot of status reporting and paperwork, the
number of “communication artifacts” rises with bigger teams who are working on large-scale projects.

In other words, the more people you have on the team, the more critical the project is and the more
complex the approach needs to be.To make this categorization easy to understand, Cockburn named the
methodology Crystal and categorized it along two dimensions size and criticality that matching those of
minerals - color and hardness.Essentially, Cockburn developed these families to point out that each
project may require a particular set of policies, practices, and processes in order to meet project’s unique
characteristics. Cockburn tried to explain this by calling Crystal “a set of samples that you adjust to your
circumstances”.

Which approach will be most suitable for your projects depends on three dimensions:

• Team size
• Criticality
• What the priority of the project is

Generally, they are characterized by colors, according to the number of people involved in the project:
• Clear - for teams of 8 or fewer people
• Yellow - for teams of 10-20 people
• Orange - for teams of 20-50 people
• Red - for teams of 50-100 people

Crystal methods focus on:-

1. People involved
2. Interaction between the teams
3. Community
4. Skills of people involved
5. Their Talents
6. Communication between all the teams

Crystal method characteristics

1. Human-powered

This means that people involved in the project are vital and that the processes should be adapted to meet
people’s needs. It also emphasizes that people are capable of organizing themselves and that they can
become more organized and competent as the processes develop.

2. Adaptive

Crystal is a stretch to fit methodology meaning that processes and tools are not fixed, but have to be
adjusted to meet the requirements of the team and the project at hand.

3. Ultra-light

Crystal doesn’t involve too much documentation, management and reporting. It keeps things light by
focusing on transparent workflow between the team and the client and by practicing open communication
between team members.

7 properties of Crystal method

• Frequent delivery - it allows you to frequently deliver working, tested code to real users. In this way,
you don’t have to face the fact that you have invested your energy and time into the product that nobody
wants to buy.
• Reflective improvement - no matter how bad or good the product is, there are always areas where the
product can be improved. Also, there are always new techniques and methods your team can implement
to improve their future practices
• Osmotic communication - with the team who works co-located, information flows around the team. That
allows them to pick up valuable information without even being directly involved in the discussion of the
certain matter.This gradual absorption of ideas is called osmotic communication. Cockburn believes that
this kind of work atmosphere can operate with very little structure.
• Personal Safety - the only way to build a healthy working atmosphere and a true team culture is by
practicing an open and honest communication. Team members should be able to speak without the fear,
no matter whether they are presenting a new idea or talking about a potential problem.
• Focus - each team member knows exactly what to work on which enables them to focus their attention
and avoid switching from one task to another. Also, this boosts team communication and helps the team
prioritize and work towards the same goals.
• Easy access to expert users - Crystal enables your team to maintain communication and get regular
feedback from real users.
• A technical environment with automated tests, configuration management, and frequent
integration - very specific tools for software teams where the emphasis is on continuous integration so
that the errors could be caught within minutes.

Why is Crystal method useful ?

The fact that Crystal uses a focus on people and communication as its organizing principle I what
distinguishes it from other software development methods.

Unlike other agile methodologies, Crystal focuses on adjusting the techniques used in a project with the
aim to strengthen the process of team communication. Besides that, Crystal allows:

• Continuous integration
• Flexible and configurable processes
• Active user involvement

Keep in mind that Crystal is primarily created to remind you how to stay centered and focused on your
work during the project development.

7. Discuss Dynamic Software Development Method (DSDM)?

Dynamic Systems Development Method (DSDM)

The Dynamic Systems Development Method (DSDM) is an agile framework that addresses the entire
project lifecycle and its impact on the business. Like the broader agile philosophy, DSDM is an iterative
approach to software development, and this framework explicitly states “any project must be aligned to
clearly defined strategic goals and focus upon early deliver of real benefits to the business.” The
framework is built on four principles: feasibility and business study, functional model and prototype
iteration, design and build iteration, and implementation.
History of the Dynamic Systems Development Method (DSDM)

DSDM was invented in 1994, when project managers using another agile framework, Rapid Application
Development (RAD), determined that the new iterative approach to software development needed more
governance and stricter guidelines.

DSDM Lifecycle

1. Feasibility Study:
It establishes the essential business necessities and constraints related to the applying to be designed then
assesses whether or not the application could be a viable candidate for the DSDM method.

2. Business Study:
It establishes the use and knowledge necessities that may permit the applying to supply business value;
additionally, it is the essential application design and identifies the maintainability necessities for the
applying.

3. Functional Model Iteration:

It produces a collection of progressive prototypes that demonstrate practicality for the client.
(Note: All DSDM prototypes are supposed to evolve into the deliverable application.) The intent
throughout this unvarying cycle is to collect further necessities by eliciting feedback from users as they
exercise the paradigm.

4. Design and Build Iteration:

It revisits prototypes designed throughout useful model iteration to make sure that everyone has been
designed during a manner that may alter it to supply operational business price for finish users. In some
cases, useful model iteration and style and build iteration occur at the same time.

5. Implementation:
It places the newest code increment (an “operationalized” prototype) into the operational surroundings. It
ought to be noted that:

(a) the increment might not 100% complete or,

(b) changes are also requested because the increment is placed into place. In either case, DSDM
development work continues by returning to the useful model iteration activity.

Below diagram describe the DSDM life cycle:

DSDM is often combined with XP to supply a mixed approach that defines a solid method model (the
DSDM life cycle) with the barmy and bolt practices (XP) that are needed to create code increments.
additionally, the ASD ideas of collaboration and self-organizing groups are often tailored to a combined
method model.

Strengths and Weakness of DSDM

DSDM’s strengths include:

• Basic product functionality can be delivered rapidly

• Developers have easy access to end-users
• Projects are reliably completed on time

DSDM’s weaknesses include:

• Can represent a dramatic and disruptive change in company culture

• Costly to implement
 • Not ideal for small organizations
8. Discuss the Agile model for improving The Software (System) Development Life Cycle.
From unit 1 question 1 and 6 (about agile model , advantages , disadvantages).

9. Explain in brief Lean Software Development.

Lean Software Development

Lean Software Development (LSD) is an agile framework based on optimizing development time and
resources, eliminating waste, and ultimately delivering only what the product needs. The Lean approach
is also often referred to as the Minimum Viable Product (MVP) strategy, in which a team releases a bare-
minimum version of its product to the market, learns from users what they like, don’t like and want to be
added, and then iterates based on this feedback.

History of Lean Software Development (LSD)

LSD actually borrows its philosophy from the manufacturing industry, which originated the lean
development process as a way to optimize production and assembly lines to minimize waste and
maximize customer value. In fact, it was originally called the Toyota Production System, because
automaker Toyota invented this approach in the middle of the twentieth century as a way to streamline its
production of cars and eliminate wasted time and resources. (Any action that did not impact the
functionality of car being built and delivered was considered a waste under this system, and therefore
removed from the process.)

Eventually, other manufacturing organizations across many industries began using this system, and the
name later changed to Lean. The methodology was first applied to the creation of software in 2003 with
the publication of the now-famous book Lean Software Development.

Seven Principles of Lean Software Development

1. Eliminate Waste

Waste is anything that does not contribute value to the final product and interferes with the aim of
delivering value to customers. This includes, but is not limited to, inefficient processes or project churn,
crossing boundaries/departments, and features that won’t be used. Eliminating waste is the guiding
principle in lean software development.

2. Build Quality In
Building quality into a product means preventing defects by seeking them out within your verification
process rather than using post-implementation integration and testing to detect them after the fact. Not
building legacy code that lacks automated unit and acceptance tests is crucial to continuous integration
and nested synchronization.

3. Create Knowledge
While planning is useful, it is learning that is essential. Encourage developers to build and record the
knowledge necessary to develop a project. This should comprehensively include all requirements,
architecture, and technologies, which are seldom known or understood completely at project startup.
Creating knowledge and recording it over the course of the project ensures that the final product is in line
with customer expectations.

4. Defer Commitment
Reject the idea that projects should begin with a set plan for the specification. Planning is not the same as
committing. Deferring commitment is positive procrastination as more information is available at the
latest possible moment before an irreversible decision needs to be made.

5. Deliver Fast
Delivering fast puts the product in front of the customer quickly so they can provide feedback, allowing
companies to take a more experimental approach to product/feature development. Fast delivery is
accomplished using short iterations that produce software in small increments by focusing on a limited
number of the highest priority requirements.

6. Respect People
Respecting people means giving the development team’s most important resource — its members —
freedom to find the best way to accomplish a task, recognizing their efforts, and standing by them when
those efforts are unsuccessful. Engaged team members are a company’s most sustainable competitive
advantage.

7. Optimize the Whole

Optimizing the whole development process generates better results than optimizing local processes in
isolation, which is usually done at the expense of other local processes. Brilliant products are often the
result of a unique combination of technology and opportunity which is afforded by a lean software
development process.

Strengths and Weakness of Lean Software Development

LSD’s strengths include:

• Streamlined approach allows more functionality to be delivered in less time

• Eliminates unnecessary activity, and as a result can reduce costs
• Empowers the development team to make decisions, which can also boost morale

LSD’s weaknesses include:

• Heavily depends on the team involved, making it not as scalable as other frameworks
• Depends on strong documentation, and failure to do so can result in development mistakes
Should You Use Lean Software Development ?

Many organizations have found the LSD methodology to be an excellent approach to software
development because of its streamlining of the process and forcing the team to ruthlessly cut away any
activity that doesn’t directly affect the final product. But an organization must have an outstanding
development team, and trust that team implicitly, for this approach to be successful.

10. What is Sashimi? Explain the phases of Scrum.

Sashimi is a Japanese word that means a pierced body. Basically, it is a Japanese dish that consists of
fresh meat or fish, sliced into thin pieces. Each piece is similar in taste when compared with the other
pieces.
Sashimi in scrum methodology means every phase of the software development cycle in a sprint which
includes requirement analysis, planning & design, development, testing, documentation is complete or
not and the product is ready to be displayed etc.

The sashimi software process is quite similar to the waterfall, except that the phases overlap to show that
requirements can't be completed until architecture is at least partially explored, and architecture can't be
completed until module design is at least partially explored, and so on.

The sashimi process is most appropriate for medium-sized projects for which the communication between
phases can be handled in an improvised manner. For larger projects, high-risk projects, or projects in
which few of the developers are experienced, a spiral approach may be better.

Phases in Scrum

1. Initiate

1. Create Project Vision

2. Identify Scrum Master and Stakeholder(s)
3. Form Scrum Team
4. Develop Epic(s)
5. Create Prioritized Product Backlog
6. Conduct Release Planning
2. Plan and Estimate

7. Create User Stories

8. Approve, Estimate, and Commit User Stories
9. Create Tasks
10. Estimate Tasks
11. Create Sprint Backlog

3. Implement

12. Create Deliverables

13. Conduct Daily Standup
14. Groom Prioritized Product Backlog

4. Review and Retrospect

15. Convene Scrum of Scrums

16. Demonstrate and Validate Sprint
17. Retrospect Sprint

5. Release

18. Ship Deliverables

19. Retrospect Project

UNIT-3
1. What are objectives of knowledge management?

Knowledge management is the process of gathering, developing, sharing, and the efficient handling
of information within an organization. Knowledge management is often associated with information
technology but it is an integral part of many organizations.
In one-way or another, to improve efficiency and increase productivity, many use knowledge
management. The purpose of knowledge management is to ensure that the right information is available
to the right people.
Knowledge management, also referred to as KM, ensures that organizations can learn and retrieve their
knowledge assets when they are needed. Organizations use KM to remain beneficial and maintain a
competitive advantage.

Being able to access information whenever it is needed, keeps employees informed, and can encourage
innovation. Maintaining a knowledge base can give you access to data that may be useful for identifying
new product opportunities.
KM is a learning enabler for most and is often part of an organization’s overall strategy.

Knowledge management is the systematic management of an organization's knowledge assets for the
purpose of creating value and meeting tactical & strategic requirements; it consists of the initiatives,
processes, strategies, and systems that sustain and enhance the storage, assessment, sharing, refinement,
and creation of knowledge.

Objectives of knowledge management

• Organizational Memory Management: the necessary conditions to identify all the knowledge the
company has accumulated and where it stores it.
• Company organizes data logically so that it can transform it into useful information to use
for knowledge development.
• Make information flow properly and be accessible to all, with the help of technology, allowing
your business to find results.
• Promote the generation of new knowledge from the dissemination of this information, which leads
to the achievement of competitive advantages.
• Increase organizational competitiveness by using this knowledge in a strategic way that unfolds in
tactical objectives and operational actions.

2. Describe briefly knowledge management infrastructure and its components.

Knowledge Management Infrastructure

1. Organizational Culture

2. Organizational Structure

3. Communities of Practice

4. Information Technology Infrastructure

5. Common Knowledge

Organizational Culture

• Organizational culture reflects the norms and beliefs that guide the behavior of the organization’s
members
 • Attributes of an enabling organizational culture include understanding of the value of KM
practices, management support for KM at all levels, incentives that reward knowledge sharing,
and encouragement of interaction for the creation and sharing of knowledge

Organizational Structure

• Hierarchical structure of the organization affects the people with whom individuals frequently
interact, and to or from whom they are consequently likely to transfer knowledge
• Organizational structures can facilitate KM through communities of practice
• Organization structures can facilitate KM through specialized structures and roles that specifically
support KM.

Information Technology Infrastructure „

• The IT infrastructure includes data processing, storage, and communication technologies and
systems
• One way of systematically viewing the IT infrastructure is to consider the capabilities it provides
in four important aspects:
• Reach
• Depth
• Richness
• Aggregation

Common Knowledge

• Common knowledge also refers to the organization’s cumulative experiences in comprehending a

category of knowledge and activities, and the organizing principles that support communication
and coordination
• Common knowledge helps enhance the value of an individual expert’s knowledge by integrating it
with the knowledge of others

Physical Environment

• Physical environment includes the design of buildings and the separation between them; the
location, size, and type of offices; the type, number, and nature of meeting rooms
• A 1998 study found that most employees thought they gained most of their knowledge related to
work from informal conversations around water coolers or over meals instead of formal training
or manuals
3. Distinguish between KM foundation and KM solutions.
KM Solutions
The ways in which specific aspects of KM (discovery , capture , sharing and application of
knowledge)can be accomplished . KM solutions include KM systems and KM processes.
1. Knowledge Management Systems
• Knowledge management systems are the integration of technologies and mechanisms that are
developed to support KM processes
• KM systems utilize a variety of KM mechanisms and technologies to support the KM processes
1. Knowledge Management Discovery Systems
2. Knowledge Management Capture Systems
3. Knowledge Management Sharing Systems
4. Knowledge Application Systems
KM Fountations
The broad organizational aspects that support KM in the short and long term. They include KM
Infrastructures , KM mechanisms and KM Technologies.

Knowledge Management Mechanisms

• KM mechanisms are organizational or structural means used to promote KM
• Examples of KM mechanisms include learning by doing, on-the-job training, learning by
observation, and face-to-face meetings
• Long term KM mechanisms: cooperative projects, hiring a chief K officer, employee rotation,
standards, organisational policies.
 • Mechanisms facilitating direction include traditional hierarchical relationships in organizations,
help desks, and support centers .Mechanisms supporting routines include organizational policies,
work practices, and standards .

Knowledge Management Technologies

• Technologies that support KM include artificial intelligence (AI) technologies encompassing

those used for knowledge acquisition and case-based reasoning systems, electronic discussion
groups, computerbased simulations databases, decision support systems, management IS,
information repositories encompassing best practices databases,etc .
• Technologies supporting direction include experts’ knowledge embedded in expert systems and
decision support systems, as well as troubleshooting systems based on the use of technologies like
case-based reasoning.
• Technologies that facilitate routines are expert systems, enterprise resource planning systems, and
traditional management information systems

4. Discuss in brief about Institutional Knowledge Evolution Cycle.

The Institutional knowledge evolution cycle

Knowledge Development

Knowledge is developed through learning, innovation, creativity, and importation from outside.

Knowledge Acquisition

Knowledge is captured and retained for use and further treatment

Knowledge Refinement

Knowledge is organized, transformed, or included in written material, knowledge bases, and so on

to make it available and useful.

Knowledge Distribution and Deployment

Knowledge is distributed to Points-of-Action (PoAs) through education, training programs,

automated knowledge-based systems, expert networks.

Knowledge Leveraging

Knowledge is applied or otherwise leveraged. By using (applying) knowledge, it becomes the basis
for further learning and innovation.
5. Briefly explain the four kinds of classification for knowledge management systems based on the
process supported. How each KM system can facilitate knowledge management?
OR
What are the four basic knowledge management processes and their subprocesses? Describe briefly
these processes.
6. Give an example of one knowledge management mechanism that could be used to facilitate each
of the four knowledge management processes.
Knowledge Management Mechanisms are organizational or structural means used to promote
knowledge management. They enable knowledge management systems, and they are themselves
supported by the knowledge management infrastructure. Knowledge Management Mechanisms may (or
may not) utilize technology, but they do involve some kind of organizational arrangement or social or
structural means of facilitating knowledge management.

Examples of Knowledge Management Mechanisms include:

• learning by doing,
• on-the-job training,
• learning by observation, and
• face-to-face meetings.

More long-term knowledge management mechanisms include the hiring of a Chief Knowledge Officer,
cooperative projects across departments, traditional hierarchical relationships, organisational policies,
standards, initiation process for new employees, and employee rotation across departments.
7. Write notes on (i) Role of Story-Cards (ii) Story-Card Maturity Model (SMM).
(i) Role of Story-Cards
(ii) Story-Card Maturity Model (SMM).

The Story card Maturity Model (SMM), requirements improvement framework offers many advantages.
The SMM includes an assessment method that guides the user to understand current story cards based
requirements engineering process. The rationale for building the SMM is as:

• To define a generic process model for Story cards based requirements engineering process
improvement that is suitable for RE at agile software development environments.

• To design and implement an automated tool that support to apply the proposed model in order to help
facilitate process improvement.

• Identify and define story cards based requirements engineering practices

• Recognise story cards based requirement engineering practices problems

• Access and agree story cards based RE practices improvement priorities

• Relate story cards based RE practices problem to RE practices improvement goals

• Contains guidelines for many story cards related requirements engineering activities
• Is designed to be tailored to focus on specific process areas

• Goal focused

• Maturity structure to help with process prioritisation.

8. Explain in brief about Earl’s Schools of KM .

Earl’s Seven Schools:

Earl after a five year study on strategies of knowledge management categorised knowledge management
into seven types which are called as Earl’s Seven Schools. These schools are inturn put into three groups.
Now we will see each of these groups and the types that come under these groups as categorised by Earl.

Technocratic:
Earl termed this group technocratic as the schools that come under this group rely on Information
Technology to help the knowledge workers. And a total of three schools come under this group:
Systems; Cartographic; and Engineering.

1. Systems: According to the Systems school, we have to store the knowledge of an expert which can in
turn be accessed by other experts or qualified individuals who understand that stored knowledge. This is
because it saves time and resources for everyone. When a problem arises, the staff instead of searching
for the possible solution and wasting huge amount of time and resources can access the stored knowledge
in which the solutions of many problems has been stored by the experts or by individuals through
experience and assist their customers who have faced a similar problem and assist them (customers) very
quickly without wasting much time and this inturn leads to customer satisfaction.

2. Cartographic: The main aim of this school is to be sure that an expert is always available for the staff
when required. When a member of staff is unable to find a possible solution in the database an expert
should be readily available in order to give advice on how that problem can be solved.The main
advantage of this school is that making an expert available is always helpful in case an individual looses
his track in solving an issue.

3. Engineering: This school has two sub categories’ on which the attention has been drawn which are,
“more knowledge is present in management than that exists in business process” and “a way to enhance a
business process is to provide the staff with knowledge that is suitable to their work”.

Economic: This is the second group classified by Earl which consists of only one school, which is the

4. Commercial School: This school states that an organisation must concentrate on increasing the
revenue by protecting an organisation’s knowledge and also exploiting it incase. The main aim as stated
by this school is to increase the revenue of the organisation in what ever way possible and useful for the
organisation in simple terms.

Behavioral : Earl termed this group as Behavioral as according to him technology is not the only force
that drives an organisation but also KM.

5. Organisational School: This school supports the idea of sharing the knowledge when one is unable to
find a straight possible solution to a problem. According to a research done by Xerox, much of the
knowledge exists in the minds of the employees than in the database that is available for access with the
solution to certain problems

6. Spatial School: This school states that space should not be a problem for workers who want to share
knowledge i.e., restricting the staff to meet in only one room or in only one building.

7. Strategic School: According to this school, knowledge should be considered the bigger picture after
achieving success.

UNIT-4

1. Discuss in brief about RE Using Agile?

2. Explain how to Manage Unstable Requirements?
3. Explain the process of Requirements Elicitation and Agile Requirements Abstraction Model ?
4. Discuss about Requirements Management in Agile Environment.
5. Explain in detail about Agile Requirements Prioritization.
6. Discuss about Agile Requirements Modeling and Generation.

7. Explain how Concurrency in Agile Requirements Generation is carried out.

8. How is agile requirement elicitation is different than traditional requirement elicitation.

In traditional requirements elicitation methods it is difficult to make any changes in the latter phases and
changing requirements at a later phase have a major impact in terms of budget and customer satisfaction.
It can be expensive to fix the errors at the later stages as more cost and time will be involved resulting in
the delay of the project. In traditional models like the Waterfall model, Spiral model, Incremental Build
Model, V-Model in all of them requirements are applied at the initial stages only because these models
are not much flexible to acquire the changes in requirements at later stages as they are based on the
sequential flow of activities.

To overcome these limitations agile methodology came into existence which is incremental and iterative
approach, flexible in acquiring the changes even late in the development cycle. The agile methods
overcame the limitations of the traditional models like Waterfall model, Spiral model in the way of
accepting the changes in the requirements at later stages of development because they are based on
“incremental” and “iterative “approach (Lucassen et al., 2016). Every phase of the software development
life cycle is divided into iterations and each iteration is revisited again and again to steer the process in
another direction if some changes are to be done. The approach of this “inspectand-adapt” greatly
decreases the development cost and time to the organization (Lesmana et al., 2016). Our literature review
identified few interesting work .

UNIT-5

1. What is Agile Testing and how does it differ from the traditional waterfall or the V-model?
2. What are the main differences between Quality Assurance, Quality Control, and Software
Testing?
3. What are the differences between a Test Plan and a Use Case?

4. What is the difference between functional and nonfunctional testing?

Parameters Functional Non-functional testing

Execution It is performed before non- It is performed after the

functional testing. functional testing.

Focus area It is based on customer's It focusses on customer's

requirements. expectation.

Requirement It is easy to define functional It is difficult to define the

requirements. requirements for non-functional
testing.

Usage Helps to validate the behavior of Helps to validate the

the application. performance of the application.

Objective Carried out to validate software It is done to validate the

actions. performance of the software.

Requirements Functional testing is carried out This kind of testing is carried out
using the functional specification. by performance specifications

Manual testing Functional testing is easy to It's very hard to perform non-
execute by manual testing. functional testing manually.
Parameters Functional Non-functional testing

Functionality It describes what the product It describes how the product

does. works.

Example Test Check login functionality. The dashboard should load in 2

Case seconds.

Testing Types Examples of Functional Testing Examples of Non-functional

Types Testing Types

• Unit testing • Performance Testing

• Smoke testing • Volume Testing
• User Acceptance • Scalability
• Integration Testing • Usability Testing
• Regression testing • Load Testing
• Localization • Stress Testing
• Globalization • Compliance Testing
• Interoperability • Portability Testing
• Disaster Recover Testing

5. Explain what is Bug triage?

Defect Triage is also known as Bug Triage. The term Triage is used in Software Testing to define the
severity and priority of defects. Defect triage is a process or mechanism where each defect is prioritized
based on its severity, risk, reoccurrence etc.

Triage is a medical word. Triage is the process of quickly examining patients who are taken to a hospital
in order to decide which ones are the most seriously ill and must be treated first. Patients will be
categorized based on the severity of the illness and then the doctors treat the patients who are seriously ill
in the priority basis. Patients who have non-critical diseases are considered as low priority patients and
were treated after the patients who are seriously ill.

In Software Testing, we use the word Triage with the combination of Bug/Defect like Bug Triage or
Defect Triage. Here we apply the same concept to bugs found during testing phase. It is to decide the
priority of the bugs based on their severity, risk and frequency of re occurrence etc.
6. Explain what is Test Metric in software testing and what information does it contains?
The Software testing metrics provide quantitative approach to measure the quality and effectiveness of
the software development and testing process. It provides the visibility into the readiness of the product
and gives clear measurement of its quality and completeness. Moreover, with the assistance of testing
metrics the team of testers can keep a track of the software quality at every stage in the software
development cycle. One can also get information to control and reduce the number of errors through
testing metrics. Some examples of test metrics are:

• How many defects are existing within the module?

• What is the Test Coverage %?

• How many test cases were executed per person?

Importance of Metrics in Software Testing:

• Without measurement, it is impossible to tell whether the process implemented in the software
application is improving or not.

• With the help of metrics one can easily take decisions about the activities that will be executed in
the next phase of software development or testing, such as estimating the cost and schedule of the
future projects.

• Metrics helps in understanding the type of improvements required in a project and assist with
decisions regarding process or technology changes.

• One can track the improvements in the software.

Phases of Test Metrics

Known as Test Metrics Life Cycle, there are four phases of test metrics. During these phases different
factors related to the software production are measured for the development process as well as reported to
the stakeholders. These phases are:

• Analysis Phase -In this phase the metrics, which have been generated are identified, which are
then defined by the tester.

• Communicate Phase- Here, the need of metrics is explained to the stakeholders. Moreover, the
testing team is educated about the data points required for generating Metrics.

• Evaluation Phase- The data used for generating the Metrics is captured and verified. It is based
on these captured data that the metrics are calculated.

• Reporting Phase- A metrics report is developed with all the required information, which includes
graphs and pie charts and is distributed to stakeholder. After the evaluation of this report, a
feedback is provided by stakeholders for any intended improvements.
7. What are the leading testing techniques for QA? And what is their purpose?

Quality Assurance (QA) is defined as an activity to ensure that an organization is providing the best
possible product or service to customers. QA focuses on improving the processes to deliver Quality
Products to the customer. An organization has to ensure, that processes are efficient and effective as per
the quality standards defined for software products. Quality Assurance is popularly known as QA Testing

Quality assurance has a defined cycle called PDCA cycle or Deming cycle. The phases of this cycle are:

• Plan
• Do
• Check
• Act
These above steps are repeated to ensure that processes followed in the organization are evaluated and
improved on a periodic basis. Let's look into the above steps in detail -

• Plan - Organization should plan and establish the process related objectives and determine the
processes that are required to deliver a high-Quality end product.
• Do - Development and testing of Processes and also "do" changes in the processes
• Check - Monitoring of processes, modify the processes, and check whether it meets the
predetermined objectives
• Act - Implement actions that are necessary to achieve improvements in the processes

An organization must use Quality Assurance to ensure that the product is designed and implemented with
correct procedures. This helps reduce problems and errors, in the final product.

Quality Assurance Tools & Techniques

There are many tools and techniques that form the basis of the key quality assurance principles. Some of
these include...
• Cost-Benefit Analysis
• Cost of Quality (COQ)
• Control Charts
• Benchmarking
• Design of Experiments (DOE)
• Statistical Sampling
• Flow Charting
• Quality Management Methodologies (i.e. Six Sigma, CMMI, etc)
• Cause and Effect Diagrams (i.e. Fishbone Diagram)
• Histogram
• Pareto Chart
• Run Chart
• Scatter Diagram
• Inspection

8. What causes a Software to have bugs?

A Software Bug is a failure or flaw in a program that produces undesired or incorrect results. It’s an error
that prevents the application from functioning as it should. There are many reasons for Software Bugs.
The most common reason is human mistakes in software design and coding. Once you know the causes
for Software Defects it will be easier for you to take corrective actions to minimize these defects.
Reasons For Software Bugs

1) Miscommunication or No Communication
The success of any software application depends on communication between stakeholders, development
and testing teams. Unclear requirements and misinterpretation of requirements are two major factors
causing defects in software. Also, defects are introduced in the development stage if exact requirements
are not communicated properly to development teams.

2) Software Complexity
The complexity of current software applications can be difficult for anyone without experience in
modern-day software development.The use of object-oriented techniques can complicate instead of
simplifying a project unless it is well-engineered.

3) Programming Errors
Programmers, like anyone else, can make programming mistakes. Not all developers are domain experts.
Inexperienced programmers or programmers without proper domain knowledge can introduce simple
mistakes while coding.
Lack of simple coding practices, unit testing, debugging are some of the common reasons why these
issues get introduced at the development stage.

4) Changing Requirements
The customer may not understand the effects of changes or may understand and request them anyway –
redesign, rescheduling of engineers, effects on other projects, work already completed that may have to
be redone or thrown out, hardware requirements that may be affected, etc.If there are many minor
changes or any major changes, known and unknown dependencies among parts of the project are likely to
interact and cause problems, and the complexity of keeping track of changes may result in errors.

5) Time Pressures
Scheduling of software projects is difficult at best, often requiring a lot of guesswork. When deadlines
loom and the crunch comes, mistakes will be made.

6) Egotistical or Overconfident People

People prefer to say things like:
• ‘no problem’
• ‘piece of cake’
• ‘I can whip that out in a few hours’
• ‘it should be easy to update that old code’

7) Poorly Documented Code

It’s tough to maintain and modify the code that is badly written or poorly documented; the result
is Software Bugs.Any new programmer starting to work on this code may get confused due to the
complexity of the project and the poorly documented code.

8) Software Development Tools

Visual tools, class libraries, compilers, scripting tools, etc. often introduce their own bugs or are poorly
documented, resulting in added bugs.

9) Obsolete Automation Scripts

Writing automation scripts takes a lot of time especially for complex scenarios. If automation teams
record/write any test script but forget to update it over the period of time that test could become obsolete.
If the automation test is not validating the results properly it won’t be able to catch the defects.

10) Lack of Skilled Testers

Having skilled testers with domain knowledge is extremely important for the success of any project. But
appointing all experienced testers is not possible for all companies.
Domain knowledge and the tester’s ability to find defects can produce high-quality software.
Compromise on any of this can result in buggy software.

9. What approach do you follow to measure the testing efforts in a project?

Test efforts are not based on any definitive timeframe. The efforts continue until some pre-decided
timeline is set, irrespective of the completion of testing.
This is mostly due to the fact that conventionally, test effort estimation is a part of the development
estimation. Only in the case of estimation techniques that use WBS, such as Wideband Delphi, Three-
point Estimation, PERT, and WBS, you can obtain the values for the estimates of the testing activities.
If you have obtained the estimates as Function Points (FP), then as per Caper Jones,
Number of Test Cases = (Number of Function Points) × 1.2
Once you have the number of test cases, you can take productivity data from organizational database and
arrive at the effort required for testing.

Testing Estimation Techniques

The following testing estimation techniques are proven to be accurate and are widely used −

• PERT software testing estimation technique

• UCP Method
• WBS
• Wideband Delphi technique
• Function point/Testing point analysis
• Percentage distribution
• Experience-based testing estimation technique

PERT Software Testing Estimation Technique

PERT software testing estimation technique is based on statistical methods in which each testing task is
broken down into sub-tasks and then three types of estimation are done on each sub-tasks.
The formula used by this technique is −
Test Estimate = (O + (4 × M) + E)/6
Where,
O = Optimistic estimate (best case scenario in which nothing goes wrong and all conditions are optimal).
M = Most likely estimate (most likely duration and there may be some problem but most of the things
will go right).
L = Pessimistic estimate (worst case scenario where everything goes wrong).
Standard Deviation for the technique is calculated as −
Standard Deviation (SD) = (E − O)/6

Use-Case Point Method

UCP Method is based on the use cases where we calculate the unadjusted actor weights and unadjusted
use case weights to determine the software testing estimation.
Use-case is a document which specifies different users, systems or other stakeholders interacting with
the concerned application. They are named as “Actors”. The interactions accomplish some defined goals
protecting the interest of all stakeholders through different behavior or flow termed as scenarios.
Step 1 − Count the no. of actors. Actors include positive, negative and exceptional.
Step 2 − Calculate unadjusted actor weights as
Unadjusted Actor Weights = Total no. of Actors
Step 3 − Count the number of use-cases.
Step 4 − Calculate unadjusted use-case weights as
Unadjusted Use-Case Weights = Total no. of Use-Cases
Step 5 − Calculate unadjusted use-case points as
Unadjusted Use-Case Points = (Unadjusted Actor Weights + Unadjusted Use-Case Weights)
Step 6 − Determine the technical/environmental factor (TEF). If unavailable, take it as 0.50.
Step 7 − Calculate adjusted use-case point as
Adjusted Use-Case Point = Unadjusted Use-Case Points × [0.65 + (0.01 × TEF]
Step 8 − Calculate total effort as
Total Effort = Adjusted Use-Case Point × 2

Work Breakdown Structure

Step 1 − Create WBS by breaking down the test project into small pieces.
Step 2 − Divide modules into sub-modules.
Step 3 Divide sub-modules further into functionalities.
Step 4 − Divide functionalities into sub-functionalities.
Step 5 − Review all the testing requirements to make sure they are added in WBS.
Step 6 − Figure out the number of tasks your team needs to complete.
Step 7 − Estimate the effort for each task.
Step 8 − Estimate the duration of each task.
Wideband Delphi Technique

In Wideband Delphi Method, WBS is distributed to a team comprising of 3-7 members for re-estimating
the tasks. The final estimate is the result of the summarized estimates based on the team consensus.
This method speaks more on experience rather than any statistical formula. This method was popularized
by Barry Boehm to emphasize on the group iteration to reach a consensus where the team visualized
different aspects of the problems while estimating the test effort.

Function Point / Testing Point Analysis

FPs indicate the functionality of software application from the user's perspective and is used as a
technique to estimate the size of a software project.
In testing, estimation is based on requirement specification document, or on a previously created
prototype of the application. To calculate FP for a project, some major components are required. They
are −
• Unadjusted Data Function Points − i) Internal Files, ii) External Interfaces
• Unadjusted Transaction Function Points − i) User Inputs, ii) User Outputs & iii) User Inquiries
• Capers Jones basic formula −
Number of Test Cases = (Number of Function Points) × 1.2
• Total Actual Effort (TAE) −
(Number of Test cases) × (Percentage of Development Effort /100)

Percentage Distribution

In this technique, all the phases of Software Development Life Cycle (SDLC) are assigned effort in %.
This can be based on past data from similar projects. For example −

Phase % of Effort

Project Management 7%

Requirements 9%

Design 16%

Coding 26%

Testing (all Test Phases) 27%

Documentation 9%

Installation and Training 6%

Next, % of effort for testing (all test phases) is further distributed for all Testing Phases −

All Testing Phases % of Effort

Component Testing 16

Independent Testing 84

Total 100

Independent Testing % of Effort

Integration Testing 24

System Testing 52

Acceptance Testing 24

Total 100

System Testing % of Effort

Functional System Testing 65

Non-functional System Testing 35

Total 100

Test Planning and Design Architecture 50%

Review phase 50%

Experience-based Testing Estimation Technique

This technique is based on analogies and experts. The technique assumes that you already tested similar
applications in previous projects and collected metrics from those projects. You also collected metrics
from previous tests. Take inputs from subject matter experts who know the application (as well as
testing) very well and use the metrics you have collected and arrive at the testing effort.