Lecture 4
AGILE AND OTHER METHODS
PB007 Software Engineering I
Faculty of Informatics, Masaryk University
Fall 2020
1© Barbora Bühnová
Outline
 Software Process Models
 Agile Development
 Agile Practices
 Agile Methods
 UML State diagram
2© Barbora Bühnová
Software Process Models
Lecture 4/Part 1
3Chapter 22 Project management
Software process models
Chapter 2 Software Processes 4
Agile
Early SCRUM
Agile Manifesto
Spiral
Software process models
 The waterfall model
▪ Plan-driven model. Separate and distinct phases of specification
and development.
 Incremental development
▪ Specification, development and validation are interleaved. May
be plan-driven or agile.
 Reuse-oriented software engineering
▪ The system is assembled from existing components. May be
plan-driven or agile.
 In practice, most large systems are developed using a
process that incorporates elements from many different
models.
Chapter 2 Software Processes 5
Plan-driven and agile development
 Plan-driven development
▪ A plan-driven approach to software engineering is based around
separate development stages with the outputs to be produced
at each of these stages planned in advance.
▪ Not necessarily waterfall model – plan-driven, incremental
development is possible
 Agile development
▪ Specification, design, implementation and testing are interleaved
and the outputs from the development process are
decided through a process of negotiation during the software
development process.
6Chapter 3 Agile software development
The waterfall model
Chapter 2 Software Processes 7
Waterfall model benefits and problems
 The waterfall model is mostly used for large system
engineering projects where a system is developed at
several sites.
▪ In those circumstances, the plan-driven nature of the waterfall
model helps coordinate the work.
 Suitable for new versions of generic products.
▪ Well understood context, stable requirements.
 The process makes it difficult to respond to changing
customer requirements.
▪ Therefore, this model is only appropriate when the requirements
are well-understood and changes can be limited.
Chapter 2 Software Processes 8
Software prototyping
 A prototype is an initial version of a system used to
demonstrate concepts and try out design options.
 A prototype can be used in:
▪ The requirements engineering process to help with
requirements elicitation, consistency checking and validation;
▪ In design processes to explore design options and develop a
UI design;
 Prototypes often have poor internal structure and thus
should not become the foundation of the final system.
9Chapter 2 Software Processes
Boehm’s spiral model
 Process is represented as a spiral rather than as a
sequence of activities with backtracking.
 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.
10Chapter 2 Software Processes
Boehm’s spiral model of the software
process
11Chapter 2 Software Processes
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.
12Chapter 2 Software Processes
Rational Unified Process (RUP)
13© Papcunová
 A modern generic process commonly associated with the Unified
Modeling Language (UML).
 Normally described from 3 perspectives
▪ A dynamic perspective that shows phases over time
▪ A static perspective that shows process activities
▪ A practice perspective that suggests good practices to be used
during the process.
Rational Unified Process (RUP)
14Chapter 2 Software Processes
Phases in the Rational Unified Process
15Chapter 2 Software Processes
 Inception
▪ Establish the business case for the system.
 Elaboration
▪ Develop understanding of the problem domain and system architecture.
 Construction
▪ System design, programming and testing.
 Transition
▪ Deploy the system in its operating environment.
Iterative and incremental development
Chapter 2 Software Processes 16
 What is the difference between the two?
Incremental delivery
 Rather than deliver the system as a single delivery, the
development and delivery is broken down into
increments with each increment delivering part of the
required functionality.
 User requirements are prioritised and the highest
priority requirements are included in early increments.
 Once the development of an increment is started, the
requirements are frozen though requirements for later
increments can continue to evolve.
17Chapter 2 Software Processes
Incremental development benefits
 Customer value can be delivered with each increment
so system functionality is available earlier.
 Early increments act as a prototype to help elicit
requirements for later increments.
 Lower risk of overall project failure.
 The highest priority system services tend to receive the
most attention (design, testing, etc.).
Chapter 2 Software Processes 18
Incremental development problems
 The complete specification is hard to foresee.
▪ This becomes problematic when complete specification is
required in contract negotiation.
 System structure tends to degrade as new increments
are added.
▪ Unless time and money is spent on extensive refactoring,
regular changes tend to corrupt system structure and increase
the cost of incorporating further changes.
 It is hard to identify and effectively design basic facilities
shared by different parts of the system.
 The process is not visible, progress is hard to trace.
Chapter 2 Software Processes 19
Agile methods
 Agile methods:
▪ Focus on the code rather than the design
▪ Are based on an iterative and incremental approach to
software development
▪ Are intended to deliver working software quickly and evolve this
quickly to meet changing requirements.
 The aim of agile methods is to reduce overheads in the
software process (e.g. by limiting documentation) and
to be able to respond quickly to changing
requirements without excessive rework.
20Chapter 3 Agile software development
Reuse-oriented software engineering
 Based on systematic reuse where systems are
integrated from existing components or COTS
(Commercial-off-the-shelf) systems.
 Process stages
▪ Component analysis;
▪ Requirements modification;
▪ System design with reuse;
▪ Development and integration.
 Reuse is now the standard approach for building many
types of business system
Chapter 2 Software Processes 21
Key points
 General process models describe the organization of
software processes.
▪ Examples of general models include the ‘waterfall’ model,
incremental development, and reuse-oriented development.
 Processes should include activities to cope with change.
▪ This may involve prototyping and incremental delivery, which
help to avoid poor early decisions on requirements and design.
 Agile methods are incremental development methods
that focus on frequent releases, reducing process
overheads and emphasize customer involvement.
Chapter 1 Introduction 22
23
Agile Development
Lecture 4/Part 2
© Papcunová
Agile
24© Papcunová
 Being agile means being responsive to a change
 A mindset established through 4 values, grounded by 12 principles
and manifested through many different practices
 A leadership philosophy that encourages teamwork, selforganization
and accountability
 Main aspects:
▪ Flexibility
▪ Work breakdown
▪ Value of teamwork
▪ Iterative improvements
▪ Cooperation with a client
Agile manifesto
25© I. Papcunová and B. Bühnová
The principles of agile methods
Principle Description
Customer involvement Customers should be closely involved throughout the
development process. Their role is provide and prioritize new
requirements and to evaluate the iterations of the system.
Incremental delivery The software is developed in increments with the customer
specifying the requirements to be included in each increment.
People not process The skills of the development team should be recognized and
exploited. Team members should be left to develop their own
ways of working without prescriptive processes.
Embrace change Expect the system requirements to change and so design the
system to accommodate these changes.
Maintain simplicity Focus on simplicity in both the software being developed and in
the development process. Wherever possible, actively work to
eliminate complexity from the system.
26Chapter 3 Agile software development
Agile development
27© Papcunová
 A time boxed, iterative approach to software delivery that builds
software incrementally from the start of the project
 A group of software development methodologies based on iterative
development that focuses on frequent releases, reducing process
overheads and emphasize customer involvement through
collaboration between self-organizing cross-functional teams
https://content.altexsoft.com/media/2016/04/2-
agile-wp-1024x484.png
Benefits of agile development
28© Papcunová
 Customer satisfaction by continuous delivery of software
 Working software is delivered frequently
 Greater flexibility and adaptability to change
 Increased collaboration frequency and feedback
 Close cooperation between stakeholders and developers
 Focused on Business Value
 Increased project control
Problems and challenges in agile
29© Papcunová
 The project can easily get taken off track if the stakeholder is not
clear with what final outcome they want
 It can be difficult to keep the interest of customers who are
involved in the process
 The level of collaboration can be difficult to maintain
 The risk of losing long-term vision as there is no clear end of the
project
 Contracts may be a problem as with other approaches to iterative
development.
Problems and challenges in agile
 Documentation tends to get sidetracked
 Difficult to measure progress
 Because of their focus on small, tightly-integrated teams, one needs
to be careful when scaling agile methods to large systems.
 Prioritizing changes can be difficult where there are multiple
stakeholders.
 Maintaining simplicity requires extra work
30Chapter 3 Agile software development
Agile vs Waterfall
31© Papcunová
https://saigontechnology.com/assets/media/agile-scrum-vs-waterfall.png
Agile Practices
Lecture 4/Part 3
32© Papcunová
Agile practices
33© Barbora Bühnová
https://www.researchgate.net/publication/267429278_Agile_Practices_An_Assessment_of_Perception_of_Value_of_Professionals_on_the_Quality_Criteria_in_Performance_of_Projects
User Story
34© Papcunová
 The smallest unit of work in an agile framework
 An informal, natural language description of a feature or desired
outcome of a software system
 Often written from the perspective of an end user of a system to
influence the functionality of the system being developed
 May be written by various stakeholders including clients, users,
managers, or development team members
As a < type of user >, I want < some goal >
so that < some reason >.
Daily Scrum (Stand-up)
35© I. Papcunová and B. Bühnová
 A 15-minute time-boxed event for the Development Team to
synchronize activities and create a plan for the next 24 hours
 Optimizes team collaboration and performance by sharing the work
done since the last Daily Scrum/Stand-up and forecasting upcoming
Sprint work
 The Daily Scrum/Stand-up is held at the same time and place each
day
 Every team member should answer these questions:
▪ What did I work on yesterday?
▪ What am I working on today?
▪ What issues are blocking me?
Backlog
36© I. Papcunová and B. Bühnová
 List of items ordered by priority, prioritized by the product owner
 The items ranked highest on the list represent the most important or
urgent items for the team to complete
 Product backlog:
▪ The list of tasks to be done and contains a prioritized list of all
product requirements that a team maintains for a product
 Sprint backlog:
▪ The list of tasks from product backlog to be completed by the
development team during the next sprint
Backlog
37© Papcunová
Sprintbacklog
Product backlog
UserStory
Agile Methods
Lecture 4/Part 4
38© Papcunová
History of agile
39© Barbora BühnováRodríguez, Pilar, Mika Mäntylä, Markku Oivo, Lucy Ellen Lwakatare, Pertti Seppänen, and Pasi Kuvaja. "Advances in using agile and lean
processes for software development." In Advances in Computers, vol. 113, pp. 135-224. Elsevier, 2019.
History of agile
40© Barbora Bühnová
https://www.visual-paradigm.com/guide/agile-software-development/what-is-agile-software-development/
Agile umbrella
41© Papcunová
https://i.pinimg.com/originals/e8/8f/1d/e88f1dfcf8917879c7391f42eef449fa.jpg
Common points
42© Papcunová
 All Agile methods have these points in common:
▪ Iterative design process
▪ Effective communication and stakeholder engagement
▪ Aiming for quality and reliable software
▪ Short development cycle allowing regular delivery of
software
Kanban
43© Papcunová
 A workflow designed to help visualize the work, maximize efficiency
requiring real-time communication of capacity and full transparency
of work
 Work items are represented visually on a kanban board, allowing
team members to see the state of every piece of work at any time
 Two main practices are:
▪ Visualize
your work
▪ Limit work
in progress
(WIP)
https://kanbanize.com/wp-content/uploads/website-
images/kanban-resources/Kanban_board_elements.png
Scrum
44© Papcunová
 A set of meetings, tools, practices and roles to help teams structure
and manage their work
 Teams deliver products in iterations called sprints
 Continuously creating the highest priority parts of functionality and
regularly getting
customers’ feedback
https://media.vlpt.us/images/katanazero86/p
ost/dca8baba-9834-4276-ae85-
870753abb0dd/%EB%8B%A4%EC%9A%B4
%EB%A1%9C%EB%93%9C.jpg?w=768
Scrum ceremonies
 Sprint
▪ Basic unit of development in Scrum, fixed duration 1-4 weeks.
 Sprint planning
▪ Planning event to discuss and agree on the scope of work that is intended to be
done during that sprint.
 Daily Scrum
▪ Each day during a sprint, the team holds a daily scrum (or stand-up) to let
everybody say what they completed yesterday, what they plan to complete today,
what impediment they face.
 Sprint review
▪ The team reviews the work that was completed and plans the work that was not
completed.
 Sprint retrospective
▪ Team reflects on the past sprint and identifies and agrees on continuous process
improvement actions.
45Chapter 3 Agile software development
SCRUM
46Chapter 3 Agile software development
Extreme programming
47© Papcunová
 An agile methodology
designed to improve the
quality of software and
its ability to adapt to the
changing needs of the
customer
 Iterative and frequent
small releases
 Practices:
▪ Pair programming
▪ Test driven
development (TDD)
https://www.hiclipart.com/free-transparent-
background-png-clipart-aqzrw
Feature driven development
48© Papcunová
 A client-centered, architecture-centered, and pragmatic software
process
 Ideal for long-term, complex projects looking for a simple but
comprehensive methodology with clear outcomes
 Principles
▪ Domain object modeling
▪ Developing by feature
▪ Individual class ownership
▪ Feature teams
▪ Inspections
▪ Configuration management
▪ Progress reports
Feature driven development
49© Papcunová
 Project stages:
▪ Develop An Overall Model
▪ Build a Features List
▪ Plan By Feature
▪ Design By Feature
▪ Build By Feature
https://www.atsc.org.my/wp-content/uploads/2015/01/FDD.jpg
Test driven development
50© Papcunová
 A process that relies on the repetition of a very short development
cycle: requirements are turned into very specific unit test cases, then
the code is improved so that the tests pass
https://codica-images-staging.s3.eu-central-
1.amazonaws.com/c3cb64e3ac2d4eae89002e0ccc5789dd.png
Project roles
51© Papcunová
 Product Owner
▪ An expert on the product and the customer’s needs and priorities. Works with the
development team daily to help clarify requirements and makes business
decisions.
 Scrum Master
▪ The team role responsible for ensuring the team lives agile values and principles
and follows the processes and practices that the team agreed they would use.
 Team Member
▪ The people who create the product. Programmers, testers, designers, writers,
data engineers, and anyone else with a hands-on role in product development.
 Stakeholder
▪ Anyone with an interest in the project. Provides regular feedback and is affected
by the project’s outcome.
Project roles
© Papcunová 52
https://wac-cdn.atlassian.com/dam/jcr:f085fea0-5149-4b9a-9fe1-
7e9fd32dc0da/Scrum-Development%20team-
revised.png?cdnVersion=1027
https://wac-
cdn.atlassian.com/dam/jcr:9
8d24faa-dd1e-4563-b389-
85dc58b13b77/Scrum-
Master-
revised.png?cdnVersion=10
27
https://wac-cdn.atlassian.com/dam/jcr:e65c7b56-55e3-
47e5-8e6b-ba80afa95a0f/Scrum-Product%20Owner-
revised.png?cdnVersion=1027
© Clear View Training 2010 v2.6 53
UML State Diagram
Lecture 4/Part 5
© Clear View Training 2010 v2.6 54
State machines
 Models life stages of a single model element – e.g. object, use case, module
 Every state machine exists in the context of a particular model element that:
▪ Has a clear life history modelled as a progression of states, transitions and events
▪ Responds to events dispatched from outside of the element
 There are two types of state machines:
▪ Behavioural state machines - define the behaviour of a model element
▪ Protocol state machines - model the protocol of a classifier
• E.g. call conditions and call ordering of an interface that itself has no behaviour
Off On Off On
turnOff
burnOut
light bulb
turnOn
© Clear View Training 2010 v2.6 55
Basic state machine syntax
 State = a situation or condition during the life of an object
▪ Determined at any point in time by the values of its
attributes, the relationships to other objects, or the
activities it is performing.
 Every state machine should have one initial state
which indicates the first state of the sequence
 Unless the states cycle endlessly, state machines
should have a final state which terminates its lifecycle
A B
anEvent
initial state transition
event
state final state
Color
red : int
green : int
blue : int
How many states?
© Clear View Training 2010 v2.6 56
State syntax
 Actions are instantaneous
and uninterruptible
▪ Entry actions occur
immediately on state entry
▪ Exit actions occur
immediately on state leaving
 Internal transitions occur
within the state. They do
not fire transition to a new
state
 Activities take a finite
amount of time and are
interruptible
EnteringPassword
entry/display passwd dialog
exit/validate password
keypress/ echo "*"
help/display help
do/get password
entry and
exit actions
internal
transitions
internal
activity
Action syntax: eventTrigger / action
Activity syntax: do / activity
state name
© Clear View Training 2010 v2.6 57
Transitions
A B
event1, event2 [guard condition] / act1, act2
behavioral state machine
C D
[precondition] event1, event2 / [postcondition]
protocol state machine {protocol}
Protocol
state machine
Specifies legal
sequences of
events.
Behavioral
state machine
Specifies
object’s
reactions to
events.
events guard condition actions
precondition events postcondition
© Clear View Training 2010 v2.6 58
 Choice pseudo state
directs its single incoming
transition to one of its
outgoing transitions
▪ Each outgoing transition
must have a mutually
exclusive guard condition
▪ Equivalent to two outgoing
transitions from one state
 Junction pseudo state
connects multiple incoming
transitions into one (or more)
transitions.
▪ When there are more
outgoing transitions, they
must have guard conditions
Unpaid
FullyPaid PartiallyPaidOverPaid
[payment == balance]
[payment > balance] [payment < balance]
acceptPayment acceptPayment
makeRefund
BankLoan
choice pseudo-state
Choice and junction pseudo states
junction
pseudo state
© Clear View Training 2010 v2.6 59
Events
 "The specification of a noteworthy
occurrence that has location in time and
space"
 Events trigger transitions in state machines
 Events can be shown externally, on
transitions, or internally within states
(internal transitions)
 There are four types of event:
▪ Call event
▪ Signal event
▪ Change event
▪ Time event
Off
On
turnOff turnOn
event
© Clear View Training 2010 v2.6 60
close()
Call event
 A call for an operation
execution
 The event should have
the same signature as an
operation of the context
class
 A sequence of actions
may be specified for a
call event - they may use
attributes and operations
of the context class
 The return value must
match the return type of
the operation
InCredit
deposit(m)/ balance = balance + m
AcceptingWithdrawal
entry/ balance = balance - m
RejectingWithdrawal
entry/ logRejectedWithdrawal()
withdraw(m)
[balance < m]
withdraw(m)
[balance >= m]
internal call event action
conditionexternal call event
entry action
SimpleBankAccount
© Clear View Training 2010 v2.6 61
close()
Signal events
 A signal is a
package of
information that is
sent
asynchronously
between objects
InCredit
deposit(m)/ balance = balance + m
AcceptingWithdrawal
entry/ balance = balance - m
RejectingWithdrawal
entry/ logRejectedWithdrawal()
withdraw(m)
[balance < m]
withdraw(m)
[balance >= m]
SimpleBankAccount
OverdrawnAccount
send a signal
«signal»
OverdrawnAccount
date : Date
accountNumber : long
amountOverdrawn : long
Calling borrowerOverdrawnAccount
signal receipt
© Clear View Training 2010 v2.6 62
close()
Change events
 The action is
performed when the
Boolean expression
transitions from false
to true
▪ The event is edge
triggered on a
false to true
transition
▪ The values in the
Boolean expression
must be constants,
globals or attributes
of the context class
 A change event
implies continually
testing the condition
whilst in the state
InCredit
deposit(m)/ balance = balance + m
balance >= 5000 / notifyManager()
AcceptingWithdrawal
entry/ balance = balance - m
RejectingWithdrawal
entry/ logRejectedWithdrawal()
withdraw(m)
[balance < m]
withdraw(m)
[balance >= m]
SimpleBankAccount
OverdrawnAccount
Boolean
expression
© Clear View Training 2010 v2.6 63
Time events
 Time events occur when a
time expression becomes
true
 There are two keywords,
after and when
 Elapsed time:
▪ after( 3 months )
 Absolute time:
▪ when( date =20/3/2000)
Overdrawn
balance < overdraftLimit / notifyManager
Frozen
after( 3 months )
Context: CreditAccount class
© Clear View Training 2010 v2.6 64
Composite states
 Have one or more regions that
each contain a nested
submachine
▪ Simple composite state
• exactly one region
▪ Orthogonal composite state
• two or more regions
 The final state terminates its
enclosing region – all other
regions continue to execute
 The terminate pseudo-state
terminates the whole state
machine
A composite state
A B
C
region 1
region 2
submachines
Another composite state
D E
F
terminate
pseudo-state
© Clear View Training 2010 v2.6 65
Orthogonal composite states
 Has two or more regions
 When we enter the superstate, both submachines start
executing concurrently - this is an implicit fork
do/ initializeSecuritySensor
Initializing
InitializingFireSensors
do/ initializeFireSensor
InitializingSecuritySensors
Initializing composite state details
do/ monitorSecuritySensor
Monitoring
MonitoringFireSensors
do/ monitorFireSensor
MonitoringSecuritySensors
fire
intruder
Monitoring composite state details
Synchronized exit - exit the superstate when both
regions have terminated
Unsynchronized exit - exit the superstate when either
region terminates. The other region continues
© Clear View Training 2010 v2.6 66
[dialtone]
after(20 seconds)/ noDialtone after(20 seconds)/ noCarrier [carrier]
cancel
Simple composite states
do/ dialISP
DialingISP
entry/ offHook
WaitingForDialtone
Dialing
WaitingForCarrier
entry
pseudo
state
notConnected
dial
connectedexit pseudo-state
NotConnected Connected
entry/ onHook exit/ onHook
do/ useConnection
ISPDialer
the nested states inherit the cancel transition
© Clear View Training 2010 v2.6 67
Key points
 Behavioral and protocol state machines
 States
▪ Initial and final
▪ Exit and entry actions, activities
 Transitions
▪ Guard conditions, actions
 Events
▪ Call, signal, change and time
 Composite states
▪ Simple and orthogonal composite states