Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Requirements on No Requirements 
Analysis of agile software development from a 
Systems and Knowledge Transformation 
Pers...
Objectives 
• Goal 
– Set up a list of pre-conditions for success of an 
agile software development project 
• Limitations...
Plan for reaching the goal 
Build models of software development for both traditional 
– phase-based development (TSD), an...
Background to built upon 
• A systems perspective on software development 
• A knowledge transformation perspective on sof...
Background: Systems perspective 
Three interconnected systems involved in software 
development: 
10/5/2014 DSV SU + IbisS...
Background: Systems perspective 
Why the project is created: systems coupling diagram 
From Lawson, H.W., 2010. A journey ...
Background: Knowledge transformation 
SECI model of knowledge transformation of Nonaka: 
Two types of knowledge: 
– Explic...
Background: Knowledge transformation 
Additional type of knowledge – embedded knowledge 
Justification 
– Every good regul...
Knowledge transformation in TSD 
ECEA - a model of Traditional Software Development 
Additional activities, e.g.: 
• Writi...
Knowledge transformation in ASD 
SEA - a model of Agile Software Development: 
Avoiding explication of knowledge 
10/5/201...
Advantages & drawbacks of TSD 
Advantages: 
1. Specialization – distribution of work 
in between experts in 4 distinct fie...
Advantages & drawbacks of TSD 
Drawbacks – a dark side of advantages 
1. Instability – No or insufficient 
Software system...
Advantages & drawbacks of ASD 
Mitigating the three drawbacks of TSD 
10/5/2014 DSV SU + IbisSoft 
13 
1. Instability 
2. ...
Advantages & drawbacks of ASD 
10/5/2014 DSV SU + IbisSoft 
Using ASD in the given project 
is OPTIONAL, building a 
softw...
Requirements on no requirements 
Requirements on human relationships 
10/5/2014 DSV SU + IbisSoft 
15 
# Requirement relev...
Requirements on no requirements 
Requirements on technical solution 
10/5/2014 DSV SU + IbisSoft 
16 
# Requirement releva...
Usability of Requirements 
on Having No requirements 
10/5/2014 DSV SU + IbisSoft 
17 
# Activity Comments 
1 Analysis of ...
Validation 
Analysis of past experience in 3 projects 
1. An attempt of substituting a legacy system using ASD – from 
lit...
Validation - Conclusion 
The approach seems promising so far, but 
validation is required for other areas of usage: 
1. De...
Information 
An extended version of this paper will be 
published as a chapter in the forthcoming book: 
Software Engineer...
Q & A 
Thank you for your patience 
Questions and comments 
Please 
Contact: ilia@{dsv.su|ibissoft}.se 
10/5/2014 DSV SU +...
Upcoming SlideShare
Loading in …5
×

Requirements on No Requirements - When using agile is justified?

1,744 views

Published on

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.

Published in: Software
  • Be the first to comment

Requirements on No Requirements - When using agile is justified?

  1. 1. 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
  2. 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 10/5/2014 DSV SU + IbisSoft 2
  3. 3. 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 10/5/2014 DSV SU + IbisSoft 3
  4. 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 10/5/2014 DSV SU + IbisSoft 4
  5. 5. Background: Systems perspective Three interconnected systems involved in software development: 10/5/2014 DSV SU + IbisSoft 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
  6. 6. 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. 10/5/2014 DSV SU + IbisSoft 6
  7. 7. Background: Knowledge transformation SECI model of knowledge transformation of Nonaka: Two types of knowledge: – Explicit – Tacit 10/5/2014 DSV SU + IbisSoft 7 Nonaka, I., 1994. A dynamic theory of organizational knowledge creation. Organization science, 5(1), pp.14-37..
  8. 8. 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 10/5/2014 DSV SU + IbisSoft 8
  9. 9. Knowledge transformation in TSD ECEA - a model of Traditional Software Development Additional activities, e.g.: • Writing manuals: embedded -> 10/5/2014 DSV SU + IbisSoft 9 explicit) • Reading manuals (explicit ->tacit Becoming obsolete
  10. 10. Knowledge transformation in ASD SEA - a model of Agile Software Development: Avoiding explication of knowledge 10/5/2014 DSV SU + IbisSoft 10 Difference: 1. Requirements: engineering -> discovery 2. Design + Coding = Embedment 3. One big cycle -> many small
  11. 11. 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 10/5/2014 DSV SU + IbisSoft 11 in explicit form 3. Contract based on Requirement Specification
  12. 12. Advantages & drawbacks of TSD Drawbacks – a dark side of advantages 1. Instability – No or insufficient Software system S-system 10/5/2014 DSV SU + IbisSoft 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
  13. 13. Advantages & drawbacks of ASD Mitigating the three drawbacks of TSD 10/5/2014 DSV SU + IbisSoft 13 1. Instability 2. Uncertainty 3. Evolving context Through multiple smaller cycles Is there a dark side?
  14. 14. Advantages & drawbacks of ASD 10/5/2014 DSV SU + IbisSoft 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
  15. 15. Requirements on no requirements Requirements on human relationships 10/5/2014 DSV SU + IbisSoft 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
  16. 16. Requirements on no requirements Requirements on technical solution 10/5/2014 DSV SU + IbisSoft 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
  17. 17. Usability of Requirements on Having No requirements 10/5/2014 DSV SU + IbisSoft 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.
  18. 18. 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) 10/5/2014 DSV SU + IbisSoft 18
  19. 19. 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 10/5/2014 DSV SU + IbisSoft 19
  20. 20. 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 10/5/2014 DSV SU + IbisSoft 20
  21. 21. Q & A Thank you for your patience Questions and comments Please Contact: ilia@{dsv.su|ibissoft}.se 10/5/2014 DSV SU + IbisSoft 21

×