Software

Development
Models
Methodologies for Organizing the Software
Development Process

Software Quality
Assurance
Telerik Software Academy
http://academy.telerik.com
 The Lectors
 Snejina Lazarova
Project Manager
BI & Reporting Team

 Dimo Mitev
QA Architect
Backend Services Team

2
 Table of Contents
 Software Development Models
 The Waterfall Development Process
 V-model (Sequential Development
Model)
 Iterative-incremental Development
Models
 Agile Development
 Extreme Programing
 Test Driven Development
 Scrum
3
 What is a Development
Model?
 A development model
(methodology) is a set of practices
and procedures for organizing the
software development process
 A set of rules that developers have
to follow
 A set of conventions the
organization decides to follow
 A systematical, engineering
approach for organizing and 4
 Software Development
Lifecycle Stages
 Documentation of user
requirements
 Designing a software product
 Implementing the software product
 Testing the software solution
 Deployment of the solution
 Maintenance of the product

5
The Waterfall
Development
Process
 The Waterfall Process
 The waterfall development
process
Software
Requireme
nts
Softwa
re
Design
Implementa
tion
(Coding)
Verificat
ion
(Testing)
Operation
(Maintena
nce)
 The Waterfall Model
 The first fundamental model was the
Waterfall model
 Impressively simple and very well
known
 Only when one development level is
completed will be initiated the next
one
 Only between adjacent levels are
there feedback loops and revisions of
the previous level
 Emphasis is on documentation
8
 V-model
(Sequential Development Model)
 The General V-model
 The model presents two branches
 Development tasks
 The process of design and
implementation
 Testing tasks
 Verification and integration into
bigger subsystems
 Both are corresponding activities
of equal importance

10
 The V-model Scheme
Requirements Acceptance
definition test

Functional System
system design test

Technical system Integration

design test

Component Component
design test

Implementation & Programming Verification &

Integration Validation 11
 Development Tasks
1.Requirements specification
 Specifying customer requirements
 Defining the system’s purpose,
characteristics and features
2.Functional system design
 Mapping functions and dialogues of
the new system

12
 Development Tasks (2)
3.Technical system design
 Designing the implementation of
the system
 Defining interfaces to the system
environment
 Decomposing the system into
smaller understandable subsystems
 System architecture

13
 Development Tasks (3)
4.Component specification
 Defining each subsystem
 Task, behavior, inner structure,
interfaces
5.Programming
 Implementing each specified
component in a programming
language
 Modules, units, classes

14
 Testing Tasks
1.Component (unit) test
 Verifies each software component
 Does it perform correctly
 According to its specification
2.Integration test
 Checks groups of components
 Do they collaborate correctly
 According to the technical system
design
15
 Testing Tasks (2)
3.System test
 Verifies the system as a whole
 Does it meet the specified system
requirements
4.Acceptance test
 Does the system meet the customer
requirements

16
 Levels of Abstraction
 Testing follows the levels of
abstraction of development
 The easiest way to find mistakes
 Look for them on the same level of
abstraction
 On which they are produced
 Testing is performed in parallel with
development

17
 Validation and
Verification
 Are we building the right system?
 Does the product (or a part of it)
solve its task?
 Is this product suitable for its
intended use?
 Are we building the system right?
 Does the product meet its
specification?
 Has it been achieved correctly and
completely
18
Iterative-incremental
Development Models
 Iterative and
Incremental
Development
 The basic idea behind these
methods:
 Develop a system through repeated
cycles (iterative)
 Smaller portions at a time/cycle
(incremental)
 Learn during development of
previous parts or versions of the
system
 Plan-do-check-act cycle
20
 Advantages
 Produces business value early in
the development life cycle
 Verification and validation
 Can be carried out on each
increment
 Take advantage of what was learnt
 Product update at each iteration

21
 Disadvantages
 Tempts you to start coding before
you have a clear idea of what you
want to do
 Requires more customer
involvement than the linear
approaches
 Partitioning the functions and
features might be problematic
 Regression testing
 Increasingly important on
22
 Initialization Step
 Creating a base version of the
system
 Create a product to which the user
can react
 Sampling of the key aspects of the
problem
 Solution that is simple enough to
understand and implement easily

23
 Iteration Step (2)
 Iteration step involves:
 Design and implementation of a
task from the project control list
 Analysis of the current version of
the system
 Analysis of the structure,
modularity, usability, reliability,
efficiency & achievement of goals
 Iteration analysis is based upon
user feedback, and the program
analysis facilities available 24
 Project Control List
 Project control list
 Created to guide the iteration
process
 Contains a record of all tasks that
need to be performed
 New features to be implemented
 Areas of redesign of the existing
solution
 Constantly revised as a result of the
analysis phase
25
 Iterative-incremental
Models Examples
 Examples for Iterative-incremental
models
 Agile Development
 Rapid Application Development
(RAD)
 Rational Unified Process (RUP)

26
Agile Development
 What is Agile
Development?
 What is agile development?
 A group of software development
methodologies based on iterative
and incremental development
 Requirements and solutions evolve
through collaboration between self-
organizing, cross-functional teams
 The new name of lightweight
models
 After the Agile Manifesto published in
2001
28
 The Agile Manifesto

“Our highest priority is to

satisfy the
customer through early and
continuous
Manifesto
delivery of valuable for Agile
software“
 The Agile Manifesto
 The four core values of Agile software
development
Individuals
Processes and
and over tools
interactions

Comprehensiv
Working
over e
software
documentation

Customer over Contract

collaboration negotiation

Responding to over Following a

change plan
 Agile Manifesto
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, at intervals of
between a few weeks to a few months, with a
preference to the shorter timescale
4. Build projects around motivated individuals. Give
them the environment and support they need, and
trust them to get the job done
5. The most efficient and effective method of conveying
information to and within a development team is
face-to-face conversation.
 Agile Manifesto
Principles (2)
7. Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely
8. Business people and developers must work together
daily throughout the project.
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
 Agile Characteristics
 Tasks are being broken into small
increments with minimal planning
 Do not directly involve long-term
planning
 Iterations are short time frames
(time boxes)
 Typically last one to four weeks
 Each iteration involves a team
working through a full software
development cycle
33
 Agile Characteristics
(2)
 Available release (with minimal
bugs) at the end of each iteration
 Teams are usually
 Cross-functional
 Self-organizing
 Team members take initiative and
responsibility

34
 Agile Characteristics
(3)
 Face-to-face communication over
written documents
 Most agile teams work in a single
open office (called a bullpen)
 Team size is typically small (5-9
people)
 Videoconferencing, voice, e-mail,
etc. for teams not in the same
location

35
 Agile Characteristics
(4)
 Agile
teams contain a customer
representative
 Answers mid-iteration problem-
domain questions
 At the end of each iteration
participates in reviewing progress
and re-evaluating priorities
 Routine and formal daily
face-to-face debrief
meetings among team
members 36
 Agile Methodologies
 eXtreme Programming (XP)
 Scrum
 Kanban
 Lean
 Crystal family of methodologies
 Adaptive Software Development
(ASD)
 Dynamic System Development Model
(DSDM)
 Extreme
Programming
 Extreme Programming
 Extreme Programming (XP)
 A type of agile software
development
 Intended to improve software
quality and responsiveness to
changing customer requirements
 Advocates frequent "releases" in
short development cycles (time
boxes)
 Intended to improve productivity
 Checkpoints where new customer 39
 Extreme Programming
(2)
 In the early 2000s, XP was the most
well-know agile method
 Today many of its practice have
become mainstream
 Many XP practices are used in most
other agile methods
 Sometimes explicitly, but often as a
matter of course
 So the relevance of known XP is as
high as it was
40
 XP basic values
 XP's set of rules and practices is
based on five fundamental ideas
(called "values")
 Communication
 Simplicity
 Feedback
 Courage
 Respect
 XP basic values (2)
 Communication
 Many problems in projects are
related to communication that
failed or simply did not happen
 Everyone is part of the team and
communicates face to face daily
 Practices that create
communication:
 Pair programming
 Informative workspace
42
 XP basic values (3)
 Simplicity
 XP requires to always use the
simplest solution that is sufficient
for today's requirements
 and not build something more
complicated in the hope that it will
be needed later
 Slogan: “You Ain't Gonna Need It!“
(YAGNI)

43
 XP basic values (4)
 Feedback
 XP integrates concrete and
immediate feedback into the
process wherever possible
 Immediate effort estimation for each
story card
 Unit tests for each piece of code
 Continuous integration
 Short iterations and frequent
releases
44
 XP basic values (5)
 Courage
 We will tell the truth about progress
and estimates
 XP creates an infrastructure that
allows to be courageous or even
bold
 in particular with automated testing
and continuous integration
 Respect
 Everyone gives and feels the
45
 Planning / Feedback
Loops
 Planning and feedback loops in
Extreme Programming

46
Extreme Programming:
The 13 Key Practices
 Test Driven
Development
Tests First – Code Later
 The Test Driven
Development Cycle
 Test-driven development (TDD)
relies on the repetition of a very
short cycle:
a)Write a failing automated test case
 Defines a desired improvement or
new function
b)Produce code to pass that test
c)Finally refactor the new code to
acceptable standards

49
 Development Cycle

Add a test
[Pass
]
Run the tests
[Developm
[Fai ent
l]
Write code/Refactor continues]
[Fai
l]
Run the tests

[Development
stops]
 Advantages of TDD
 TDD shortens the programming
feedback loop
 TDD provides detailed specification
(tests)
 TDD promotes the development of
high-quality code
 TDD provides concrete evidence
that
your software works
 TDD helps to ensure that your
design is clean by focusing on 51
 Disadvantages of TDD
 Big time investment. For the
simple case you lose about 20% of
the actual implementation, but for
complicated cases you lose much
more
 Additional Complexity. For complex
cases your test cases are harder to
write
 Design Impacts. Sometimes the
design is not clear at the start
and evolves as you go along – 52
 Why Write the Test
Before the Code?
 Think through the requirement
 Think about the design and
usability of the API
 There’s never time to write it
afterwards
 You write much less tests (if at all)
otherwise

53
 Why Make it Fail First?
 Make sure the test does not have a
bug
 Make sure you’re testing the right
thing
 When the test passes, you are
done
 If you can’t write that test, than
maybe you:
 Do not understand the requirement
 Have over designed things (not
54
 Why Refactor?
 Constantly improve the design of
the code
 Remove duplication, improve
readability and maintainability
 You’ll need to when things change
 Requirements, your understanding
of them, other factors…

55
 Scrum
Making Progress in Series of Sprints
 Scrum

A framework within which people can

address complex problems, and
productively and creative delivery
products of the highest possible value
 Scrum is:
 One of the agile approaches
 Lightweight
 Extremely simple to understand
 Extremely difficult to master
57
 Scrum (2)
 Scrum is an iterative incremental
framework for managing complex
projects

 An agile process that allows us to

focus on delivering the highest
business value in the shortest time
 It allows us to rapidly and
repeatedly inspect actual working
software (every two weeks to one
month) 58
 Scrum (3)
 The business sets the priorities
 Teams self-organize to determine
the best way to deliver the highest
priority features
 Everytwo weeks to a month
anyone can see real working
software
 And decide to release it as is or
continue to enhance it for another
sprint
59
 Scrum (4)

Roles Artifacts Events

Product Increment Sprint
Owner Product Spring
Developm Backlog Planning
ent Team Sprint Daily
Scrum Backlog Scrum
Master Sprint
Review
Retrospec
tive
 Pigs and Chickens
 Scrum teams consist of three core
roles and a range of ancillary roles
 Core roles are often referred to as
pigs
 They are fully committed to the
project
 Ancillary roles are referred as
chickens
 No formal role and infrequent
involvement
 Came into being after the story The 61
 Scrum Roles

Product
Owner

Developme
nt Team Scrum
Team

Scrum
Master
 Scrum Core Roles
 The core roles in Scrum teams are
those committed to the project in
the Scrum process
 They are the ones producing the
product (objective of the project)
 Scrum core roles:
 Scrum Master – maintains the
Scrum processes
 Product Owner – represents the
stakeholders
 Team – a group of about 7 people 63
 The Scrum Master
 Scrum is facilitated by a Scrum
Master
 The Scrum Master is not the team
leader
 Acts as a buffer between the team
and any distracting influences

64
 The Scrum Master (2)
 Accountable for removing
impediments
 Enforcer of rules
 Protects the team and keep them
focused on the tasks in hand
 Also referred to as servant-leader

65
 The Team
 The Team is responsible for
delivering the product
 Typically made up of 5–9 people
 Team members have cross-
functional skills
 The team does the actual work
 Analyze, design, develop,
test, technical communication,
document, etc.

66
 The Team (2)
 Membership should change only
between sprints
 It is recommended that the Team
be self-organizing and self-led
 Although often works with
some form of project or team
management

67
 The Product Owner
 The Product Owner represents the
voice of the customer
 He is accountable for ensuring that
the Team delivers value to the
business
 Writes customer-centric items
(typically user stories)
 Prioritizes them, and adds them
to the product backlog

68
 The Product Owner (2)
 Accepts or rejects work results
 Scrum teams should have one
Product Owner
 The product owner also can be a
member of the Development Team
 It is not recommended this role to
be combined with that of Scrum
Master

69
 Scrum Ancillary Roles
 Stakeholders (customers, vendors)
 The people who enable the project
 For them the project will produce
the agreed-upon benefits, which
justify its production
 Directly involved only in the process
during the sprint reviews

70
 Scrum Ancillary Roles
(2)
 Managers (including Project
Managers)
 People who will set up the
environment for product development
 Responsible for keeping the product
vision clear
 Help for day-to-day problems resolving
(out of Team scope)
 Provide tools instead of solutions
 Often the Scrum Master and the
Manager are one and same person 71
The Scrum Process
Framework

72
 Scrum Terminology
 Sprint/Iteration
 An iteration in the
Scrum development
 Usually two to four weeks
 Backlog
 All features that have to be
developed represented in User
Story format
 Burn down chart (Release and
Sprint)
73
 Product Backlog
 A high-level list with broad
descriptions of all potential
features for the product (backlog
items)
 Maintained throughout the entire
project
 Prioritized by the product owner
 Open and editable
The product
 In terms of years
backlog

74
 A Sample Product
Backlog
Estima
Backlog item
te
Allow a guest to make a
3
reservation
As a guest, I want to cancel a
5
reservation.
As a guest, I want to change
3
the dates of a reservation.
As a hotel employee, I can
run RevPAR reports (revenue- 8
per-available-room)
Improve exception handling 8
75
 Release Backlog
 Limited set of items from the
Product Backlog that should be
developed for a given release
 Focused to specific goals identified
for a specific time-frame
 Reprioritized by the product owner
 All items estimated at high level
(story points)
 In terms of months

76
 Sprint Backlog
 The list of work the team must
address during the next sprint
 Features are broken down into
tasks
 Between four and sixteen hours of
work
 Tasks on the sprint backlog are
never assigned
 In terms
The sprintof weeks
backlog

77
 Sprint Backlog (2)
 Often an accompanying task board
is used to see and change the state
of the tasks
 Labels are used like “to do”, “in
progress” and “done”

78
 A Sample Sprint
Backlog

Day Day Day Day Day

Backlog item Status
1 2 3 4 5
Code the user Complet
20 10 0 0 0
interface ed
Code the Not
8 8 8 8 8
middle tier Started
Test the middle In
24 20 30 25 20
tier Progress
Write online Complet
12 12 12 12 0
help ed
Write the foo Complet
12 0 0 0 0
class ed
Add error Not
8 8 8 8 8
logging Started
79
 Sprint Burn Down Chart
 The sprint burn down chart is a
publicly displayed chart
 Shows remaining work in the sprint
backlog
 Updated every day, it gives a
simple view of the sprint progress

80
A Sample Burn Down
Chart

81
 Bug Backlog
 A type of backlog which includes
bugs only
 Can be part of the Product Backlog
 Bugs are listed by their priority
 Includes bugs reported by
customers
 Bugs are prioritized by Product
Owner (may be supported by QA
lead)
82
 Team Backlog
 Created by the Team
 Represents leftover work that
team should do
 It’s a list of “want to do”, and not
a commitment
 Items can be estimated
(preferable) or not
 It has a single owner – the team’s
Product Owner
83
 Scrum Practices
 Sprint Planning Meeting
 At the beginning of the sprint cycle
 Establish the Sprint backlog
 Daily Scrum stand-up meeting
 Each day during the sprint
 Timeboxed to 15 minutes
 Sprint Review Meeting
 Review the work completed / not
completed
 Sprint Retrospective 84
 Sprint Planning
Meeting
 Held at the beginning of the sprint
cycle (every 7-30 days)
 Team selects items from the
product backlog they can commit
to completing
 Sprint backlog is created
 Tasks are identified and each is
estimated (1-16 hours)
 Done collaboratively
 Not alone by the Scrum Master
85
 Sprint Planning
Meeting (2)
 Eight hour time limit (for a 4 week
Sprint)
 (1st four hours) Product Owner +
Team:
 Dialog for prioritizing the Product
Backlog
 (2nd four hours)Code
Team only:
the middle tier (8
hours)
hours)
As a vacation
 Hashing out
planner, I want
a plan
Code for the
the user Sprint,
interface (4)
Write test fixtures (4)
toresulting
see photosin the Sprint Backlog
Code the foo class (6)
of the hotels
Update performance tests
(4)
86
 The Daily Scrum
 Held each day during the sprint
 Also called the daily standup
 This meeting has specific
guidelines:
 The meeting starts precisely on
time
 All are welcome, but normally only
the core roles speak
 The meeting is time-boxed to 15
minutes
 87
 The Daily Scrum (2)
 Everyone answers 3 questions
1
What did you do yesterday?

2
What will you do today?

3
Is anything in your way?

88
 The Daily Scrum (3)
 The Scrum meeting helps avoiding
other unnecessary meetings
 If a problem needs discussion – this
can be done after the meeting

89
 Sprint Review/Demo
Meeting
 Review the work that was
completed and not completed
 Present the completed work to the
stakeholders (a.k.a. “the demo”)
 New features or underlying
architecture
 Incomplete work cannot be
demonstrated
 2-hour preparation time rule
 No slides
90
 Sprint Retrospective
 All team members reflect on the
past sprint
 Make continuous process
improvements
 Two main questions are asked
 What went well during the sprint?
 What could be improved in the next
sprint?
 Three hour time limit for a 4 week
Sprint
91
 User Story
 In Agile development, user stories are
written to capture requirements from
the perspectives of developers, testers,
and business representatives
 A user story, as a written
representation, has the following
structure
As a [user role], (WHO)
I want to [goal], (WHAT)
so I can [reason] (WHY)
 Estimating Software
Development
Estimation is often
expensive

Accura
cy

Effort of
Time
 Story Points
 Very common way to estimate
work
 Based on size, effort and
complexity, not duration
 Unitless and numerically
relative
 Different for each team of
estimators
 Points are additive
 Based on historical reality
 Story Points (2)
 Using Story Points
Product
We can see right away Backlog
Cost: 13
1. Which work items cost the most
Cost: 20
Cost: 20
2. Total cost of all the work Cost: 3
Cost: 5
3. Total cost to an iteration
Cost: 1
Cost: 8
Cost: 13
Defect
Requireme Cost: 3
nt Cost: 100
Constraint Cost: 13
Planning Poker
 Planning Poker Rules
 Each estimator has a deck of estimation
cards
 Values similar to the Fibonacci sequence
(0, 1, 2, 3, 5, 8, 13, 21, 34, 55…)
 Customer/Product Owner reads a story
and it’s discussed briefly
 Each estimator selects a card that’s his
or her estimate
 Cards are turned over so all can see
them (synchronously)
 Discuss differences (especially outliers)
 Who Uses Scrum?
 Telerik  IBM
 Microsoft  BBC
 Yahoo  Etc.
 Google
 Electronic Arts
 Lockheed Martin
 Philips
 Siemens
 Nokia
98
 Software Development
Models
?

?
?
?
Questions
?

?
?
?
?
? ?
 Free Trainings @ Telerik
Academy
 C# Programming @ Telerik
Academy
 csharpfundamentals.telerik.com
 Telerik Software Academy
 academy.telerik.com
 Telerik Academy @ Facebook
 facebook.com/TelerikAcademy
 Telerik Software Academy Forums
 forums.academy.telerik.com