Book contents
- Frontmatter
- Dedication
- Contents
- Figures
- Tables
- Foreword
- Preface
- Acknowledgements
- Overview of the Book
- 1 Knowledge Driven Development: What is the Proposition?
- 2 Project Delivery and Supporting Methodologies
- 3 Project Delivery Pain Areas and the Way Forward
- 4 Project Knowledge Model: Context and Definition
- 5 Project Knowledge Model: A Differentiator
- 6 Project Knowledge Model vs Project Documents
- 7 Extending Project Knowledge Model to Cover End-to-End Project Delivery – KDD
- 8 Extended KDD: Pre-Requirement and Post Delivery
- 9 KDD Compliance with Standards of Project Delivery
- 10 Enabling DevOps
- 11 Addressing Contemporary Concerns of Project Delivery
- 12 Helping Existing Methodologies
- 13 Technology Enablers: Tools and Automation
- 14 Suits Factory Model: Needs Cultural Change
- 15 Global Relevance of KDD: GKMF Assisting Skill Development
- 16 Lean KDD: Elimination of Requirement and Test Design?
- 17 Conclusion
- Appendix A Illustrative Non-Functional Attributes
- Appendix B Compliance of PKM with GKMF
- Appendix C Project Estimate and Business Rule/Scenario Framework
- Appendix D Inventory Relationship for Setting up of Security Questions – as per Example in Chapter 6
- Appendix E KDD: Response to Criticism
- Glossary
- References
- Index
Appendix E - KDD: Response to Criticism
Published online by Cambridge University Press: 20 October 2018
- Frontmatter
- Dedication
- Contents
- Figures
- Tables
- Foreword
- Preface
- Acknowledgements
- Overview of the Book
- 1 Knowledge Driven Development: What is the Proposition?
- 2 Project Delivery and Supporting Methodologies
- 3 Project Delivery Pain Areas and the Way Forward
- 4 Project Knowledge Model: Context and Definition
- 5 Project Knowledge Model: A Differentiator
- 6 Project Knowledge Model vs Project Documents
- 7 Extending Project Knowledge Model to Cover End-to-End Project Delivery – KDD
- 8 Extended KDD: Pre-Requirement and Post Delivery
- 9 KDD Compliance with Standards of Project Delivery
- 10 Enabling DevOps
- 11 Addressing Contemporary Concerns of Project Delivery
- 12 Helping Existing Methodologies
- 13 Technology Enablers: Tools and Automation
- 14 Suits Factory Model: Needs Cultural Change
- 15 Global Relevance of KDD: GKMF Assisting Skill Development
- 16 Lean KDD: Elimination of Requirement and Test Design?
- 17 Conclusion
- Appendix A Illustrative Non-Functional Attributes
- Appendix B Compliance of PKM with GKMF
- Appendix C Project Estimate and Business Rule/Scenario Framework
- Appendix D Inventory Relationship for Setting up of Security Questions – as per Example in Chapter 6
- Appendix E KDD: Response to Criticism
- Glossary
- References
- Index
Summary
Although KDD is not in the open forum for discussion about its merits and demerits (this book is the first attempt to take it to the industry and academia), while evolving this methodology and writing the book, it was exposed to many academicians and practitioners of software engineering. A list of concerns expressed by the experts and my responses to these concerns are given here.
Criticism 1
Computers cannot generate a fully readable document set representing complete project knowledge. Knowledge can never be fully defined (and will always be subjective) in a way that can be automated by a computer.
Response
Documents referred are related to project knowledge such as BRS, FSD, HLD and Test Cases. People who are sufficiently skilled in producing these documents have enough knowledge about them. But everyone has an individual style, whether it is writing, presenting or explaining. The personal experience of the author influences the document produced. Different people can present the same information differently. Some would write crisp and clear descriptions and some would write details covering detailed background information as well.
This suggests that, because computers cannot think, they cannot produce a project document as the project documents need creative thinking. Computers can only process information based on algorithms and it is assumed that it is difficult to write an algorithm to capture knowledge.
However, KDD has done something noteworthy. It has created a framework which defines and scopes the entire project knowledge. It expects the project team to capture the project knowledge using the same framework. It minimises the variations that are caused in a typical documentation regime. PKM provides a mechanism to capture the project knowledge in such a format which allows a computer to extract it in a document format.
Let us appreciate the robustness of PKM. Any information related to the project can be captured completely via the combination of inventory and relationship. There are only two activities involved here. The first one is defining the inventory of a building block via a set of mandatory and optional attributes. The second one is linking all the inventories together. When all the inventories are traced, it clearly brings out their many-to-many relationships, completing the nested knowledge. This brings the rigour and maturity to the model which makes it easier for a computer to extract a document based on an algorithm.
- Type
- Chapter
- Information
- Knowledge Driven DevelopmentBridging Waterfall and Agile Methodologies, pp. 281 - 285Publisher: Cambridge University PressPrint publication year: 2018