Software Process

Models
4- Generic software process models & Agile Methods [1]
 Overview of Software Process Models

Waterfall Model

Introduct Incremental Development

ion to
Reuse-based Development
Software
Processe Evolutionary Development

s Formal Systems Development

Spiral Development
Generic Software Process Models

• The waterfall model (DONE)

• Incremental development (DONE)
• Reuse-based development (DONE)
• Other generic models:
• Evolutionary development
• Formal systems development
• Spiral development

3
Evolutionary development

• Objective is to work with customers and to evolve

a final system from an initial outline specification.
• The system evolves by adding new features as
they are proposed by customer. Concurrent
activities
Specification,
development, and Initial
Specification
validation are version

interleaved rather
than separate, with Outline
Development
Intermediate
description versions
rapid feedback
across activities.
Final
Validation
version

4
Evolutionary development (cont.)

• Particularly suitable where:

- detailed requirements not possible;
- powerful development tools (e.g. GUI)
available
• Problems
• Lack of process visibility
• Systems are often poorly structured
• Special skills (e.g. in languages for rapid
prototyping) may be required

5
 Formal systems development

• Based on the transformation of a mathematical

specification through different representations to an
executable program
• Embodied in the ‘Cleanroom’ approach (which was originally developed
by IBM) to software development

Requirements Formal Formal Integration and

definition specification transformation system testing

• Applicability
• Critical systems especially those where a safety or security
case must be made before the system is put into operation
6
Formal systems development

• Problems
• Need for specialised skills and training to apply
the technique
• Difficult to formally specify some aspects of the
system such as the user interface

7
Spiral development
• Process is represented as a spiral rather than as a
sequence of activities with backtracking
Determine objectives
Evaluate alternatives
alternatives and identify, resolve risks
constraints Risk
analysis
Risk
analysis
Risk
analysis Opera-
Prototype 3 tional
Prototype 2 protoype
Risk
REVIEW analysis Proto-
type 1
Requirements plan Simulations, models, benchmarks
Life-cycle plan Concept of
Operation S/W
requirements Product
design Detailed
Requirement design
Development
plan validation Code
Design Unit test
Integration
and test plan V&V Integr ation
Plan next phase test
Acceptance
Service test Develop, verify
next-level product
8
Spiral development (cont.)

• Each loop in the spiral represents a phase in the process.

• No fixed phases such as specification or design - loops in
the spiral are chosen depending on what is required
• Risks are explicitly assessed and resolved throughout the
process

• Spiral model sectors:

• Objective setting: Specific objectives for the phase are identified
• Risk assessment and reduction: Risks are assessed and
activities put in place to reduce the key risks
• Development and validation: A development model for the
system is chosen which can be any of the generic models
• Planning: The project is reviewed and the next phase of the spiral
is planned
9
 • Introduction to Agile Software
Development​
The • Problems with traditional models
(e.g., Waterfall)
Need for • The rise of Agile to address these
problems

Agile • Agile Manifesto and its significance​

(4- Generic Software Pro…)
Agile Software Development
Agile software development is a conceptual framework for
software engineering that promotes development iterations
throughout the life-cycle of the project.

Software developed during one unit of time is referred to as an

iteration, which may last from one to four weeks.

Agile methods also emphasize working software as the primary

measure of progress
Agile Software Development: Intro
Characteristics of Agile Software Development
-- Light Weighted methodology
-- Small to medium sized teams
-- vague and/or changing requirements
-- vague and/or changing techniques
-- Simple design
-- Minimal system into production
Rapid software development
Why?
 Need to react to changes more quickly than 2 year long waterfall projects
 2 years and then you got the design wrong anyway! Small deliveries aren't
abstract
How?
 Goal - Deliver working software quickly
• Compromise - less functionality in a delivery, not lower quality
• Less documentation
 Focus on the code rather than the design
 Interleave
• Specification, design and implementation are inter-leaved
 Deliver small versions and get user (stakeholder) input

Chapter 3 Agile software development 14

 Ouch!

s
es
en
siv
on
sp
Re e
od
C
tle it
Br
Copyright © 2010 AgileInnovation
ty
ali
Qu
Your Favorite!
Transparency
im es
Cy cle T
Long
ty
plexi
Com
ity
uctiv
Prod
points
Pain
Agile manifesto
Our values:
 Individuals and interactions over processes and tools
 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 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.

Chapter 3 Agile software development 16

3. Agile • The Agile Manifesto and its 12 Principles​
• Emphasizing customer collaboration,

Principle responsiveness to change, and

sustainable development

s and
• Understanding Agility​
• Effective communication, rapid
delivery, and adaptability
Methods
The Manifesto for Agile Software
Development
Background:

In 2001, seventeen software

developers met at a resort in
Snowbird, Utah to discuss the
lightweight development
methods.

Together they published the

Manifesto for Agile Software
Development.

https://agilemanifesto.org

18
The Manifesto for Agile Software
Development

https://agilemanifesto.org

19
 Twelve Principles of Agile
Software
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.

20
Twelve Principles of Agile Software
(cont.)
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.

21
 What is “Agility”?

• Effective (rapid and adaptive)

response to change.
• Effective communication among all
stakeholders.
• Drawing the customer onto the
team.
• Organizing a team so that it is in
control of the work performed.

Yielding …
• Rapid, incremental delivery of
software. 22
Why and What Steps are “Agility”
important?

• Why? 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.

• What? The basic activities:

• Communication, planning, modeling, construction and
deployment remain. But they morph into a minimal task set
that push the team toward construction and delivery sooner.

23
 Agility and the Cost of Change

• Accommodate changes late in the software project without dramatic cost and time impact.

24
 • Overview of Agile Methods​
4. Agile • Extreme Programming (XP): An
example of Agile in action
Methodolo • Scrum: A popular Agile framework
gies • Comparing Agile with Plan-driven
Approaches​
Extreme programming
A popular form of Agile
 Extreme Programming (XP) takes an ‘extreme’ approach to iterative development.
 New versions may be built several times per day;
 Increments are delivered to customers every 2 weeks;
 All tests must be run for every build and the build is only accepted if tests run successfully.
 Customer involvement means full-time customer engagement with the team. - Specifications through user
stories broken into tasks
 People not process : pair programming, collective ownership and a process that avoids long
working hours.
 Regular system releases. - release set of user stories
 Maintaining simplicity through constant refactoring of code.

Chapter 3 Agile software development 26

The extreme programming release cycle

Chapter 3 Agile software development 27

The Parts and the Whole
• Iteration
Plan
• Daily Stand-
Up

Set
Adapt Controller
Target

• Clean Design & Code &

Refactor Inspect
• User Stories - Late
Elaboration
• Shared Code Ownership • Pair Programming
• Test Driven • Customer Reviews
Development….. & Feedback
• Retrospectives
Sustainable pace • AutoTest…..
Collective Ownership with users
Minimal documentation for sprint
The Life of an Iteration

Copyright © 2010 AgileInnovation

Transparency

“Tell me how you will measure

me and I’ll tell you how I’ll
behave”

Copyright © 2010 AgileInnovation

A ‘prescribing medication’ story

Chapter 3 Agile software development 31

Examples of task cards for prescribing
medication

Chapter 3 Agile software development 32

Refactoring
Programming team look for possible software improvements and make these
improvements even where there is no immediate need for them.
This improves the understandability of the software and so reduces the need for
documentation.
Changes are easier to make because the code is well-structured and clear.
However, some changes requires architecture refactoring and this is much more
expensive.
RISK:
Changes the user does not test
Changes to working software break it

Chapter 3 Agile software development 34

Examples of refactoring
Re-organization of a class hierarchy to remove duplicate code.
Tidying up and renaming attributes and methods to make them
easier to understand.
The replacement of inline code with calls to methods that have
been included in a program library.

Chapter 3 Agile software development 35

Test case description for dose checking

Chapter 3 Agile software development 36

Test automation
Automate tests (junit)
Run upon checkin
Difficulties:
Time constraints
Programmer preferences to not test
Test coverage

Chapter 3 Agile software development 37

Pair programming
In XP, programmers work in pairs, sitting together to develop
code.
Common ownership
Knowledge spread
Informal review
Refactoring
Similar output to two people coding

Chapter 3 Agile software development 38

Scrum
Project Manager's job: - Deliver needed system on time within
budget
The Scrum approach - manage the iterations
There are three phases in Scrum.
 outline planning phase - general picture and architecture
 Sprint cycles releasing increments of the system.
 The project closure phase - final delivery, documentation and review of
lessons learned.

Chapter 3 Agile software development 39

The Scrum process

Chapter 3 Agile software development 40

The Sprint cycle
Every 2–4 weeks (a fixed length).
1) Project team with customer: Look at product backlog - select
stories to implement
2) implement with all customer communication through scrum
master (protecting pgmr at this point)
Scrum master has project manager role during sprint
Daily 15 min meetings
Stand up often
Team presents progress and impediments
Scrum master tasked with removing impediments
3) Review system release with user
Chapter 3 Agile software development 41
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.
Chapter 3 Agile software development 42
 Balance plan driven and agile
• Not great for Agile:
• What type of system is being developed?
• Plan-driven approaches may be required for systems that require a lot of analysis before
implementation (e.g. real-time system with complex timing requirements).
• What is the expected system lifetime?
• Long-lifetime systems may require more design documentation to communicate the original
intentions of the system developers to the support team.
• What technologies are available to support system development?
• Agile methods rely on good tools to keep track of an evolving design
• How is the development team organized?
• Many teams; Outsourcing ---> need design documents to control borders
 Culture or contract needs detailed specification
 Is rapid feedback from users realistic?
 Large scale, not co-located may require more formal communication methods
 Need high level programming skills - refactoring, work with little spec
 Outside regulation documentation requirements

Chapter 3 Agile software development 43

 • Introduction to Scrum​
• Scrum Roles: Product Owner, Scrum
5. Master, Development Team
• Scrum Artifacts: Product Backlog,
Scrum Sprint Backlog, Increment
• Scrum Ceremonies: Sprint Planning,
Framew Daily Scrum, Sprint Review, Sprint
Retrospective

ork in • Scrum Sprints​

• Timeboxing and Iterative

Detail Development
• The Sprint Cycle and its Activities
Scrum
• Scrum is easy to understand, but can be difficult to
master

• Scrum uses a methodology called the scrum framework.

• The scrum framework is a set of practices, roles and

responsibilities, events, artifacts, and rules

45
46
Scrum Sprints
• Timebox iteration for project work
• A timebox is a predetermined duration
• Scrum sprints are between one and four weeks in
duration
• During a sprint no changes are made that would affect
the goal of the sprint
• A sprint can be cancelled if they change in the project
goals make the sprint goals obsolete
• Only the product owner may cancel a sprint

47
More About Scrum Sprints
• If a sprint is cancelled, uncompleted backlog items are
returned to the product backlog

• Within a sprint there are several activities:

• Sprint planning meeting
• Development
• Daily scrums
• Sprint review meeting
• Sprint retrospective meeting

48
Scrum Artifact – Product Backlog
• The product backlog is the source for all product requirements
• The product owner sorts and prioritizes the backlog items
• The development team always works on the most important items
based on the prioritized items in the product backlog
• The backlog is always prioritized before the current sprint
• Backlog refinement is done by both the product owner and the
development team working in harmony
• The team estimates their capacity to attack the items in the product
backlog

49
Scrum Artifacts – Sprint Backlog
• Sprint backlog is a subset of the product backlog
• Sprint backlog serves as the goal for the current
iteration
• Sprint backlog is a view into the work to be
accomplished in the current sprint
• Sprint backlog is updated and refined by the
development team

50
Scrum Artifact – Product Increment
• The product increment is the outcome of an Iteration

• The product increment is a chunk of the project work

• The development team and the product owner must be

in agreement of what done means for an increment

51
Scrum Team Roles
• Scrum Master – responsible for communicating the scrum methodology
and ensuring the methodology is used effectively

• Product owner – prioritizes the product backlog to ensure value from

each sprint
• Guide the direction of the product
• Rank the work based on its business value
• Provide feedback
• Set direction on next deliverable

• Development team – the software developers who create the product

through the sprint

52
53
Looking At The Scrum Activities
• Scrum activities are also known as events or
ceremonies

• There are five scrum ceremonies:

• Product backlog refinement
• Sprint planning meetings
• Daily scrum
• Sprint reviews
• Sprint retrospective

54
Grooming the Backlog
• Backlog refinement (formerly known as backlog
grooming): the product owner and some, or all, of the
rest of the team review items on the backlog to ensure
the backlog contains the appropriate items, that they
are prioritized, and that the items at the top of the
backlog are ready for delivery
• The product owner owns the backlog
• Backlog refinement is the prioritization backlog items
• The entire project team may participate in the backlog
grooming

55
Sprint Planning Meeting
• Project team needs to discuss the goals of the upcoming
sprint
• Team discusses how the work will be accomplished
• Product owner reviews with team items in the updated
backlog
• Development team defines how the work will be done in
the goals of the sprint will be achieved
• The development team is self-organized

56
Participating In a Daily Scrum
• The daily scrum is also known as a stand-up meeting
• This is a 15-minute time-boxed meeting
• The daily scrum is held every day at the same time and
location
• The daily scrum is for the development team only

• Daily Scrum Meeting Questions:

• What have I done since the last daily scrum?
• What do I plan to do today?
• Are there any impediments to my progress?
57
Working With Large Scrum Teams
• Scrum of scrums
• Scrum of scrums of scrums

• Four questions are answered:

• What has your team done since we last met?
• What will your team do before our next meeting?
• Are there any roadblocks in your team’s way?
• Will your team put anything in another team’s way?

58
Sprint Reviews
• Hosted at the end of every sprint
• Attendees will be the development team, the product
owner, scrum master, and sometimes other project
stakeholders
• Development team will demo the work created in the
increment
• The group will decide if “Done” has been achieved
• The development team and the product owner will
discuss the sprint and the remaining items in the
product backlog
59
Sprint Retrospective
• The development team meeting posted after the sprint
review, but before the next sprint planning meeting
• This is a meeting to inspect an adapt
• Lessons learned and opportunities for improvement
• Review of the product owner’s feedback about the last
iteration
• An opportunity to improve on their approach based on
the retrospective and the last sprint

60
7.
Balancin • When to Use Agile vs. Plan-driven
g Agile Methods​

and Plan-
• Contexts where Agile is most effective
• Situations where Plan-driven approaches

Driven are necessary

Approach
es
Balance plan driven and agile
• Not great for Agile:
• What type of system is being developed?
• Plan-driven approaches may be required for systems that require a lot of analysis before
implementation (e.g. real-time system with complex timing requirements).
• What is the expected system lifetime?
• Long-lifetime systems may require more design documentation to communicate the original
intentions of the system developers to the support team.
• What technologies are available to support system development?
• Agile methods rely on good tools to keep track of an evolving design
• How is the development team organized?
• Many teams; Outsourcing ---> need design documents to control borders
 Culture or contract needs detailed specification
 Is rapid feedback from users realistic?
 Large scale, not co-located may require more formal communication methods
 Need high level programming skills - refactoring, work with little spec
 Outside regulation documentation requirements

Chapter 3 Agile software development 62

8.
Challenges • Common Issues with Agile Adoption
in Agile • Scaling Agile, maintaining simplicity, and
handling documentation
Implementa
tion
Problems with agile methods
 It can be difficult to keep the interest of customers / users who are involved in the process.
 Team members may be unsuited to the intense involvement that characterizes agile methods.
 Prioritizing changes can be difficult where there are multiple stakeholders.
 Maintaining simplicity requires extra work.
 Contracts may be a problem as with other approaches to iterative development.
 Because of their focus on small, tightly-integrated teams, there are problems in scaling agile
methods to large systems.
 Less emphasis on documentation - harder to maintain when you get a new team for maintenance

Chapter 3 Agile software development 64

9.
Summar • Recap of Key Points

y and • The Future of Agile in Software

Development

Conclusi
on