Software Development Process

[Link]/~zarras/[Link]

Slides material sources:

Software Engineering - Theory & Practice, S. L. Pfleeger
Introduction to Software Engineering, I. Sommerville
SWEBOK v3: IEEE Software Engineering Body of Knowledge
Software engineering
fundamentals
What is software?
What is software?

Computer programs and associated documentation.

Software products may be developed for a particular

customer or may be developed for a general market.
What is software engineering?
What is software engineering?

ISO/IEC/IEEE Systems and Software Engineering

Vocabulary (SEVOCAB) defines software engineering
as

“the application of a systematic, disciplined,

quantifiable approach to the development,
operation, and maintenance of software;

that is, the application of engineering to software”

Development process
fundamentals
What is a process?
What is a process ?

A process is a series of steps involving activities that take

some input, constraints, and resources to produce an intended
output of some kind.

A process involves a set of tools and techniques.

 What is a software
development process?
What is a software development
process model ?

A structured set of activities required to develop a

software system.

There are many different software processes but all involve

these key activities:

Requirements specification – defining what the system

should do.

Design and implementation – defining the organization of

the system and implementing the system.

Verification & Validation – checking if it works correctly

and if it does what the customer wants.

Evolution – changing the system in response to changing

customer needs.
 What is a software
development process model?
What is a development process model?

A software process model is a abstract representation of a

process.

It presents a description of a process from some particular

perspective.

A process description may include:

Activities that constitute the process.
Products, which are the outcomes of a process activity;
Roles, which reflect the responsibilities of the people
involved in the process;
Pre- and post-conditions, which are statements that are
true before and after a process activity has been enacted
or a product produced.

It is usually given in some notation like a simple directed

graph with nodes & edges, a UML activity diagram, a BPMN
 Well known software
development processes … a
historical retrospection
How do we develop small
programs for internal
operation/personal use?
The code & fix model

In the introduction of the Spiral model Boehm

refers to the basic model used in the earliest
days of software.
What is wrong with that?
The code & fix model
After a number of fixes, subsequent fixes may
become very expensive.

Frequently, the software becomes a poor

match to users’ needs that it is rejected or
redeveloped.
The code & fix model
Code is expensive to fix because of poor
preparation for testing and modification.

Lack of requirements analysis and design.

How do we develop larger
programs for delivery to a
customer?
The stage wise model

H.D. Benington, Production of

Large Computer Programs, In ONR
Symp. Advanced Programming
Methods for Digital Computers, pp.
15-27, 1956.

Also available in Annals of the

History of Computing, pp. 350-361,
1983 and in Proc. 9th Int’l Conf.
Software Engineering (ICSE), 1987.
 The waterfall model W. W. Royce, Managing the
Development of Large Software
Systems: Concepts and
Techniques, Proc. of Wescon,
1970.

Also available in Proc. 9th Int’l

Conf. Software Engineering (ICSE),
1987

A highly influential refinement of

the stage-wise model. It
provided two primary
enhancements to the stage-wise
model
 The waterfall model W. W. Royce, Managing the
Development of Large Software
Systems: Concepts and
Techniques, Proc. of Wescon,
1970.

Also available in Proc. 9th Int’l

Conf. Software Engineering (ICSE),
1987

(1) Recognition of the

feedback loops between
stages, and a guideline to
confine the feedback loops to
successive stages to
minimize the expensive
rework involved in feedback
across many stages.
The waterfall model
W. W. Royce, Managing the
Development of Large Software
Systems: Concepts and
Techniques, Proc. of Wescon,
1970.

Also available in Proc. 9th Int’l

Conf. Software Engineering (ICSE),
1987 (2) An initial
incorporation of
prototyping in the
software life cycle, via
a “build it twice”
step running in
parallel with
requirements analysis
and design.
The waterfall model
W. W. Royce, Managing the
Development of Large Software
Systems: Concepts and
Techniques, Proc. of Wescon,
1970.

Also available in Proc. 9th Int’l

Conf. Software Engineering (ICSE),
1987 Document
the design –
At least 6
documents
maintained
during the
whole process.
The evolutionary development model
McCracken and Jackson, Life-Cycle
Concept Considered Harmful, ACM
Software Engineering Notes, pp.
29-32, 1982.
Ok, but how about risks and
alternatives?
The spiral model
Barry W. Boehm, A Spiral Model of
Software Development and
Enhancement, IEEE Computer 21(5),
pp. 61-72, 1988.
The spiral model
Barry W. Boehm, A Spiral
Model of Software
Development and
Enhancement, IEEE Computer
21(5), pp. 61-72, 1988.
Agile approaches …
Agile methods

Dissatisfaction with the overheads

involved in conventional processes of the
1980s and 1990s led to the creation of
agile methods.

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.
Agile manifesto
eXtreme Programming (XP)
XP model
[Link]
[Link]/
Scrum
Scrum
[Link]

Scrum is a process framework that has been used to

manage work on complex products since the early
1990s.

Scrum is not a process, technique, or definitive method.

Rather, it is a framework within which you can employ
various processes and techniques.

Ken Schwaber and Jeff Sutherland

Scrum Team
[Link]

The Product Owner is the person responsible for managing the

Product Backlog. Product Backlog management includes:

[Link] expressing Product Backlog items;

[Link] the items in the Product Backlog to best achieve goals
and missions;
[Link] that the Product Backlog is visible, transparent, and
clear to all, and shows what the Scrum Team will work on next;
[Link] the Development Team understands items in the
Product Backlog to the level needed.
Scrum Team
[Link]

The Development Team consists of professionals who do the work

of delivering a potentially releasable Increment of “Done”
product at the end of each Sprint.

A “Done” increment is required at the Sprint Review. Only

members of the Development Team create the Increment.

<= 3 Size of team < 9

Scrum Team
[Link]

The Scrum Master is responsible for promoting and supporting

Scrum as defined in the Scrum Guide.

Scrum Masters do this by helping everyone understand Scrum

theory, practices, rules, and values.
Scrum Events
[Link]

The Sprint

The heart of Scrum is a Sprint, a time-box of one month or less

during which a “Done”, useable, and potentially releasable
product Increment is created. Sprints have consistent durations
throughout a development effort.

A new Sprint starts immediately after the conclusion of the

previous Sprint.

Sprints contain and consist of the Sprint Planning, Daily Scrums,

the development work, the Sprint Review, and the Sprint
Retrospective.

During the Sprint: No changes are made that would endanger

the Sprint Goal; Quality goals do not decrease; and, Scope may
Scrum Events
[Link]

Sprint Planning

Sprint Planning is time-boxed to a maximum of eight hours for a

one-month Sprint. For shorter Sprints, the event is usually
shorter.

Sprint Planning answers the following:

[Link] can be delivered in the Increment resulting from the
upcoming Sprint?
[Link] will the work needed to deliver the Increment be achieved?

What => select from Program Backlog

How => designing the product

Scrum Events
[Link]

Daily Scrum

The Daily Scrum is a 15-minute time-boxed event for the

Development Team. The Daily Scrum is held every day of the
Sprint.

Here is an example of what might be used:

What did I do yesterday that helped the Development Team meet

the Sprint Goal?

What will I do today to help the Development Team meet the

Sprint Goal?

Do I see any impediment that prevents me or the Development

Team from meeting the Sprint Goal?
Scrum Events
[Link]

Sprint Review

A Sprint Review is held at the end of the Sprint to inspect the

Increment and adapt the Product Backlog if needed.

During the Sprint Review, the Scrum Team and stakeholders

collaborate about what was done in the Sprint. Based on that and
any changes to the Product Backlog during the Sprint, attendees
collaborate on the next things that could be done to optimize
value.

This is an informal meeting, not a status meeting, and the

presentation of the Increment is intended to elicit feedback and
foster collaboration. This is at most a four-hour meeting for one-
month Sprints. For shorter Sprints, the event is usually shorter
Scrum Events
[Link]

Sprint Retrospective

The Sprint Retrospective is an opportunity for the Scrum Team to

inspect itself and create a plan for improvements to be enacted
during the next Sprint.

[Link] how the last Sprint went with regards to people,

relationships, process, and tools;
[Link] and order the major items that went well and potential
improvements;
[Link] a plan for implementing improvements to the way the
Scrum Team does its work.
Scrum Artefacts
[Link]

Product Backlog

The Product Backlog is an ordered list of everything that is known

to be needed in the product.

The Product Owner is responsible for the Product Backlog,

including its content, availability, and ordering.

A Product Backlog is never complete.

The Product Backlog lists all features, functions, requirements,

enhancements, and fixes that constitute the changes to be made
to the product in future releases. Product Backlog items often
include test descriptions
Scrum Artefacts
[Link]

Sprint Backlog
The Sprint Backlog is the set of Product Backlog items selected for
the Sprint, plus a plan for delivering the product Increment and
realizing the Sprint Goal.

The Sprint Backlog is a forecast by the Development Team about

what functionality will be in the next Increment and the work
needed to deliver that functionality into a “Done” Increment.

As work is performed or completed, the estimated remaining work

is updated.