SOFTWARE ENGINEERING

Module 03
Chapter 01
The methodology comprises various approaches to software
development under which requirements and solutions evolve
through the collaborative effort of self-organizing and cross-
functional teams and their customer(s)/end user(s).

It advocates adaptive planning, evolutionary development,

early delivery, and continual improvement, and it encourages
rapid and flexible response to change. Scrum is a type of
methodology under Agile.
• Individuals and Interactions over processes and tools

• Working Software over comprehensive documentation

• Customer Collaboration over contract negotiation

• Responding to Change over following a plan

• Tools and processes are important, but it is more
important to have competent people working
together effectively.

• Good documentation is useful in helping people

to understand how the software is built and how
to use it, but the main point of development is to
create software, not documentation.
• A contract is important but is no substitute for
working closely with customers to discover what
they need.

• A project plan is important, but it must not be too

rigid to accommodate changes in technology or the
environment, stakeholders’ priorities, and people's
understanding of the problem and its solution.
• Customer satisfaction by early and continuous
delivery of valuable software.
• Welcome changing requirements, even in late
development.
• Deliver working software frequently (weeks
rather than months)
• Close, daily cooperation between business
people and developers
• Projects are built around motivated individuals,
who should be trusted
• Face-to-face conversation is the best form of
communication (co-location)
• Working software is the primary measure of
progress
• Sustainable development, able to maintain a
constant pace
• Continuous attention to technical excellence and
good design
• Simplicity—the art of maximizing the amount of
work not done—is essential
• Best architectures, requirements, and designs
emerge from self-organizing teams
• Regularly, the team reflects on how to become
more effective, and adjusts accordingly
Agile breaks product development work into small increments
that minimize the amount of up-front planning and design. At
the end of an iteration a working product is demonstrated to
stakeholders to minimize overall risk and allows the product
to adapt to changes quickly. It involves in all functions,
namely:
• Planning;
• Analysis;
• Design;
• Coding; and
• Testing.
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 at the end of the project.
make decision and changes to the project.
Agile Model Waterfall Model

•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 and
quickly. For large projects, it is difficult to 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.
Agile Model
•Development process is iterative, and the
project is executed in short (2-4) weeks
iterations. Planning is very less.
•Documentation attends less priority than
software development
•Every iteration has its own testing phase. It
allows implementing regression testing every
time new functions or logic are released.
Waterfall Model
•The development process is phased, and
the phase is much bigger than iteration.
Every phase ends with the detailed
description of the next phase.
•Documentation is a top priority and can
even use for training staff and upgrade the
software with another team
•Only after the development phase, the
testing phase is executed because separate
parts are not fully functional.
Agile Model
•In agile testing when an iteration end,
shippable features of the product is delivered to after the long implementation phase.
the customer. New features are usable right
after shipment.
•Testers and developers work together. At the
end of every sprint, user acceptance is
performed.
•It requires close communication with
developers and together analyze requirements
and planning.
Waterfall Model
•All features developed are delivered at once
•Testers work separately from developers.
User acceptance is performed at the end of
the project.
•Developer does not involve in requirement
and planning process. Usually, time delays
between tests and coding.
Throughout the years, a number of agile methodologies
have been developed and used by various projects.
Scrum, being among them, share much of the same
philosophy, as well as many of the same characteristics
and practices.

However, from an implementation standpoint, each has

its own recipe of practices, terminology, and tactics. The
approach varies in its project management.
Scrum is an agile process framework for managing
complex knowledge work, with an initial emphasis
on software development, research and advanced
technologies.

It is designed for teams of ten or fewer members, who

break their work into goals that can be completed within
timeboxed iterations, called sprints in no longer than a
month and most commonly two (2) weeks, then track
progress and re-plan in 15-minute time-boxed daily
meetings, called daily scrums.
While project management methods emphasize building an
entire product in one iteration from start to finish, agile scrum
methodology focuses on delivering several iterations of a
product to provide stakeholders with the highest business value
in the least amount of time.

It encourages products to be built faster, since each set of goals

must be completed within each sprint's time frame. It also
requires frequent planning and goal setting, which helps the
scrum team focus on the current sprint's objectives and increase
productivity.
• Flexibility and adaptability
• Creativity and innovation
• Lower costs
• Quality improvement
• Organizational synergy
• Employee satisfaction
• Customer satisfaction
1.Scrum Master

2.Product Owner

3.Scrum Development
Team
The scrum master is the facilitator of the scrum development
process. In addition to holding daily meetings with the scrum
team, the scrum master makes certain that scrum rules are
being enforced and applied as intended.

The scrum master's responsibilities also include coaching

and motivating the team, removing impediments to sprints,
and ensuring that the team has the best possible conditions
to meet its goals and produce deliverable products.
They represents stakeholders, which are typically customers.
To ensure the team is always delivering value to stakeholders
and the business, the product owner determines product
expectations, records changes and administers a scrum
backlog, a detailed and constantly updated to-do list for the
scrum project.

The product owner is also responsible for prioritizing goals for

each sprint, based on their value to stakeholders, such that
the most important and deliverable features are built in each
iteration.
The scrum team is a self-organized group of three to
ten individuals who have the business, design,
analytical and development skills to carry out the
actual work, solve problems and produce deliverable
products.

Members of the scrum team self-administer tasks and

are jointly responsible for meeting each sprint's goals
while being monitored by the Scrum Master
1. Sprint
2. Sprint Planning
3. Daily Scrum
4. Sprint Review
5. Sprint Retrospective
6. Backlog Refinement
A sprint (or timebox) is the basic unit of development in
Scrum. The sprint is a timeboxed effort with the length
agreed and fixed in advance for each sprint and is normally
between one week and one month, with two weeks being
the most common. Each sprint starts with a sprint
planning event that establishes a sprint goal and the
required product backlog items. The team accepts what they
agree is ready and translate this into a sprint backlog, with a
breakdown of the work required and an estimated forecast
for the sprint goal.
• Mutual discussion and agree on the scope of work
• Select product backlogs that can be completed in one sprint
• Prepare a sprint backlog that includes the work needed to be
completed
• Agree on a sprint goal, a short description of what they are
forecasting to deliver at the end of the sprint.
• Maintain the four (4) hours duration for a 2-week sprint
• From the prepared sprint backlog, development team
forecast (usually by voting) which tasks will be delivered
within the sprint
• Each day during a sprint, the team holds a daily scrum
with specific guidelines. All members of the
development team come prepared. The daily scrum:
• starts precisely on time even if some development team
members are missing
• should happen at the same time and place every day
• is limited (timeboxed) to fifteen minutes
• Anyone is welcome, though only development team
members should contribute.
During the daily scrum, each team member
typically answers three questions:
1. What did I complete yesterday that contributed to the
team meeting our sprint goal?
2. What do I plan to complete today to contribute to the
team meeting our sprint goal?
3. Do I see any impediment that could prevent me or the
team from meeting our sprint goal?
At the sprint review, the team:
• reviews the work that was completed and the planned
work that was not completed
• presents the completed work to the stakeholders
• collaborates with the stakeholders on what to work on next
Guidelines for sprint reviews:
• Incomplete work cannot be demonstrated.
• The recommended duration is two hours for a two-week
sprint (proportional for other sprint-durations)
At the sprint retrospective, the team:
• Reflects on the past sprint
• Identifies and agrees on continuous process improvement actions

Guidelines for sprint retrospectives:

• Three main questions are asked in the sprint retrospective: What went
well during the sprint? What did not go well? What could be improved
for better productivity in the next sprint?
• The recommended duration is one-and-a-half hours for a two-week
sprint (proportional for other sprint duration(s))
• The event is facilitated by the scrum master
Backlog refinement (formerly called grooming) is the
ongoing process of reviewing product backlog items and
checking that they are appropriately prepared and ordered
in a way that makes them clear and executable for teams
once they enter sprints via the sprint planning activity.

Product backlog items may be broken into multiple smaller

ones. Acceptance criteria may be clarified. Dependencies
may be identified and investigated.
Alfonso, A. (2018). Learn The Scrum Ceremonies In This Stunningly Simple Guide.
Retrieved from, https://thedigitalprojectmanager.com/scrum-ceremonies-made-
simple/

Attkisson, A. (2020). What Is Agile Scrum Methodology? Retrieved from, https://

www.businessnewsdaily.com/4987-what-is-agile-scrum-methodology.html

Bentley, L. D. (2013). Systems Analysis and Design for the Global Enterprise. 7th Edition,
ISBN-13: 978-0071107662: Mc Graw-Hill Press

Cho, L. (2009). Adopting an Agile Culture A User Experience Team's Journey. Agile
Conference, pp. 416-421
Gangji, A., Hartman, B. (2015). Agile SCRUM for Denver Web Development. Retrieved
from, https://www.neonrain.com/agile-scrum-web-development

Guru (2020). Agile Methodology & Model: Guide for Software Development & Testing.
Retrieved from, https://www.guru99.com/ agile-scrum-extreme-testing.html

Highsmith, J. (2001). History: The Agile Manifesto. Retrieved from, http://

agilemanifesto.org/history.html

Kent, B., Grenning, J., Martin, R. C., et. al. (2010). Principles Behind the Agile Manifesto.
Retrieved from, http://agilemanifesto.org/principles.html