Requirements on No Requirements - When using agile is justified?

Requirements on No Requirements
Analysis of agile software development from a
Systems and Knowledge Transformation
Perspective
DSV SU + IbisSoft
1
Ilia Bider
13TH INTERNATIONAL
CONFERENCE ON
PERSPECTIVES IN
BUSINESS INFORMATICS
RESEARCH
Recording on Youtube will be published shortly
10/5/2014
Pre-proceedings http://bit.ly/1vBsgqI - Free access
Springer proceedings http://link.springer.com/chapter/10.1007/978-3-319-11370-8_11

Objectives
• Goal
– Set up a list of pre-conditions for success of an
agile software development project
• Limitations
– We will consider only new software development,
leaving maintenance and farther development
outside our consideration
10/5/2014 DSV SU + IbisSoft
2

Plan for reaching the goal
Build models of software development for both traditional
– phase-based development (TSD), and agile
development (ASD) that help to
– Highlight the essential differences between TSD & ASD
– Highlight advantages and risks related to the TSD
– Show how ASD can help in mitigating the risks related to TSD
– Analyze the conditions required for success of ASD
3

Background to built upon
• A systems perspective on software development
• A knowledge transformation perspective on software
development
• Experience of the author in software related projects
– Including requirements engineering, software development,
introducing IT in organisations
– big and small, non-agile and agile, successful and
unsuccessful
– In different capacities, such as a programmer, group leader,
consultant, bug fixer, technical project manager
4

Background: Systems perspective
Three interconnected systems involved in software
development:
5
Software system
S-system
Context System
C-system
SE project
P-system
S-, P- and C- system needs to be aligned inside and
between each other

Background: Systems perspective
Why the project is created: systems coupling diagram
From Lawson, H.W., 2010. A journey through the systems
landscape. Systems Series, Volumes 1 and 5, College Publications.
6

Background: Knowledge transformation
SECI model of knowledge transformation of Nonaka:
Two types of knowledge:
– Explicit
– Tacit
7
Nonaka, I., 1994. A dynamic theory of
organizational knowledge creation.
Organization science, 5(1), pp.14-37..

Background: Knowledge transformation
Additional type of knowledge – embedded knowledge
Justification
– Every good regulator of a system must be a model of that system
(Conant and Ashby )
– A good solution is a model of the problem it solves (Scholten)
– A key is a model of the lock it opens (Scholten)
– A good software system is a model of the requirements its
implements/satisfy (Me)
Se also Armour, P.G., 2000. The Case for a New Business Model. Is software a
product or a medium? Communications of the ACM August 2000/Vol. 43, No. 8,
43(8), pp.19-22
8

Knowledge transformation in TSD
ECEA - a model of Traditional Software Development
Additional activities, e.g.:
• Writing manuals: embedded ->
9
explicit)
• Reading manuals (explicit ->tacit
Becoming obsolete

Knowledge transformation in ASD
SEA - a model of Agile Software Development:
Avoiding explication of knowledge
10
Difference:
1. Requirements:
engineering -> discovery
2. Design + Coding =
Embedment
3. One big cycle -> many
small

Advantages & drawbacks of TSD
Advantages:
1. Specialization – distribution of work
in between experts in 4 distinct fields
(RE, Design, Coding, Training)
2. Using proven principles in all 4 fields
11
in explicit form
3. Contract based on Requirement
Specification

Advantages & drawbacks of TSD
Drawbacks – a dark side of advantages
1. Instability – No or insufficient
Software system
S-system
12
negative feedback loop
2. Uncertainty – Not always easy to
imagine how C-system will work with
the new S-system in operation
3. Evolving context
Context System
C-system
SE project
P-system

Advantages & drawbacks of ASD
Mitigating the three drawbacks of TSD
13
1. Instability
2. Uncertainty
3. Evolving context
Through multiple smaller cycles
Is there a dark side?

Advantages & drawbacks of ASD
Using ASD in the given project
is OPTIONAL, building a
software system that will work
satisfactory in the context
intended for it is MANDATORY
14
Warning sign on the top of the trails in Great Canyon

Requirements on no requirements
Requirements on human relationships
15
# Requirement relevant
to ASD
Concerns
alignment
Difference from TSD
1 One team consisting of
“universal” members
Of P-system
itself
Several specialized teams
2 User involvement during the
duration of the project
Between P- and
C-systems
User involvement during
the Externalization and
Adoption phases
3 Non-contractual agreement
based on trust
Between P- and
C-systems
Contractual agreement is
possible

Requirements on no requirements
Requirements on technical solution
16
# Requirement relevant
to ASD
Concerns
alignment
Difference from TSD
4 Possibility to identify and
agree on a core system that
can be expanded in
consequent iterations
Between P-, S-and
C-systems
Not needed
5 Architecture aimed at
expansion
Between P- and
S-system
Architecture aimed at
fulfilling the identified
requirements
6 Employing high-level tools –
domain-specific languages,
development platforms,
libraries, etc., appropriate to
the application domain
Of P-system
itself and
between P- and
S- system
Not mandatory – low
level, and universal tools
can be employed

Usability of Requirements
on Having No requirements
17
# Activity Comments
1 Analysis of
past
experience
Analyzing what went wrong/right - promotes organizational
learning
2 Decision
making
As a check list for decision whether employing agile
methodology have chances for success.
3 Project
planning
As part of the plan of action when decision to use the agile
approach has been made.
4 Education The requirements in plus the simple brand independent
models can be used as educational material.

Validation
Analysis of past experience in 3 projects
1. An attempt of substituting a legacy system using ASD – from
literature
Failed (at least) on 2 , 3 and 6 (user involvement, core system,
tools)
2. Developing a system from scratch using ASD – own experience
Satisfied all 6 requirements
3. Developing a system from scratch using TSD – own experience
Half failed due to all drawbacks of TSD (Instability, Uncertainty,
Evolving context)
18

Validation - Conclusion
The approach seems promising so far, but
validation is required for other areas of usage:
1. Decision making (whether to use ASD or not)
2. Project planning
3. Education
19

Information
An extended version of this paper will be
published as a chapter in the forthcoming book:
Software Engineering in the Systems Context. Edited by
Ivar Jacobson and Harold “Bud” Lawson. College
Publishing, Systems series, 2015
20

Q & A
Thank you for your patience
Questions and comments
Please
Contact: ilia@{dsv.su|ibissoft}.se
21

Requirements on No Requirements - When using agile is justified?

Recommended

Recommended

More Related Content

Similar to Requirements on No Requirements - When using agile is justified?

Similar to Requirements on No Requirements - When using agile is justified? (20)

More from Ilia Bider

More from Ilia Bider (20)

Recently uploaded

Recently uploaded (20)

Requirements on No Requirements - When using agile is justified?