SOFTWARE ENGINEERING

Lesson 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 Waterfall Model
•Development process is iterative, and the •The development process is phased, and
project is executed in short (2-4) weeks the phase is much bigger than iteration.
iterations. Planning is very less. Every phase ends with the detailed
description of the next phase.
•Documentation attends less priority than •Documentation is a top priority and can
software development 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 separate
time new functions or logic are released. parts are not fully functional.
Agile Model Waterfall Model
•In agile testing when an iteration end, •All features developed are delivered at once
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 •Testers work separately from developers.
end of every sprint, user acceptance is User acceptance is performed at the end of
performed. the project.
•It requires close communication with •Developer does not involve in requirement
developers and together analyze requirements and planning process. Usually, time delays
and planning. 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.
Lesson 02
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.
Lesson 03
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.

Developed by Alistair Cockburn, he 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.
• Teams can streamline their processes as their
work and become a more optimised team

• Projects are unique and dynamic and require

specific methods
1.Chartering

2.Cyclic Delivery

3.Wrap Up
Various activities involved in
this phase are creating a
development team, performing
a preliminary feasibility
analysis, developing an initial
plan and fine-tuning the
development methodology.
The main development phase consists of two or more
delivery cycles, during which the following occurs:

1. Team updates and refines the release plan

2. Implements a subset of the requirements through
one or more program test integrate iterations
3. Integrated product is delivered to real users
4. Review of the project plan and adopted
development methodology
The activities performed in
this phase are deployment
into the user environment,
post- deployment reviews
and reflections are
performed.
DSDM is a software development approach that
provides an agile project delivery framework. The
important aspect of DSDM is that the users are
required to be involved actively, and the teams are
given the power to make decisions. Frequent
delivery of product becomes the active focus with
DSDM.
Timeboxing: is the approach for completing the project
incrementally by breaking it down into splitting the project in
portions, each with a fixed budget and a delivery date. For
each portion a number of requirements are prioritised and
selected. Because time and budget are fixed, the only
remaining variables are the requirements. So if a project is
running out of time or money the requirements with the
lowest priority are omitted.
MoSCoW: is a prioritization technique used in
management, business analysis, project
management, and software development to reach a
common understanding with stakeholders on the
importance they place on the delivery of
each requirement. It is an acronym that stands for
Must have, Should have, Could have, and Won't
have.
Prototyping: refers to the creation of prototypes of
the system under development at an early stage of
the project. It enables the early discovery of
shortcomings in the system and allows future users
to test-drive the system. This way good user
involvement is realized, one of the key success
factors of DSDM, or any System Development
project for that matter.
1. Pre-project;
2. Feasibility Study;
3. Business Study;
4. Functional Model Iteration;
5. Design and build Iteration;
6. Implementation; and
7. Post-project.
Lesson 04
Feature Driven Development methodology is
focused around designing and building features.
Unlike other agile methods, FDD describes very
specific and short phases of work that has to be
accomplished separately per feature. It includes
domain walkthrough, design inspection, promote to
build, code inspection and design.
1. Domain object Modeling
2. Development by feature
3. Component/ Class Ownership
4. Feature Teams
5. Inspections
6. Configuration Management
7. Regular Builds
8. Visibility of progress and results
It is a translation of lean manufacturing principles and
practices to the software development domain. Adapted
from the Toyota Production System, it is emerging with the
support of a pro-lean subculture within the Agile community
based on the principle "Just in time production".

It aims at increasing speed of software development and

decreasing cost. Lean offers a solid conceptual framework,
values and principles, as well as good practices, derived
from experience, that support agile organizations.
1. Eliminating Waste;
2. Amplifying learning;
3. Defer commitment;
4. Early delivery;
5. Empowering the team;
6. Building Integrity; and
7. Optimize the whole.
Eliminating Wastes: If some activity could be bypassed or the
result could be achieved without it, it is waste. Partially done coding
eventually abandoned during the development process is waste.
Extra features like paperwork and features not often used by
customers are waste.

Amplifying Learning: Software development is a continuous

learning process based on iterations when writing code. Software
design is a problem-solving process involving the developers writing
the code and what they have learned. Software value is measured in
fitness for use and not in conformance to requirements.
Defer Commitment: As software development is always
associated with some uncertainty, better results should be
achieved with a set-based or options-based approach, delaying
decisions as much as possible until they can be made based on
facts and not on uncertain assumptions and predictions.

Early Delivery: The sooner the end product is delivered without

major defects, the sooner feedback can be received, and
incorporated into the next iteration. In the era of rapid technology
evolution, it is not the biggest that survives, but the fastest.
Empowering the team: the managers are taught how to listen to
the developers, so they can explain better what actions might be
taken, as well as provide suggestions for improvements. The lean
approach follows the Agile Principle “build projects around
motivated individuals and trust them to get the job done”.

Building Integrity: The customer needs to have an overall

experience of the System with integrity on how it is being
advertised, delivered, deployed, accessed, how intuitive its use is,
its price and how well it solves problem
Optimize the whole: Defects in software tend to accumulate
during the development process by decomposing the big tasks
into smaller tasks, and by standardizing different stages of
development, the root causes of defects should be found and
eliminated. Modern software systems are not simply the sum of
their parts, but also the product of their interactions.

Lean thinking has to be understood well by all members of a

project, before implementing in a concrete, real-life situation.
“Think big, act small, fail fast; learn rapidly”.
Lesson 05
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.
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 Time Iteration
• 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 tests
• 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 Support
Story Cardboard: This is a traditional way of
collecting all the stories in a board in the form of stick
notes to track daily XP activities. As this manual
activity involves more effort and time, it is better to
switch to an online form.

Online Storyboard: Online tool Storyboard can be

used to store the stories. Several teams can use it for
different purposes.
• Agile Methodology
• Scrum Methodology
• Crystal and DSDM
• FDD and LSD
• Extreme Programming
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
McIntyre, J. (2016). MoSCoW or Kano Models - how do you prioritize?. Retrieved
from, https://www.hotpmo.com/management-models/moscow-kano-prioritize

Moran, A. (2014). Agile Risk Management. ISBN 978-3-319-05008-9: Springer

International Publishing

Mrsic, M. (2017). Crystal Methods. Retrieved from, https://activecollab.com/

blog/project-management/crystal-methods

Plonka, L., et al. (2014). “UX Design in Agile: A DSDM Case Study.” Agile Processes in
Software Engineering and Extreme Programming: Springer International Publishing.
Poppendieck, M., and Poppendieck, T. (2003). Lean Software Development: An Agile
Tool Kit. ISBN 978-0-321-15078-3: Addison-Wesley Professional Press

Pressman, R. S. and Maxim, B. R. (2020). Software Engineering – A Practitioner’s

Approach. 9th Edition, ISBN-13 9781259872976: Mc Graw-Hill Press

Schwanber, K. (2004). Agile Project Management with Scrum. ISBN 978-

0735619937: Microsoft Press

Sommerville, I. F. (2015). Software Engineering. 10th Edition, ISBN-13 978-

0133943030: Pearson Press