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 C - Project Estimate and Business Rule/Scenario Framework
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
One of the biggest issues that the IT industry is facing today is the lack of an effective mechanism for sizing a project. There are many techniques existing to size projects which are sometimes dependent on the technology used for the software and sometimes not. The main project sizing mechanisms are:
• Function Point estimate: The function point is a unit of measurement to express the amount of business functionality an information system (as a product) provides to a user. Function points are used to compute a functional size measurement of software. The sizing is independent of technology.
• Feature Point estimate: It is a modified function point to improve applicability to systems with significant internal processing (e.g., operating systems, communication systems). This allows accounting for functions not readily perceivable by the user, but essential for proper operations. The sizing is independent of the technology.
• Use Case based estimate: Use case represents the functional aspect of the project. The use cases and their complexity add up to scope the project and determine the size of the project. The sizing is independent of the technology.
• Component based estimate: The software is broken into multiple, manageable IT components and an estimate is done for each of the IT components. The technology influences the sizing.
• Line of Code: Line of code is another mechanism that determines the size of the software. The technology influences the sizing.
In practice, these methods are not very popular with the project teams. Estimates are still the prerogative of the SMEs, who often get them wrong. Techniques like Work Breakdown Structure (WBS) that calculate effort and not the software size are still widely used to estimate a project.
If we look at the three technology independent software sizing techniques (function point, feature point and use case), it becomes clear that they are primarily trying to count the functionality of the software. They represent the unit of project knowledge for sizing the software. As explained in chapter 15, a combination of business rule and scenario can be used to represent project knowledge. Combination of business rule and scenario is more suitable to become the basis of sizing a project – a well researched discovery made in the book as explained via GKMF and Lean KDD.
- Type
- Chapter
- Information
- Knowledge Driven DevelopmentBridging Waterfall and Agile Methodologies, pp. 272 - 273Publisher: Cambridge University PressPrint publication year: 2018