Genba Sopanrao Moze College Of Engineering, Balewadi - Pune

Department of MCA, F.Y SEM – I, Software Engineering and project Management

SOFTWARE
ENGINEERING &
PROJECT
MANAGEMENT
[310904]
LECTURE NOTES

MCA I YEAR – SEM (I)

(2022-2023)

DEPARTMENT OF MCA
Faculty of Science and Technology

Prepared by , Prof. Mukta Deshpande HOD (MCA) Page 1

 Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management

Unit 3 - Agile Development Process

Introduction to Agile Software Development

Agile is a topic of growing importance in software industry that helps the organization to be
more flexible to change and to deliver workable software in a shorter span of time benefiting
both the customer and the executing organization. It has been a subject of long debate since the
time the concept of agile methodology arrived whether agile is a better methodology than the
traditional waterfall. Understanding the difference in philosophy of the traditional project
execution model versus Agile is very important before exploring different agile methodologies.
This chapter discusses the definition of agile, agile manifesto values and principles, names of
different agile methodologies, and terminologies related to agile methodology.

WHAT IS AGILE?

Agile frame work tries to address the limitations of traditional methodologies.

Limitation of traditional project execution methodologies
1. Modern projects are constrained by lot of uncertainties more on what is expected/What is
anticipated in the beginning of the project.
2. Although there is as process to handle difficult situation, people should be empowered to
execute it.
3. It is difficult to change the plan once it is base lined. Customer needs to follow a change
control System. Customer happens to pay even for genuine change.
4. End users see the end product only at the end of the project.
5. There is a huge gap between the expectations of the customer and the end users of the product
And because of which most of the IT projects face problem in user acceptance testing phase.
6. Project is often isolated from the business changing scenario. Once initiated the changes are
Often very difficult to be inserted by the customer however genuine case it may be.
7. Most of the projects are scrapped due to change in technologies and business conditions
during

Prepared by , Prof. Mukta Deshpande HOD (MCA) Page 2

 Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management

the execution of the project.

8. Traditional project management tries to defi ne the timeline and cost based on the scope of the
project. But as the project progresses, the scope is getting changed but the timeline is not revised
which leads to team frustration.
9. Often the customer is ending up paying more than what was estimated for the project in the
beginning.
10. As team is not empowered to take decisions, the execution part is entirely different from the
planning (mostly owned by the project manager). Most of the time, the execution is not
happening
as per the initial plan.
11. Customer only sees the interim deliverables during the various phases of the project, which
may not reflect the actual final product.

How agile methodologies overcome the limitations of traditional project execution?

1. Agile project involves the end user throughout the life cycle of the project to avoid conflicts at
a later stage.
2. Agile project produces incremental product at the end of every phase of the project (the
concept of phase getting changed).
3. Agile project delivers important features first.
4. Customers are given flexibility to add/modify/delete the requirement until the team actually
starts working on it. Customers are also given options to prioritize the requirements.
5. Agile project engages all the stakeholders (usually in traditional project management only the
team is involved and engaged).
6. Agile project gets the commitment from the team (in traditional project management, only the
tasks are allocated to the team without getting their commitment).
7. Agile project does planning at multiple levels of the projects (in traditional project
management, only high-level planning is done and once it is fixed execution starts. There are no
plans at execution levels.).
8. Agile project encourages proactive risk identification.
9. Agile project allows open and transparent project management

Prepared by , Prof. Mukta Deshpande HOD (MCA) Page 3

 Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management

10. Agile project continuously improves product, process, and people (in traditional project
management more concentration is on process.).

AGILE MANIFESTO

Individuals and interactions over processes and tools: Agile focuses on empowered and self-
organized team which gives more importance to interactions. Daily planning is based on this
value, which
helps to overcome the impediments faced by the team members in frequent manner. Frequent
interactions also help to get the team commitment and get more focus on the tasks on the hand.
Team helps each other because of this. This does not mean that process and tools were not
required for the execution of agile projects, it means that more importance is given to individuals
and interactions. Wherever possible, individual interactions need to be encouraged rather than
using tools for communication.

Working software over comprehensive documentation: Documentation needs to be prepared

only wherever necessary and more importance to be given to working software. Lot of people
misunderstood this statement as an agile project does not require any documentation. This is not
the actual meaning. Documentations, such as end user manual are very much necessary and it
adds more value and it must be created. Compliance-related documents need to be prepared
because it is compliant with the rules and regulations. But rather than converting the requirement
into various types of documentation and converting the documentations into the final product,
agile stresses the importance to covert the requirements straight into the product thereby
delivering value early to the customer. Agile project gives incremental working software as
deliverable rather than documentations, such as what is done with traditional project
management. Measurement of the project progress not measured based on the milestone
deliverables but based on the feature delivered into the system incrementally. Customer
collaboration over contract negotiation: In traditional projects everything is decided (scope,
price, and time) upfront and put it in a contract before starting the project. There are lots of
disadvantages because of this. Team stretch their working hours and they work day, night to

Prepared by , Prof. Mukta Deshpande HOD (MCA) Page 4

 Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management

meet the deadline, because of which the quality of the product may go down. Because the scope
is fixed, even

Individuals and Interactions over process and tools

Working software over comprehensive documentation
Costomer collaboration over contract negotiation
Responding to change over following a plan

Figure 1 Manifesto for Agile Software Development

Principles behind agile manifesto

Twelve principles behind agile manifesto: Fundamental truths and shared values that drive the
agile methodologies are called as agile principles. Agile principles help to manage change,
manage the uncertainty, increase efficiency, reduce Cost, increase value to the stakeholders, and
improve project progress predictability. Following 12 principles are derived based on four values
of agile manifesto.
1. The highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change
for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
Preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity—the art of maximizing the amount of work not done— is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.

Prepared by , Prof. Mukta Deshpande HOD (MCA) Page 5

 Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management

12. At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.

An Agility and Cost of Change:

The conventional wisdom in software development is that the cost of change increases
nonlinearly as a project progresses (solid red curve). A usage scenario might have to be
modified; a list of functions may be extended. The change requires a modification to the
architectural design of the software, the design and construction of three new components,
modifications to another five components, the design of new tests, and so on. Costs escalate
quickly, and the time and cost required to ensure that the change is made without unintended side
effects is nontrivial. Agility argue that a well-designed agile process “flattens” the cost of change
curve (solid green curve), allowing a software team to accommodate changes late in a software
project without dramatic cost and time impact.

Human Factors

Proponents of agile software development take great pains to emphasize the importance of
“people factors.” As Cockburn and Highsmith [Coc01a] state, “Agile development focuses on
the talents and skills of individuals, molding the process to specific people and teams.” The key
point in this statement is that the process molds to the needs of the people and team, not the other
way around.2 If members of the software team are to drive the characteristics of the process that
is applied to build software, a number of key traits must exist among the people on an agile team
and the team itself:

Prepared by , Prof. Mukta Deshpande HOD (MCA) Page 6

 Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management

Competence. In an agile development (as well as software engineering) context, “competence”

encompasses innate talent, specific software-related skills, and overall knowledge of the process
that the team has chosen to apply. Skill and knowledge of process can and should be taught to all
people who serve as agile team members.

Common focus. Although members of the agile team may perform different tasks and bring
different skills to the project, all should be focused on one goal—to deliver a working software
increment to the customer within the time promised. To achieve this goal, the team will also
focus on continual adaptations (small and large) that will make the process fit the needs of the
team.

Collaboration. Software engineering (regardless of process) is about assessing, analyzing, and

using information that is communicated to the software team; creating information that will help
all stakeholders understand the work of the team; and building information (computer software
and relevant databases) that provides business value for the customer. To accomplish these tasks,
team members must collaborate—with one another and all other stakeholders.

Decision-making ability. Any good software team (including agile teams) must be allowed the
freedom to control its own destiny. This implies that the team is given autonomy—decision-
making authority for both technical and project issues.

Fuzzy problem-solving ability. Software managers must recognize that the agile team will
continually have to deal with ambiguity and will continually be buffeted by change. In some
cases, the team must accept the fact that the problem they are solving today may not be the
problem that needs to be solved tomorrow. However, lessons learned from any problem-solving
activity (including those that solve the wrong problem) may be of benefit to the team later in the
project

Mutual trust and respect. The agile team must become what DeMarco and Lister [DeM98] call
a “jelled” team (Chapter 24). A jelled team exhibits the trust and respect that are necessary to
make them “so strongly knit that the whole is greater than the sum of the parts.” [DeM98]

Prepared by , Prof. Mukta Deshpande HOD (MCA) Page 7

 Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management

Self-organization. In the context of agile development, self-organization implies three things:

(1) the agile team organizes itself for the work to be done, (2) the team organizes the process to
best accommodate its local environment, (3) the team organizes the work schedule to best
achieve delivery of the software increment. Self-organization has a number of technical benefits,
but more importantly, it serves to improve collaboration and boost team morale. In essence, the
team serves as its own management. Ken Schwaber [Sch02] addresses these issues when he
writes: “The team selects how much work it believes it can perform within the iteration, and the
team commits to the work. Nothing demotivates a team as much as someone else making
commitments for it. Nothing motivates a team as much as accepting the responsibility for
fulfilling commitments that it made itself.”

AGILE-RELATED CONCEPTS
Here are some of the agile-related concepts. These are predominantly used in all agile
methodologies.
Iteration: The ceremony in which working software is produced in agile project is called as
iteration. In agile project, working software is produced at the end of the iteration. The result of
an iteration which is usually working software is being used as the starting point of the next
subsequent iteration. Iteration demo to the customer happens at the end of the iteration followed
by iteration retrospection, which helps to improvise the next iteration cycle execution. Iteration is
usually a time boxed event.
Adaptive planning: Adaptive planning expects to define only a high-level plan for the far-end
features, but a detailed plan for the next immediate iteration. This is always a more comfortable
and realistic situation to live in, right? This is also referred to as rolling wave planning as the
process of planning for a project is happening in waves as the project becomes clearer and
complexities unfold. Only key milestones are highlighted in the initial stages for reference.
Time boxing: It is a fixed time frame within which the team tries to achieve the planned tasks
for the iteration and stops the iteration as soon as the timeline is over. Iterations follow a
consistent, unchanging schedule in which each activity is executed and these events are called as
time-boxed events.
• Demonstrate finished iteration outcome (up to an hour),
• Hold retrospective on previous iteration (1 h), and

Prepared by , Prof. Mukta Deshpande HOD (MCA) Page 8

 Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management

• Plan iteration (half an hour to 4 h).

This helps the team keep focused on the main activities and avoid spending time on the low-
priority tasks.

Minimal marketable future (MMF): MMF is the basis minimum feature of the product so that
People can start using it rather than waiting for all the futures. There will be a release after
minimal marketable futures gets created. It actually enables incremental delivery of the product.
Multiple MMF makes the whole product. MMF has value to the end user on its own.

Agile triangle: In traditional projects, the scope is fixed; Time and Cost are the deriving factors
of scope. In agile projects, time and costs and fixed through time boxing but scope is not fixed
for the entire project in a single stretch. It is being developed using just in time plan for the
iteration. So agile Triangle is the inverse triangle of traditional project where Time and Cost are
represented at the top and scope is derived from them (which is at the lower side).
Customer involvement: Agile manifesto recommends active customer participation and
involvement rather than time and effort expended on negotiating contracts. Agile software
development stresses in—evolving requirements accomplished by direct user involvement in the
development process, rapid iterations—small and frequent releases. Customer involvement in the
software development process is very critical to the success of the project. The agile methods
state that the customer should be part of the development process from analysis and design to
implementation and maintenance.
Re-factoring: Restructuring the code without changing the functionality is called as re-factoring.
It helps to strengthen the code further enabling for further addition of functionalities. It helps to
simplify the code. In agile projects, the same piece of code is re-factored multiple times to enable
future requirement to fit in.
Servant leader: Servant-leadership represents a model of leadership in agile projects in which
the leader assumes a service-orientated role as servant, serving the team. Servant leader will find
the need of the team and helps the team to solve the problem. Servant leader will not give any
instructions or commands to the team rather help them servicing and empowering the team.
Spike: Spike can be defined as a small learning period or technical investigation for solving a
Problem. Spike explores potential solutions for a difficult technical or design problem which can

Prepared by , Prof. Mukta Deshpande HOD (MCA) Page 9

 Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management

be used to provide a more accurate estimate. If the team does not know whether a particular
design approach will work out or not, it is recommended to do spikes to find out which design
approach will work out for the team. Spike solutions use controlled experiments to provide
information.
Technical debt: Technical debt is the total amount of less-than-perfect design and
implementation decisions in the agile project. It is a known technical problem in the code. As the
technical debt decreases, velocity (number of story points completed per iteration) will start rise
again. A thumb rule in agile project is to spend 10% of the iteration on technical debt.

Pair programming: Two people sit opposite to each other to code the program while the first
Person is actually coding the program, and other is checking the possible errors that might occur
as reviewer of the code. They also exchange the seats and thereby the roles (coders, reviewers).
Pair programming doubles the brainpower available during coding, and gives one person in each
pair the opportunity to think about strategic, long-term issues.

EPICS, FEATURES, USER STORIES

In agile project, the requirements are maintained in the forms of epics, features, and user stories.
Epics are collections of features, typically 1–3 months in duration. Features are smaller than
epics, typically executed in 2–4 weeks duration. User stories are the smallest increment of value
(created from feature) typically executed less than a week. A user story describes what the user
does with the software and how the software responds. A user story is a functional requirement
that resembles a use case and test case. In agile terminology product features are otherwise called
as user stories. User stories are much smaller than the usage requirement artifacts, such as use
cases or usage scenarios; user stories will be captured in the dialog format and anybody can
understand it easily. Three parts (3Cs) of user stories are card, conversation, and confirmation. In
agile stories are written in the form of a card (postal card size). In agile stories are written in the
form of conversation and it has a format: As a [Role] I want to do [feature] so that I can do
[reason/benefit]. It is actually the format of [Who] [What] [Why].
Example: As an end user I want to purchase the model question papers online so that I can avoid

Prepared by , Prof. Mukta Deshpande HOD (MCA) Page 10

 Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management

Delay in purchase. [Why] part is optional but it is better to describe it. Confirmation is the
acceptance criteria of a user story. The customer captures these criteria in acceptance tests,
designed to exercise the system in enough ways to demonstrate that the feature really works.
Types of user stories: User stories are of three types namely business user story, technical user
story, and bug user story. A technical story is a non-functional requirement that describes the
functionality supporting the user-facing features in user stories. Technical stories are usually
written by team members and are added to the product backlog. The product owner must be
familiar with these stories and understand the dependencies between these and user stories in
order to rank all stories for implementation.
Backlogs: In agile projects the requirements are maintained in the name of backlogs. It is
actually a to-do list of the project. Backlogs contain epics, features, user stories, bugs, and errors.
Iterative cycle backlog (sprint backlog) is a to-do list of that particular iterative cycle (sprint).
Iterative cycle backlog is being created by the team based on the high priority list of release
backlog. A release consists of multiple iterative cycles (sprints).

COMMUNICATION IN AGILE PROJECTS

Daily standup meeting (daily scrum meeting): Agile team works as per the principle of TEAM
(Together Everybody Achievers More). Each agile team members tries to help other team
members to finish their tasks. Team commitment is more important in agile projects. Nobody
allocates tasks to the team members; the team decides what tasks need to be executed on a
particular day in a ceremony called as daily standup meeting. They are short (15 min maximum)
but structured meetings that aim at uncovering any impediments (backlogs) in executing the
assigned tasks. Every team members gathers in a regular place and updates the team, what tasks
they executed yesterday, what tasks they are going to executing today, and what are all the
impediments while executing the tasks. There will not be any discussions or debate in this
meeting. It is not a status report meeting, as in agile projects team does not report status to
anybody but they just move the tasks board to reflect the current status of the tasks which will act
as information radiators for others.
Information radiators: Agile has a practice called “informative workspace” which is similar to

Prepared by , Prof. Mukta Deshpande HOD (MCA) Page 11

 Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management

war room of the traditional project team, where the team is displaying the product backlogs,
release backlogs, and iteration backlogs which are usually in the form of story cards or task cards
on the wall. Other graphs and charts prepared by the team is also being pasted on the wall which
are sometimes called “information radiators” or “Visible Big Charts.” There is no hard and fast
rule for the information radiators and the team displays the items, whatever they feel is useful for
them and for the execution of projects.
Burn charts: Burn charts helps to track the agile projects. It helps to show case the amount of
work
Completed, amount of work remaining, and projected completion dates. Team members are
actually motivated by the amount of work remaining steadily reduced. There are three types of
burn charts namely
• Burn down chart
• Burn up chart
• Combined chart
Burn charts are used for sprints as well as for releases. Burn down chart is also called as estimate
to complete chart. Because it is moving downward it is called burn down chart. It actually draws
the story points (measure of story) yet to be completed. While moving some story points are
done and so pending story points starts to come down and hence the chart points goes down. A
sprint burn down chart (or “sprint burn down graph”) compares actual and expected progress,
and shows whether the team is ahead or behind expectations. Expected progress line is a line
drawn between total story points to be completed and zero. Burn down chart is drawn either with
the story points or time estimate.
It is up to the team to decide which one to choose for the project; whichever is comfortable with
the team can be chosen. Team can draw the burn down graph for sprint, release, and multiple
releases too. Time scale is longer for release and multiple release charts.
Burn down chart shows only how much work is pending (remains to be completed) at the end of
Each iteration and does not show up whether there is any change in the total story points and it
also Does not show how much work actually accomplished in each iteration. Burn up chart is
helpful to showcase how much work is actually completed. Combined chart is the combination
of both burn down chart and burn up chart. Both the charts are showing in the same graph.

Prepared by , Prof. Mukta Deshpande HOD (MCA) Page 12

 Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management

Retrospection: Agile is not a prescriptive methodology, but rather it is a framework that should
be adapted according to the given project, team, and specifi c circumstances. The iteration
retrospective is an important mechanism that allows a team to continuously evolve and improve
through the life of a project. Key elements of the retrospective meeting are
• Process improvements are made at end of every iteration—ensures that the project team is
Always in self-improving mode.
• The retrospective is a collaborative process between all members of the team.
• All team members identify what went well and what can be improved.
• The actions and lessons learnt are prioritized based on team direction.
• Team works out solution to most prominent problems—helps to build the team ownership and
Self-management.
• Helps the team formation and bonding as the areas of conflict can be identified and dealt with.

DIFFERENT AGILE METHODOLOGIES

Frameworks and process which are based on about agile manifesto are called agile
methodologies. Agile is a principle which is followed in different project execution
methodologies based on the type of engagement and project dynamic.
Following are the examples of agile methodologies:
1. Scrum methodology
2. Extreme programming (XP)
3. Dynamic system development method (DSDM)
4. Agile unified process (AUP)
5. Feature-driven development (FDD)
6. Lean software development
7. Crystal methods

Scrum Methodology
Scrum uses standard project management concepts but with different terminology and best
practices. Scrum is the most widely used methodology framework of agile. The term scrum is
related to the Rugby sports. Some of the scrum best practices are short fixed iterative cycle,

Prepared by , Prof. Mukta Deshpande HOD (MCA) Page 13

 Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management

adjustable scope, customer satisfaction through quick turnaround time, responding to change
quickly, and customer collaboration throughout the project. Scrum concepts have vision, product
backlog, release backlog, and sprint backlog. Product backlog is the highest level of the
requirement. Release backlog is prepared from the product backlog. Sprint backlog is prepared
from the release backlog.
The scrum project execution is explained as follows:
Step 1: Collect the product features(product backlog),
Step 2: Get the product features (backlog) in order,
Step 3: Plan the number of releases,
Step 4: Plan the number of iterative cycle in each release,
Step 5: Iterative cycle (sprint) planning: clarify the requirements,
Step 6: Iterative cycle (sprint) planning: estimate individual tasks,
Step 7: Create work environment for executing the iteration,
Step 8: Execute the iterative cycle (sprint),
Step 9: Conduct standup meeting to track the iterative cycle,
Step 10: Conduct iterative cycle retrospection at the end of iterative cycle,
Step 11: Go to Step 5 if there are more iterations in the release,
Step 12: Conduct release retrospection at the end of the release, and
Step 13: Go to Steps 3 and 4 if there are more releases to execute.
This methodology consists of three phases namely pregame, development phase, and post-game.
Iterative cycle is called as sprint. Sprint planning is happening in pregame phase. Actual sprint
execution is happening in development phase. Integration, retrospection is happening in the post-
game phase.
SCRUM methodology has the following elements
• A project team called a SCRUM team,
• A product backlog is a list of all known requirements,
• A sprint backlog is a list of all known requirements which team is going to work currently (in
the current sprint),

Prepared by , Prof. Mukta Deshpande HOD (MCA) Page 14

 Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management

Figure 2 Agile Scrum Methodology Flow

A period of work is called as sprint (it is actually the current phase of the project) and it is time
boxed usually.
• Daily standup meetings happens with the SCRUM team,
• A burn down chart, burn up chart to track progress of the sprint,
• An incremental product is delivered to the customer at the end of each sprint,
• SCRUM master is a facilitator and leader and also responsible for teaching others how to use
the scrum process to deal with every new complexity encountered during a project,
• Story point is the metric used for estimation,
•Scrum product owner is a customer representative (preferably) with highest business knowledge
who can prioritize the requirements based on the business value,
• Scrum master connects the team with the management and ensures that the team is able to
progress smoothly throughout the iteration cycle by helping them removing the impediments,
and
• Scrum team is a group of people doing the actual work for the project creating the potentially
shippable product at the end of the sprint.

SCRUM methodology challenges are

• Resistance and unlearning from team members on working on scrum, especially resources who

Prepared by , Prof. Mukta Deshpande HOD (MCA) Page 15

 Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management

are used to waterfall methodology.

• Managing expectations from clients—the clients may assume that any requirements change at
any time can be easily accommodated in scrum projects.
• Adhering to standards—expectations on detailed documentation.
• Code brittleness—in scrum, the same piece of code is re-factored multiple times after it is
deployed to enable future requirements to be fitted in. This continuous re-factoring may make
the code brittle and thereby impact the code quality.

Extreme Programming (XP)

Extreme programming is a method that is based upon agile concepts and the supporting XP
principals of rapid development, flexibility, team empowerment, and customer-based quality
management.
Following are the characteristics of XP
• Requirements changing almost every day,
• Total chaos in the project environment,
• Customer wants everything fast,
• Handling with new domain/technology, and
• Total uncertainty in everything.
In a nutshell, high speed, high change, and high uncertainties are the characteristics of XP.
Traditional project management (TPM) is actually just opposite to XP. Pair programming is
related to XP where two people sitting together and writing the same code.
Extreme programming actually supports test-driven development (TDD).

Test-Driven Development (TDD)

TDD can be used without extreme programming also. It actually recommends writing the
automated unit test first before writing the code. The test will not compile itself at the first
instance, so write the basic minimal code to make it compile. Run the test and see it fails because
full code was not implemented.

Prepared by , Prof. Mukta Deshpande HOD (MCA) Page 16

 Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management

Write the full code and make it pass. Re-factor for clarity and repeat. It actually increases the
speed and also improves the quality. Three A model (Arrange, Act, and Assert) is a type of TDD.
Following are the steps in TDD model
• Write a single test
• Compile the test. It will not compile because the code is not written,
• Implement the just enough code to enable the test to compile,
• Run the test and see it fails because there is no content inside,
• Implement just enough code to see the test pass,
• Run the test and see it pass,
• Re-factor the code for clarity, and
• Repeat the process.

Refactoring in Agile

Refactoring is the practice of continuously improving the design of existing code, without
changing the fundamental behavior. In Agile, teams maintain and enhance their code on an
incremental basis from Sprint to Sprint. If code is not refactored in an Agile project, it will
result in poor code quality, such as unhealthy dependencies between classes or packages,
improper class responsibility allocation, too many responsibilities per method or class,
duplicate code, and a variety of other types of confusion and clutter. Refactoring helps to
remove this chaos and simplifies the unclear and complex code.
It is best to refactor continuously, rather than in phases. Refactoring continuously prevents the
code from getting complicated and helps to keep the code clean and easy to maintain. In Agile
development, there can be short and separate sprints to accommodate refactoring.

Challenges:
Though refactoring brings a lot of benefits to the code quality of the software, there are
multiple challenges that dissuade developers in Agile projects from continuously refactoring
the code. Following are a few challenges that are mostly seen in Agile projects

Prepared by , Prof. Mukta Deshpande HOD (MCA) Page 17

 Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management

 Time Constraint: Time is the biggest challenge for doing refactoring in Agile projects as
the Sprints are time-boxed with a defined set of deliverables.
 Reluctance: If the code is working fine without any refactoring done, there will be an
inclination towards not revisiting the code. This is primarily because of the mindset that
there is no error and hence no need to do additional activities i.e. refactoring.
 Integration with branches: To integrate the code across different branches post
refactoring is considered a challenge
 Fear factor: Developer often fears that refactoring will introduce bugs and break the
existing functionality which is working fine
 Re-Testing: In case automated test suites are not available, the developer is discouraged to
do refactoring with the additional effort of manual testing to check the functionality
 Backward Compatibility: Backward compatibility often prevents developers from starting
refactoring efforts.

Motivation For Refactoring:

The following points for motivation are more common among the developers while they do
refactoring

 It becomes easier to add new code

 The existing code’s design is improved.
 Helps to gain a better understanding of code
 Makes coding less annoying
Advantages of Refactoring:
Refactoring in small steps helps to prevent defects from being introduced. The following
points can be further perceived from the benefits of implementing Refactoring.

 Improves software extendibility

 Reduce the expense of code maintenance.
 Provides standardized code
 Architecture improvement without impacting software behavior
 Provides more readable and modular code

Prepared by , Prof. Mukta Deshpande HOD (MCA) Page 18

 Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management

 Modular component refactored to maximize possible reusability

Difference between Scripted testing and Exploratory testing

1. Scripted testing:
In Scripted testing to test specific functionality a tester follows a detailed step-by-step
systematic approach. For this testing in advance the tester has to define the test cases of the
functionality along with its instructions to perform it and finally the expected outcome of the
test. Testers clearly follow the testing instructions and steps but in case they may deviate from
the script but which is very minimal in case of scripted testing. It ensures that every
functionality must be tested and passed. In this scripted testing skilled resources, well scripted
instructions and test cases and verification are required.

Advantages:
1. Well-suited for automation.
2. Good at finding functional defects.
3. Standardized documentation helps in repeatability and tracking.
Disadvantages:
1. Non-standard testing out comes is a concern.
2. Fewer bugs are found.
3. Testing horizon is limited to script only.
2. Exploratory testing:
Exploratory testing is more towards learning and experience based testing approach means it
depends more on the responsibility of a tester. So, a tester can apply this exploratory testing to
any test technique and at any time development stage. The key aspect of exploratory testing is
it depends on the skills and experience of individual testers. As it is adaptable to changes, so it
is very good for rapid changing development process and well suited for the agile development
approach.

Advantages:
1. It analyzes the application in a better way when the application is live.
2. Testers’ creativity, experience, & skill have a great impact on testing outcome.

Prepared by , Prof. Mukta Deshpande HOD (MCA) Page 19

 Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management

3. Helps in finding usability & UI issues.

4. Project owners can get insights that were not possible to get with scripted tests.
Disadvantages:
1. There is no documentation for reference.
2. A bias depending on the tester can exist.
3. Critical bugs can be missed.
Difference between Scripted testing and Exploratory testing :

S.NO. SCRIPTED TESTING EXPLORATORY TESTING

The test scripts can be traced back to

the original requirements and
specifications to demonstrate test In this testing no well documented, clear and
01. coverage. measurable test coverage.

This approach emphasizes prediction This approach emphasizes adaptability and

04. and decision-making. learning.

At the end of test cycle bugs are

05. detected. This approaches focuses more on test design.

Testers need to follow the sequence

and steps of test cases which are
06. designed in advance. Testers can alter tests on the fly.

07. Feedback is slower. Enables rapid feedback.

In this testing all test scripts and test As like scripted testing, in this test cases
08. cases are designed and reviewed in cannot

Prepared by , Prof. Mukta Deshpande HOD (MCA) Page 20

 Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management

advance.

As there are no clear and documented test

At the end of the testing cycle, cases, so there is no way to check and
testers can confirm if all the confirm that all the requirements have been
09. requirements have been met or not. met.

10. Managing test coverage is easier. Managing test coverage is challenging.

11. It can be automated. It cannot be automated.

Prepared by , Prof. Mukta Deshpande HOD (MCA) Page 21