Software Engineering

The Software Process (2)

 Agile Model (XP)
material adapted from Steve Easterbrook

Collect
User stories

Planning
Each cycle: game

approx 2 weeks
Release

Write test
code cases

integrate

test

2
3
 Agile Software Development

Agile software development is a group of software

development methods based on iterative and
incremental development, where requirements and
solutions evolve through collaboration between self-
organizing, cross-functional teams.
Methods
Iterative
incremental

4
 Agile Software Development

It promotes adaptive planning, evolutionary

development and delivery, a time-
boxed iterative approach, and encourages
rapid and flexible response to change.
It is a conceptual framework that promotes
foreseen interactions throughout the
development cycle.

5
 One Month’s Goals

6
7
8
 Too Many Meetings

9
 No Code Without Tests

10
 What is Agility?

Effective response to change

Effective communication among all
stakeholders
Drawing the customer onto the team;
eliminate the “us and them” attitude
Organizing a team so that it is in control of
the work performed
Rapid, incremental delivery of software
11
 Agile Software Process

Agile process must be adaptable

It must adapt incrementally
Requires customer feedback
An effective catalyst for customer
feedback is an operational prototype

12 12
 Agile Model Driven Development (AMDD)

Initial Requirements Initial Architectural

Modeling Modeling
(days) (days)

Cycle 0: Initial Modeling

Model Storming
(minutes)
Reviews
(optional)

All Cycles
(hours)

Implementation
(Ideally Test Driven)
(hours)

Cycle 1: Development
13 Cycle 2: Development
Copyright 2003-2005
Cycle n: Development Scott W. Ambler
 Iterative and Incremental Development

Iterative and Incremental development is at

the heart of a cyclic software development
process developed in response to the
weaknesses of the waterfall model.
It starts with an initial planning and ends
with deployment with the cyclic interactions in
between.
14
 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
system 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
15 work to eliminate complexity from the system.
 Principles to achieve agility

1. Highest priority -> satisfy the customer

2. Welcome changing requirements
3. Deliver working software frequently
4. Business people and developers must work
together
5. Build projects around motivated individuals
6. Emphasize face-to-face conversation1

16
 Principles to achieve agility

7. Working software is the primary measure of progress

8. Agile processes promote sustainable development
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 designs emerge from self-organizing teams
12. The team tunes and adjusts its behavior to become
more effective
17
 Agile Process Models

Extreme Programming (XP)

Adaptive Software Development (ASD)
Dynamic Systems Development Method (DSDM)
Scrum
Crystal
Feature Driven Development (FDD)
Agile Modeling (AM)

18 18
 eXtreme
Programming

19
 Extreme programming

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.
20
 Extreme Programming (XP)

XP uses an object-oriented approach as its

preferred development paradigm
Defines four (4) framework activities
Planning
Design
Coding
Testing
21 21
 Extreme Programming (XP) - 2
simple design spike solutions
CRC cards prototypes
user stories
values
acceptance test criteria
iteration plan

refactoring

pair programming

Release
unit test
software increment continuous integration
project velocity computed
22 22
acceptance testing
 XP - Planning
Begins with the creation of a set of stories (also called
user stories)
Each story is placed on an index card
The customer assigns a value (i.e. a priority) to the story
Agile team assesses each story and assigns a cost
Stories are grouped to for a deliverable increment
A commitment is made on delivery date
After the first increment “project velocity” is used to help
define subsequent delivery dates for other increments
23
 User Stories

24
 Pair Programming

Pairs produce higher quality code

Pairs complete their tasks faster
Pairs enjoy their work more
Pairs feel more confident in their work

25
 On-Site Customer

Customer available on site

Clarify user stories
Make critical business decisions
Developers don’t make assumptions
Developers don’t have to wait for decisions
Face to face communication minimizes the chances of
misunderstanding

26
 Testing in XP
• Testing is central to XP and XP has developed an
approach where the program is tested after every change
has been made.
• XP testing features:
– Test-first development.
– Incremental test development from scenarios.
– User involvement in test development and validation.
– Automated test harnesses are used to run all component
tests each time that a new release is built.
27
 XP - Testing

Unit tests should be implemented using a framework to

make testing automated. This encourages a regression
testing strategy.
Integration and validation testing can occur on a daily
basis
Acceptance tests, also called customer tests, are specified
by the customer and executed to assess customer visible
functionality
Acceptance tests are derived from user stories

28
 http://www.extremeprogramming.org/map/project.html

29 29
30 30
31 31
32 32
33 33
 agile and scrum

agile
Abstract
scrum
Concrete implementation of
agile
34
 Scrum

35
3
6

What is Scrum?

Definition from rugby football:

a scrum is a way to restart the game after
an interruption, where the forwards of
each side come together in a tight
formation and struggle to gain possession
of the ball when it is tossed in among
them
36
 How Scrum Works?

37
 Sample Product Backlog

38
 Process – Scrum
Suitable for development of unique products from unique
specifications
 Basic principles for the agile method Scrum
Self-organization – Leave responsibility to self-organizing teams
Transparency – Let anybody know what happens at any time
Good news as well as bad ones are visible early
Feedback – Work in a tight, empiric loop with the ”product
owner” (customer)
”Sprints” of 2 – 4 weeks
Self-assessment – Team retrospective after each sprint
39
 Scrum: Co-located teams

All team member meet face-to-face often

Communication
Communication
Communication
At what cost?
Some companies will not hire remote employees
Google included

40
 Scrum Roles

Product Owner
Possibly a Product Manager or Project Sponsor
Decides features, release date, prioritization, $$$

Scrum Master
Typically a Project Manager or Team Leader
Responsible for enacting Scrum values and practices
Remove impediments / politics, keeps everyone productive

Project Team
5-10 members; Teams are self-organizing
Cross-functional: QA, Programmers, UI Designers, etc.
Membership should change only between sprints
41
 Product Owner

 Define the features of the product

 Decide on release date and content
 Be responsible for the profitability of the product (ROI)
 Prioritize features according to market value
 Adjust features and priority every iteration, as needed
 Accept or reject work results.

42
 The Scrum Master

 Represents management to the project

 Responsible for enacting Scrum values and practices
 Removes impediments
 Ensure that the team is fully functional and productive
 Enable close cooperation across all roles and functions
 Shield the team from external interferences

43
 Scrum Team

 Typically 5-10 people

 Cross-functional
 QA, Programmers, UI Designers, etc.
 Members should be full-time
 May be exceptions (e.g., System Admin, etc.)
 Teams are self-organizing
 What to do if a team self-organizes someone off the team??
 Ideally, no titles but rarely a possibility
 Membership can change only between sprints

44
 Scrum - Gathering requirements
 Stories
Customer “tells a story”
Non-technical
ex: “When I check a piece of equipment, I want to know all
the information about it.”
 Tasks
Technical requirements needed for stories
ex:
host a database of equipment information
track equipment with barcodes
convert scanned codes into SQL queries
display query results to the user
45
 Scrum this semester

Generate stories
Divide stories into tasks
Give each task a time estimate
Assign each task a group member(s)
Track tasks in GitHub or productivity
software
Scrum board
46
 Scrum Highlights
 Scrum roles
 Product owner (PO) responsibilities to describe and prioritize requirements
 Team responsibilities to produce within a time boxed ”sprint” (iteration)
 Scrum master (SM) responsibilities to enable team working conditions
 Scrum practices
 Micro feedback, like daily scrum, sprint backlog, burn-down charts
 Macro feed-back and prioritization by product owner on every sprint,
Product backlog
 Scrum does not prescribe
 Solutions techniques, working methods, project progress plans
 These are up to the team to discover and adapt according to need
 Suitable for projects with uncertain goals or moving targets
 Or where the way to get there is not completely known
47
 Scrum Practices
 Time boxing
 The incremental value of an activity decreases over time
 80/20 benefit achieved within time box
 Potentially installable results
 Iterations (”sprints”) time boxed to 30 days (or shorter)
 Every iteration shall deliver custom value and production quality
 Reduce initial elaboration (one day)
 Specify ”all” overall requirements for initial product backlog
Main Use cases with scenarios, alt. user stories
Primary actor roles
 Prioritize and reprioritize
 Only work on what may be completed during next sprint (iteration)
 Specification and planning time box: one day
48
 Sprints

Scrum projects make progress in a series of

“sprints”
Analogous to XP iterations
Target duration is one month
+/- a week or two
But, a constant duration leads to a better
rhythm
Product is designed, coded, and tested during
49 the sprint
 No changes during the sprint

Change

Inputs Sprint Tested Code

 Plan sprint durations around how long you can commit to

keeping change out of the sprint

50
 Scrum - Sprints

After each sprint

Demo the software to the customer
Discuss the direction of the project
Adjust as needed

51
 A Scrum Sprint

 Sprint Planning
Commit to certain functionality & estimate
Produces Sprint Backlog
 Daily Scrum
15 minutes @ start of day
What have you done since last Scrum?
What will do before next Scrum?
What obstacles?

52
 Scrum

 Get it done
 Daily scrum 10 – 15 minutes
Identify obstacles and priorities
Emphasize collaboration
 Weekly review
How does progress look for cycle?
Requires estimation and work logging
 Subversion -> JIRA integration

53
54
5
5

Daily Scrum

 Is a short (15 minutes long) meeting, which is held every

day before the Team starts working
 Participants: Scrum Master (which is the chairman), Scrum
Team
 “Chickens” and “Pigs”
 Every Team member should answer on 3 questions

55
5
6

Questions

 What did you do since the last Scrum?

 What are you doing until the next Scrum?
 What is stopping you getting on with the work?

56
5
7

Sprint Backlog

No more then 300 tasks in the list

If a task requires more than 16 hours,
it should be broken down
Team can add or subtract items from
the list. Product Owner is not allowed
to do it
57
5
8
What is Scrum?
Sprint
backlog
Product Backlog Backlog
items selected
for release S3 backlog

S2 backlog
Product
S1 backlog
Backlog
Sprints in this release

Sprint 1 Sprint 2 Sprint 3

Product Daily
Owner Scrum
Team Retrospective

Review
Scrum Agenda
Master Agenda
Burndown
Agenda
Sprint Product
backlog (increment)
Ready Done
58
http://demo.callis.dk/scrum checklist checklist
 Common Failures with Scrum

1. Misunderstanding what Scrum is (and is

not)
2. Software not tested at end of sprint
(definition of Done)
3. Backlog not ready at beginning of sprint
(definition of Ready)
4. Lack of facilitation or bad facilitation
5. Lack of management support
596. Lack of client, customer, or end user support
 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

60
 Types of software component

Web services that are developed according to

service standards and which are available for
remote invocation.
Collections of objects that are developed as a
package to be integrated with a component
framework such as .NET or J2EE.
Stand-alone software systems (COTS) that are
configured for use in a particular environment.
61
 CBSE and design principles

 Apart from the benefits of reuse, CBSE is based on sound

software engineering design principles:
Components are independent so do not interfere with
each other;
Component implementations are hidden;
Communication is through well-defined interfaces;
Component platforms are shared and reduce
development costs.

62
 Components

 Components provide a service without regard to where

the component is executing or its programming language
 A component is an independent executable entity that
can be made up of one or more executable objects;
 The component interface is published and all
interactions are through the published interface;

63
 Component interfaces

 Provides interface
Defines the services that are provided by the
component to other components.
 Requires interface
Defines the services that specifies what services must
be made available for the component to execute as
specified.

64
 Component interfaces

Requires int erface Provides int erface

Defines the services Defines the services
fromthe component’s Component that are pro vided
environment that it by the component
uses to other co mponents

65
 A data collector component

Requires int erface Provides int erface

addSensor
removeSensor
sensorManagement
star tSensor
Data collector stopSensor
sensorData testSensor
initialise
repor t
listAll

66
 Component models

 A component model is a definition of standards for

component implementation, documentation and
deployment.
 Examples of component models
 EJB model (Enterprise Java Beans)
 COM+ model (.NET model)
 Corba Component Model
 The component model specifies how interfaces should be
defined and the elements that should be included in an
interface definition.
67
 Types of composition

 Sequential composition where the composed components

are executed in sequence. This involves composing the
provides interfaces of each component.
 Hierarchical composition where one component calls on
the services of another. The provides interface of one
component is composed with the requires interface of
another.
 Additive composition where the interfaces of two
components are put together to create a new component.

68
 Types of composition

A A

A B

B B

(a) (b) (c)

69
 Adaptor components

 Address the problem of component incompatibility by

reconciling the interfaces of the components that are
composed.
 Different types of adaptor are required depending on the
type of composition.
 An addressFinder and a mapper component may be
composed through an adaptor that strips the postal code
from an address and passes this to the mapper component.

70
 Adaptor for data collector

sensorManagement addSensor
star t removeSensor
star tSensor
sensor stop
Adapter Data collector stopSensor
sensorData testSensor
getdata initialise
repor t
listAll

71
 Photo library composition

addItem getImage
Image
adaptor Manager
Photo retrieve
Library
catEntry getCatalogEntry

User
Inter face

72
 Component development for reuse

 Components developed for a specific application usually

have to be generalised to make them reusable.
 A component is most likely to be reusable if it associated
with a stable domain abstraction (business object).
 For example, in a hospital stable domain abstractions are
associated with the fundamental purpose - nurses, patients,
treatments, etc.

73
 Component development for reuse

 Components for reuse may be specially constructed by

generalising existing components.
 Component reusability
 Should reflect stable domain abstractions;
 Should hide state representation;
 Should be as independent as possible;
 Should publish exceptions through the component interface.
 There is a trade-off between reusability and usability
 The more general the interface, the greater the reusability but it
is then more complex and hence less usable.

74
 CBSE problems

 Component trustworthiness - how can a component with

no available source code be trusted?
 Component certification - who will certify the quality of
components?
 Emergent property prediction - how can the emergent
properties of component compositions be predicted?
 Requirements trade-offs - how do we do trade-off analysis
between the features of one component and another?

75
 Bank example
 Requirements
 Open an account for a customer (savings or chequing)
 Deposit ƒ
Withdraw ƒ
Display details of an account ƒ
Change LOC ƒ
 Produce monthly statements ƒ
Print a list of customers
 Ambiguities
 What is the difference between savings and chequing?
76
 Case study

Children hospital
Care for children in the Alexandria city and
some Arab countries
The average length of stay of inpatients is
3.6 days
All patients are accompanied by a parent
for the entire duration of their stay at
77 hospital
 Case Study: Sensor Display

Consider a small system that displays the status of

several sensors (e.g., pressure, temperature, rate of
change, etc.) on a limited-size screen
What are some of its functional requirements?
What are some of its non-functional requirements?

display
System

78