The document presents a case study on agile software development methodologies, specifically focusing on creating a web application aimed at supporting women in Andhra Pradesh. It discusses the advantages of agile methods, such as flexibility and client involvement, compared to the traditional waterfall model, and details various methodologies including Scrum and Extreme Programming (XP). The application development process includes phases for analysis, design, testing, and feedback mechanisms to ensure effective collaboration and responsiveness to user needs.

1. AGILE S/W
DEVELOPMENT
A C A S E S T U D Y O F W E B A P P L I C A T I
O N
N R I P E S H K A R M A C H A R Y A ( 2
1 ) S A J A N M A H A T ( 3
0 )
B I S H E S H W O R N E U P A N E ( 3 5 )
G A U R A B S H R E S T H A ( 4 3 )
U M E S H S H R E S T
H A ( 4 7 ) S A B I N T H A
P A ( 5 4 )

2. Introduction
Methodology
Analysis
Design
Testing
Scrum
Conclusion
Contents

3. Introductio
n
Case
Study
A case study on Women's Era (WE) for state-
level development and support
Women from different categories of society
from different areas of Andhra Pradesh
A web application addressing the requirements
Development of the project using Agile
Development Methodologies: Extreme Programming (XP) &
Scrum

4. Introductio
n
Agile Method for S/W Development / Agile Modelling
Software development methodology centered around the idea
of iterative development.
Eliminates much of the modeling and documentation overhead
and the time spent on the task.
Usually used to deal with the situations where the traditional
waterfall model fails.
What is a waterfall model?
Agile: is a reference to the ability to adapt to contextual changes and changes to specifications that
occur during the development process.

5. Waterfall
Model
Software development methodology centered around the idea
of linear sequential development.
Planning
Analysis
Design
Implementation
Support
Introductio
n

6. Waterfall Model : Drawbacks
Difficult in making changes
Focuses very little on end-users as their motto is to help
internal teams move efficiently through the project
Delays testing until after production
How does Agile methodology address these
drawbacks?
Introductio
n

7. Agile Methodology
Unlike waterfall methodology, teams can work simultaneously
on different phases of the project.
Flexible to change directions and experiment new features at
any given time.
Client-facing - sharing progress with client and gathering
feedbacks.
Methodolog
y

8. Agile Methodology
Methodolog
y

9. Agile Methodology
Agile methodology makes three key assumptions about a
software project:
It is difficult to predict in advance which software
requirements will persist and which will change. It is equally
difficult to predict how customer priorities will change as a
project proceeds.
For many types of software, design and construction are
interleaved (alternated).
Analysis, design, construction, and testing are not as
predictable as we might like.
An agile process, therefore, must be adaptable.
Methodolog
y

10. Agile Methodology
Types
Kanban.
Scrum.
Extreme Programming (XP)
Crystal.
Dynamic Systems Development Method (DSDM)
Methodolog
y

11. Methodolog
y
Information Gathering
After collaborative communication with the end-users, the
information gathered are:
To know the Legal Matters related to Women.
Different University Notification in a single point
access. Expert lectures and study material
T
o have the information related to the precautions and preventions
of various diseases and likes to have suggestions from the
Medical practitioners.
To know the information related to local, national and international
recipes.
Government Schemes related to women.

12. Methodolog
y
Issues and solutions
Recipes
Websites & expert chefs
Government Schemes
www.aponline.gov &
government sites
Legal
Lawyers, police, social
organizations
Educational
University websites, study
materials and expert lectures.
Medical
Medical practitioners - info
about various diseases &
precautions

13. ANALYSI
S
Definition:
collecting factual data
understanding the processes
involved identfying problems
recommending feasible suggestions for improving the
system functioning

14. ANALYSI
S
It involves:
studying business processes
gathering operational data
understanding the information
flow finding out bottlenecks
evolving solutions for overcoming the weaknesses of the system
so as to achieve organizational goals
decomposition of complex processes
identification of data store and manual
processes

15. ANALYSI
S
The phases of analysis involves three different steps.
It involves 3 sequential steps
Analysis Strategy: To guide the projects team's effort.
Requirements Gathering: To collect informations regarding
requirements which leads to the development of a concept
System Proposal: To be presented to the project sponsor or to
any individuals who decides whether it should proceed or not

16. ANALYSI
S
Based on case
study
concentrate on the requirements of users called stories
consists of the features and functionalities and these will be placed
on index cards.
customers specify the values for these requirements called
Priorities. depending on the priorities specified by the customers
releases will be done.

17. ANALYSI
S
Customer Interest
Chart

18. ANALYSI
S
Priority
Chart

19. Terminologies
DESIGN
System
Architecture CRC
Cards
MVC model
1
2
4
3
5
Content
s
DESIG
N

20. Terminologie
s
1. XP( Extreme Programming)
XP is agile software
development
framework, applicable most for
dynamically changing software
requirements.
Five values of XP are
Communication, simplicity,
feedback, courage, and respect.

21. Terminologies
KIS principle stands for Keep it Simple.
A design principle states that designs and/or systems should be
as simple as possible.
Wherever possible, complexity should be avoided in a system- as
simplicity guarantees the greatest level of user acceptance
and interaction.
2. KIS

22. Terminologies 3. CRC (Class-Responsibility- Collaborator) cards
CRC is a collection of standard
index
cards that have been divided into
three sections as shown in the figure.
Class is a collection of similar objects.
A responsibility is anything a class
knows or does.
A collaborator is any other class with
whom a class collaborates to get
the
job
done.
CRC cards
template

23. Terminologies CRC example
CRC cards
example

24. Terminologies
The model contains only the
pure application data.
The view presents the model's
data to the user. It only knows
how to access the model's data.
The controller listens to events
triggered by the view and
executes the appropriate reaction
to these events.
4. MVC Design
Pattern
MVC
design

25. DESIGN
Design
XP follows KIS principle.
CRC cards identify and organize the object-oriented classes that are relevant
to the current software increment.
Design occurs both before and after coding commences.
Refactoring means that design occurs continuously as the system is
constructed.
From the
paper...

26. DESIGN System Architecture

27. DESIGN CRC
Cards
According to the architecture, the following are the classes:
In Legal issues Complaint registration, Complaint status, Advice from
Advocates, and Helping Hands are some classes. The classes Complaint
registration and Complaint status have internal relationships.
In Educational Issues courses, E-Sources, Notifications, and Empowering girls
are the individual functionalities with no interdependency between the classes.
In Medical issues, Home & Health, Health A-Z, Drugs & Supplements, Healthy
living, Eating & Diet, Parenting & Pregnancy, and Teen Health are some
functions with no interoperability between them.
In Recipes there are two functionalities: Add Recipes and Download.
In Government schemes, they planned to post the information related
to government schemes.

28. DESIGN
MVC design pattern make the development and maintenance simpler.
MVC is a fundamental design pattern for the separation between
user interface logic and business logic.
MVC design pattern

29. DESIGN
The model represents
the
business or database code.
The view represents the
page design code.
THe controller represents
the navigational code.
MVC model
used
Fig 4: MVC
model

30. TESTING

31. Testing
Agile Testing
Unlike Waterfall model where the testing is typically the final
phase in the SDLC before deployment, Agile testing can begin at
the start of the project with continuous integration between
development and testing.
So, less chance to find out that a product fails to deliver on its
promises, or includes big defects, right before it goes live.
Not sequential (in a sense that it is executed only after each
coding phase).
Continuous

32. Testing
Agile Testing sample (from the case
study)
Unit testing +
System
testing

33. Testing
Acceptance
Testing
Acceptance testing is where you find out whether the software
you created is what the customer and the users expected or
not.
Performed after System Testing and before making the system
available for actual use.
Similar to a unit test, an acceptance test generally has a binary
result, pass or fail. A failure suggests, though does not prove, the
presence of a defect in the product.

34. Testing
Acceptance
Testing
Once the System Testing process is completed by the testing
team and is signed-off, the entire product is handed over to few
users to test for its acceptability.
Development System
Testing
Acceptance
Testing
Productio
n
Acceptance criteria are defined when a user story is created. This
drives the testing and validation of the user stories.

35. Testing
System Testing vs Acceptance
Testing
System Testing Acceptance Testing
End to end testing is performed to
determine whether the product meets all
specified requirements.
Testing is performed to verify whether the
product meets the customer requirements
for acceptability.
It is focused only on the functional and
non-functional requirements.
It is focused on user acceptance, operations
and rules and regulations
Only test data is used for testing.
Real time data / Production data is used for
testing.

36. Testing
Forms of Acceptance
Testing
Various forms of acceptance testing based on the test
performers.
Acceptance Testing
Internal Acceptance
Testing
External Acceptance
Testing
Customer Acceptance
Testing
User Acceptance
Testing

37. Testing
Internal Acceptance
Testing
Also known as Alpha Testing.
It is performed by members of the organization that
developed the software but who are indirectly involved in the
development of the software.
It is called alpha only because it is done early on, near the end
of the development of the software, and before beta testing.
Here usually the analysts and designers are involved.

38. Testing
External Acceptance
Testing
It is performed by people who are not employees of
the organization that developed the software.
Two types:
Customer Acceptance
Testing
User Acceptance
Testing

39. Testing
Customer Acceptance
Testing
It is performed by the customers of the organization that
developed the software.
They are the ones who asked the organization to develop the
software for them.
In the case study, the project was for social benefit so no specific
customer was there. So, they involved the Doctors, Lawyers and
members of social organizations who shared their knowledge to
start the process.

40. Testing
User Acceptance
Testing
Also known as Beta Testing.
The testing is done by the end users of the software.
The end users can be customers themselves or the customers'
customers.
Direct feedback from customers is a major advantage of Beta Testing.
This testing helps to test products in customer’s environment.
In the case study, to perform this task 50 women member from
different categories of the society were selected to finally identify all
possible issues and bugs before releasing the final product to the end
users.

41. Scrum
It is a Agile Development framework.
Helps teams work together, encourages to learn through
experience, self-organize while working on problem and reflect on
the wins and loses to continuously improve.
This framework is used in developing, delivering and sustaining
complex products/projects.
Helps shift thinking in a more agile manner and start implementing
agile principles.

42. Scrum
In Scrum, we break down the project into many sprints(bite sized
pieces) to develop the product.
This makes the project much more manageable.
This helps deliver high quality work faster and more frequently.
During product development, the requirements, goals and the
situations can keep changing. The Scrum methodology gives you
more flexibility to adapt to these changes.

43. It reduces the risk taken and cost during development.
Developers can get feedback from the users faster.
The products speed to market is increased and can get value from
the development quicker.
Milestones like end of Sprint are reached quickly and frequently
which gives the team regular sense of progress and keeps them
motivated.
Pluses of Scrum

44. Uses short, iterative release cycles called Sprints.
Product Backlog keeps track of all the features,
requirements, enhancements and fixes that need to be
implemented in the product.
Things to be done in the next sprint are decided from the product
backlog keeping in mind the priorities and the duration of the sprint.
A sprint normally lasts 2 weeks, but this can be extended or
decreased depending on the product/project.
How does it work?

45. The Scrum Activities can be divided into 3
phases: Pre-Game
Sprint Planning
Architecture
Game:
Sprint
Daily Scrum or
Standup Post-Game
Sprint Review
Sprint
Retrospective
Scrum Events/Ceremonies:

46. Sprint Planning:
Providing definition of new release based on currently know backlog
as well as its schedule and cost. If a completely new system is being
developed, this phase consists of both conceptualization and
analysis.
Architecture:
The architecture of scrum deals with the development of design
which specifies the process patterns for work units called sprints.
Pre-Game

47. These requirements have been specified in XP.
During sprints the work units are frozen and allotted to team
members to work in stable environment.

48. Sprint :
A sprint lasts on average 2 weeks during which the daily scrum takes
place.
Daily Scrum or Standup:
Daily Scrum is a short meeting between the team members. This
makes sure that the members are on the same page. This meeting is
used to voice concerns and hindrance you might be facing to
accomplish the sprint backlog.
Game

49. Sprint Review:
This is an informal session to see what was accomplished
throughout the sprint. The Development Team shows the Product
Owner the backlog tasks they have accomplished during the sprint
to get approval for release. The product owner also rework the
product backlog with regard to the current sprint. This serves as a
backbone for future sprint.
Sprint Retrospective:
As the name suggests, this is used to look back on the sprint and
discuss what worked well and what didn't. It can be about the sprint
in general or particular people and their relationship or ceremonies
for it to be focused on and improved on in the next sprint.
Post-Game

51. Agile Development is open to adaptation and welcomes change
even in later phases of the project. This makes it much more flexible
than Waterfall Development. Feedback can also be gathered
through the users and clients. XP methodology divides stories into
smaller stories depending on time factor, and allows for changes in
the middle of development. Whereas in Scrum when the sprints are
identified and allotted to team members, no modifications are
allowed before completion.
Conclusion

52. Thank
you!
Feel free to approach us
if you have any questions.