Top Banner
DSV SU + IbisSoft Requirements on No Requirements Analysis of agile software development from a Systems and Knowledge Transformation Perspective 1 Ilia Bider Recording on Youtube will be published shortly 06/06/2022 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
21

Requirements on No Requirements - When using agile is justified?

Dec 01, 2014

Download

Software

Ilia Bider

Analysis of agile software development from a Systems and Knowledge Transformation Perspective. Presentation at BIR 2014 (13TH INTERNATIONAL CONFERENCE ON PERSPECTIVES IN BUSINESS INFORMATICS RESEARCH). While the Agile Software Development (ASD) has been successfully promoted in the last 15 years, there is no agreement on how to determine whether a particular project is agile or not. Some practitioners consider agility as strict usage of a specific methodology, e.g. SCRUM, others consider agility as adhering to Agile Manifesto. The lack of common view on ASD prevents creating common guidelines on when the usage of ASD is appropriate. This paper presents a model of ASD that helps to differentiate it from the traditional, phase-based development, and more strictly defines the area of its applicability. The model has been built based on the knowledge transformation perspective, as the author considers it to be the most differentiating perspective when comparing ASD to traditional software development. For building the model, the ideas from SECI model of Nonaka have been exploited. The results, in the form of requirements to be fulfilled for successful employment of ASD, are demonstrated through analysis of completed ASD projects.

Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: 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

Page 2: Requirements on No Requirements - When using agile is justified?

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

Page 3: Requirements on No Requirements - When using agile is justified?

04/09/2023 DSV SU + IbisSoft 3

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

Page 4: Requirements on No Requirements - When using agile is justified?

04/09/2023 DSV SU + IbisSoft 4

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

Page 5: Requirements on No Requirements - When using agile is justified?

04/09/2023 DSV SU + IbisSoft 5

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

Page 6: Requirements on No Requirements - When using agile is justified?

04/09/2023 DSV SU + IbisSoft 6

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.

Page 7: Requirements on No Requirements - When using agile is justified?

04/09/2023 DSV SU + IbisSoft 7

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

Page 8: Requirements on No Requirements - When using agile is justified?

04/09/2023 DSV SU + IbisSoft 8

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

Page 9: Requirements on No Requirements - When using agile is justified?

04/09/2023 DSV SU + IbisSoft 9

Knowledge transformation in TSDECEA - a model of Traditional Software Development

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

explicit) • Reading manuals (explicit ->tacit

Becoming obsolete

Page 10: Requirements on No Requirements - When using agile is justified?

04/09/2023 DSV SU + IbisSoft 10

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

Page 11: Requirements on No Requirements - When using agile is justified?

04/09/2023 DSV SU + IbisSoft 11

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

Page 12: Requirements on No Requirements - When using agile is justified?

04/09/2023 DSV SU + IbisSoft 12

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

Page 13: Requirements on No Requirements - When using agile is justified?

04/09/2023 DSV SU + IbisSoft 13

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?

Page 14: Requirements on No Requirements - When using agile is justified?

04/09/2023 DSV SU + IbisSoft 14

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

Page 15: Requirements on No Requirements - When using agile is justified?

04/09/2023 DSV SU + IbisSoft 15

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

Page 16: Requirements on No Requirements - When using agile is justified?

04/09/2023 DSV SU + IbisSoft 16

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

Page 17: Requirements on No Requirements - When using agile is justified?

04/09/2023 DSV SU + IbisSoft 17

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.

Page 18: Requirements on No Requirements - When using agile is justified?

04/09/2023 DSV SU + IbisSoft 18

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)

Page 19: Requirements on No Requirements - When using agile is justified?

04/09/2023 DSV SU + IbisSoft 19

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

Page 20: Requirements on No Requirements - When using agile is justified?

04/09/2023 DSV SU + IbisSoft 20

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

Page 21: Requirements on No Requirements - When using agile is justified?

04/09/2023 DSV SU + IbisSoft 21

Q & A

Thank you for your patience

Questions and comments

Please

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