Requirements on No Requirements - When using agile is justified?

1DSV SU + IbisSoft

Requirements on No RequirementsAnalysis of agile software development from a

Systems and Knowledge Transformation Perspective

Ilia BiderRecording on Youtube will be published shortly

04/09/2023

13TH INTERNATIONAL CONFERENCE ON PERSPECTIVES IN BUSINESS INFORMATICS RESEARCH

Pre-proceedings http://bit.ly/1vBsgqI - Free access

Springer proceedings http://link.springer.com/chapter/10.1007/978-3-319-11370-8_11

04/09/2023 DSV SU + IbisSoft 2

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


Plan for reaching the goalBuild 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


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


Background: Systems perspectiveThree interconnected systems involved in software development:

Software systemS-system

Context SystemC-system

SE projectP-system

S-, P- and C- system needs to be aligned inside and between each other


Background: Systems perspectiveWhy 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.


Background: Knowledge transformationSECI model of knowledge transformation of Nonaka:

Nonaka, I., 1994. A dynamic theory of organizational knowledge creation. Organization science, 5(1), pp.14-37..

Two types of knowledge:– Explicit– Tacit


Background: Knowledge transformationAdditional 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


Knowledge transformation in TSDECEA - a model of Traditional Software Development

Additional activities, e.g.:• Writing manuals: embedded ->

explicit) • Reading manuals (explicit ->tacit

Becoming obsolete


Knowledge transformation in ASDSEA - a model of Agile Software Development:

Avoiding explication of knowledge

Difference:1. Requirements:

engineering -> discovery

2. Design + Coding = Embedment

3. One big cycle -> many small


Advantages & drawbacks of TSDAdvantages:

1. Specialization – distribution of work in between experts in 4 distinct fields (RE, Design, Coding, Training)

2. Using proven principles in all 4 fields in explicit form

3. Contract based on Requirement Specification


Advantages & drawbacks of TSDDrawbacks – a dark side of advantages

1. Instability – No or insufficient 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

Software systemS-system

Context SystemC-system

SE projectP-system


Advantages & drawbacks of ASDMitigating the three drawbacks of TSD

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

Warning sign on the top of the trails in Great Canyon


Requirements on no requirementsRequirements on human relationships

# 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 requirementsRequirements on technical solution# 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 Requirementson Having No requirements

# 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.


ValidationAnalysis of past experience in 3 projects

1. An attempt of substituting a legacy system using ASD – from literatureFailed (at least) on 2 , 3 and 6 (user involvement, core system, tools)

2. Developing a system from scratch using ASD – own experienceSatisfied all 6 requirements

3. Developing a system from scratch using TSD – own experienceHalf failed due to all drawbacks of TSD (Instability, Uncertainty, Evolving context)


Validation - ConclusionThe 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


InformationAn 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


Q & A

Thank you for your patience

Questions and comments

Please

Contact: ilia@{dsv.su|ibissoft}.se