Software Engineering

Lecture 4

[These slides are adapted from Software Engineering: A Practitioner’s Approach, Roger S.
Pressman © 2015 & Software Engineering, Ian Somerville © 2015 ]
Agile Development
Lecture Outcomes
• Understanding of:
– the rationale for agile software development methods, the agile manifesto, and the
differences between agile and plan-driven development;
– important agile development practices such as user stories, refactoring, pair
programming and test-first development;
– Scrum approach to agile project management;
– the issues of scaling agile development methods and
combining agile approaches with plan-driven approaches in the
development of large software systems.
 Agile Software Development

Agile is a group of methodologies that

demonstrate a commitment to tight
feedback cycles and continuous
improvement.

4
 Agile Manifesto
• The Agile Manifesto is a foundational document in the field of software
development that outlines a set of guiding values and principles for agile software
development.
• It was created in February 2001 by a group of prominent software developers who
wanted to promote a more flexible and customer-centric approach to software
development.
 Agile Alliance – Agile Manifesto
• The Agile Manifesto is a document that identifies 04 key values and
12 principles that its authors believe software developers should
use to guide their work.

• The developers called themselves the Agile Alliance.

Manifesto: A public declaration of policy and aims

Agile Alliance – Agile Manifesto
The Agile Manifesto
We are uncovering better ways of developing software by doing
it and helping others do it. Through this work we have come to
value:

1. Individuals and interactions over processes and tools

2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

That is, while there is value in the items on the right, we value the
items on the left more.
Agile Manifesto Values
1. Individuals and Interactions over Processes and Tools: This value emphasizes
the importance of people working together and communicating effectively, rather than
relying solely on processes and tools.
2. Working Software over Comprehensive Documentation: Agile development
prioritizes delivering working software that meets customer needs over extensive
documentation that may become outdated quickly.
3. Customer Collaboration over Contract Negotiation: Agile encourages active
collaboration with customers and stakeholders throughout the development process,
rather than relying on rigid contracts and negotiations.
4. Responding to Change over Following a Plan: Agile recognizes that change is
certain in software development and encourages teams to be adaptable and responsive
to changing requirements.
Agility Principles
 Agility Principles
1. Our 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.

10
Agility Principles
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
indefinitely.
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.
12. At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.
 What is “Agility”? ability to move quickly and easily.
• Effective (rapid and adaptive) response to change (team members, new
technology, requirements)
• Effective communication in structure and attitudes among all team members,
technological and business people, software engineers and managers.
• Drawing the customer into the team. Eliminate “us and them” attitude. Planning in
an uncertain world has its limits and plan must be flexible.
• Organizing a team so that it is in control of the work performed.
• Emphasize an incremental delivery strategy

12
 What is “Agility”?
Yielding …
• Rapid, incremental delivery of software
• The development guidelines stress delivery over analysis and design although
these activates are not discouraged, and active and continuous communication
between developers and customers.

13
 Why Agile Development?
• The modern business environment is fast-paced and ever-changing. It represents a
reasonable alternative to conventional software engineering for certain classes of
software projects. It has been demonstrated to deliver successful systems quickly.

14
 Agility and the Cost of Change
• Conventional wisdom is that the cost of change increases nonlinearly as a project
progresses. It is relatively easy to accommodate a change when a team is gathering
requirements early in a project. If there are any changes, the costs of doing this
work are minimal. But if the middle of validation testing, a stakeholder is
requesting a major functional change. Then the change requires a modification to
the architectural design, construction of new components, changes to other
existing components, new testing and so on. Costs escalate quickly.

• A well-designed agile process may “flatten/ smooth” the cost of change curve by
coupling incremental delivery with agile practices such as continuous unit testing
and pair programming. Thus team can accommodate changes late in the software
project without dramatic cost and time impact.

15
 Agility and the Cost of Change

16
 An Agile Process
• Is driven by customer descriptions of what is required (scenarios). Some
assumptions:
– Recognizes that plans are short-lived (some requirements will persist, some will
change. Customer priorities will change)
– Develops software iteratively with a heavy emphasis on construction activities (design
and construction are interleaved)
• Thus has to Adapt as changes occur due to unpredictability
• Delivers multiple ‘software increments’, deliver an operational prototype or
portion of a system to collect customer feedback for adaption / alteration.

17
Agile Process Models
Scrum
• A software development method Originally proposed by Beedle (an activity occurs during a
rugby match) in early 1990.
• Scrum—distinguishing features
– Development work is partitioned into “packets (tasks)”
– Testing and documentation are on-going as the product is constructed
– Work units occurs in “sprints” and is derived from a “backlog” of existing changing prioritized
requirements
– Changes are not introduced in sprints (short term but stable) but in backlog.
– Meetings are very short (15 minutes daily) and sometimes conducted without chairs (what did you do
since last meeting? What obstacles are you encountering? What do you plan to accomplish by next
meeting?)
– “demos” are delivered to the customer with the time-box allocated. May not contain all
functionalities. So customers can evaluate and give feedbacks.
– https://www.thedruckmancompany.com/the-agile-mindset/articleid/18/scrum-rugby-and-teamwork
 Timeboxing Techniquue in
•
Agile
In agile principles, timeboxing allocates a fixed and maximum unit of time to an
activity, called a timebox, within which planned activity takes place.
• Timeboxing simply means that you open your calendar and enter a block of time
that you'll spend on a certain task in the future. Instead of working on the task
until it's done, you proactively decide how much time you'll spend on it and when
(and even where).
 Scrum Sprint Cycle

Backlog: an accumulation of uncompleted work or matters needing to be dealt with.

 Product Backlog
• In Agile development, a product backlog is a prioritized list of deliverables (such
as new features) that should be implemented as part of a project or product
development.
• It's a decision-making artifact that helps you estimate, refine, and prioritize
everything you might sometime in the future want to complete.
An Agile retrospective (dictionary meaning: looking back over the past) is a meeting that's held at
the end of an iteration in Agile software development. During the retrospective, the team reflects on
what happened in the iteration and identifies actions for improvement going forward.
 Burn-down & Burn-up Charts
A burn-down chart shows the amount of work remaining on a project (the
remaining effort), whereas a burn-up chart shows how much work has been
completed and the total scope of the project.
Scrum
Product Backlog
Wish List

Collection of user stories

How to choose?
Direction of project
 The Scrum Sprint Cycle
• Sprints are fixed length, normally 2–4 weeks.
• The starting point for planning is the product backlog, which is the list of
work to be done on the project.
• The selection phase involves all of the project team who work with the
customer to select the features and functionality from the product backlog to
be developed during the sprint.
The Sprint Cycle
• Once these are agreed, the team organize themselves to develop the software.
• During this stage the team is isolated from the customer and the organization, with
all communications channelled through the so-called ‘Scrum master’.
• The role of the Scrum master is to protect the development team from external
distractions.
• At the end of the sprint, the work done is reviewed and presented to stakeholders.
The next sprint cycle then begins.
Scrum Benefits
• The product is broken down into a set of manageable and understandable chunks.
• Unstable requirements do not hold up progress.
• The whole team have visibility of everything and consequently team communication
is improved.
• Customers see on-time delivery of increments and gain feedback on how the product
works.
• Trust between customers and developers is established and a positive culture is
created in which everyone expects the project to succeed.
 Extreme Programming (XP)
• The most widely used agile process, originally proposed by Kent Beck in 2004.
• It uses an object-oriented approach.
– Planning
– Design
– Coding
– Test

32
The Extreme Programming Release Cycle
 XP and agile principles
• Incremental development is supported through small, frequent
system releases.
• Customer involvement means full-time customer engagement with
the team.
• People not process through pair programming, collective ownership
and a process that avoids long working hours.
• Change supported through regular system releases.
• Maintaining simplicity through constant refactoring of code.
 User stories for requirements
✧In XP, a customer or user is part of the XP team and is responsible
for making decisions on requirements.
✧User requirements are expressed as user stories or scenarios.
✧These are written on cards and the development team break them
down into implementation tasks. These tasks are the basis of
schedule and cost estimates.
✧The customer chooses the stories for inclusion in the next release
based on their priorities and the schedule estimates.
 XP Planning
• Begins with the listening, leads to creation of “user stories” that describes required output,
features, and functionality. Customer assigns a value (i.e., a priority) to each story.
• Agile team assesses each story and assigns a cost (development weeks. If more than 3 weeks,
customer asked to split into smaller stories)
• Working together, stories are grouped for a deliverable increment next release.
• A commitment (stories to be included, delivery date and other project matters) is made. Three
ways:
– 1. Either all stories will be implemented in a few weeks, 2. high priority stories first, or 3. the riskiest stories will be
implemented first.
• After the first increment “project velocity”, namely number of stories implemented during the
first release is used to help define subsequent delivery dates for other increments. Customers can
add stories, delete existing stories, change values of an existing story, split stories as
development work proceeds.

36
 User stories for requirements

A user story is the smallest unit of work in an agile framework. It's an end
goal, not a feature, expressed from the software user's perspective. A user
story is an informal, general explanation of a software feature written from the
perspective of the end user or customer.
User Stories

persona + need + purpose.

 User Stories
✧ Example: Examination System User Stories for a Teacher
 User Stories
✧ Example: Examination System User Stories for a Student
XP Design
• Occurs both before and after coding as refactoring is encouraged
– Follows the KIS principle (keep it simple) Nothing more nothing less than the
story.
– For difficult design problems, suggests the creation of “spike solutions”—a design
prototype for that portion is implemented and evaluated.
– Encourages “refactoring”—an iterative refinement of the internal program design.
Does not alter the external behavior yet improve the internal structure. Minimize
chances of bugs. More efficient, easy to read.

– Refactoring is the activity of improving the internal structure or operation of a code or component
without changing its external behavior.
 XP Coding and Testing
• XP Coding
– Recommends the construction of a unit test for a story before coding commences. So implementer can
focus on what must be implemented to pass the test.
– Encourages “pair programming”. Two people work together at one workstation. Real time problem
solving, real time review for quality assurance. Take slightly different roles. Pair programming uses the
four eyes principle, which ensures two sets of eyes review the code that is being produced, even when
there is a division of labor. While the driver writes the code, the navigator checks the code being written.
The driver focuses on the specifics of coding, while the navigator checks the work, code quality and
provides direction.
• XP Testing
– All unit tests are executed daily and ideally should be automated. Regression tests are conducted to test
current and previous components.
– “Acceptance tests” are defined by the customer and executed to assess customer visible functionality

43
 XP Coding and Testing
• https://www.techtarget.com/
searchsoftwarequality/definition/Pair-
programming
Thank you