Functional Software Size Measurement Methodology with Effort Estimation and Performance Indication - Jasveer Singh - E-Book

Functional Software Size Measurement Methodology with Effort Estimation and Performance Indication E-Book

Jasveer Singh

0,0
105,99 €

-100%
Sammeln Sie Punkte in unserem Gutscheinprogramm und kaufen Sie E-Books und Hörbücher mit bis zu 100% Rabatt.
Mehr erfahren.
Beschreibung

Presents a new, effective methodology in software size measurement Software size measurement is an extremely important and highly specialized aspect of the software life cycle. It is used for determining the effort and cost estimations for project planning purposes of a software project's execution, and/or for other costing, charging, and productivity analysis purposes. Many software projects exceed their allocated budget limits because the methodologies currently available lack accuracy. The new software size measurement methodology presented in this book offers a complete procedure that overcomes the deficiencies of the current methodologies, allowing businesses to estimate the size and required effort correctly for all their software projects developed in high level languages. The Functional Software Size Measurement Methodology with Effort Estimation and Performance Indication (FSSM) allows for projects to be completed within the defined budget limits by obtaining accurate estimations. The methodology provides comprehensive and precise measurements of the complete software whereby factual software size determination, development effort estimation, and performance indications are obtained. The approach is elaborate, effective and accurate for software size measurement and development effort estimation, avoiding inaccurate project planning of software projects. Key features: * Pinpoints one of the major, originating root causes of erroneous planning by disclosing hidden errors made in software size measurement, and consequently in effort estimates and project planning * All the major relevant and important aspects of software size measurement are taken into consideration and clearly presented to the reader Functional Software Size Measurement Methodology with Effort Estimation and Performance Indication is a vital reference for software professionals and Master level students in software engineering. For further information and materials relating to this book, such as FSSM 1.0 Calculations Template for Results Tables and Graphs, containing Calculations, and Results Tables/Graphs for the Mini FSSM Example, please visit the following two accompanying websites: http://booksupport.wiley.com www.fssm.software

Sie lesen das E-Book in den Legimi-Apps auf:

Android
iOS
von Legimi
zertifizierten E-Readern

Seitenzahl: 705

Veröffentlichungsjahr: 2017

Bewertungen
0,0
0
0
0
0
0
Mehr Informationen
Mehr Informationen
Legimi prüft nicht, ob Rezensionen von Nutzern stammen, die den betreffenden Titel tatsächlich gekauft oder gelesen/gehört haben. Wir entfernen aber gefälschte Rezensionen.



IEEE Press Editorial Board

Tariq Samad, Editor in Chief

Giancarlo Fortino

Xiaoou Li

Ray Perez

Dmitry Goldgof

Andreas Molisch

Linda Shafer

Don Heirman

Saeid Nahavandi

Mohammad Shahidehpour

Ekram Hossain

Jeffrey Nanzer

Zidong Wang

About IEEE Computer Society

IEEE Computer Society is the world's leading computing membership organization and the trusted information and career-development source for a global workforce of technology leaders including: professors, researchers, software engineers, IT professionals, employers, and students. The unmatched source for technology information, inspiration, and collaboration, the IEEE Computer Society is the source that computing professionals trust to provide high-quality, state-of-the-art information on an on-demand basis. The Computer Society provides a wide range of forums for top minds to come together, including technical conferences, publications, and a comprehensive digital library, unique training webinars, professional training, and the TechLeader Training Partner Program to help organizations increase their staff's technical knowledge and expertise, as well as the personalized information tool myComputer. To find out more about the community for technology leaders, visit http://www.computer.org.

IEEE/Wiley Partnership

The IEEE Computer Society and Wiley partnership allows the CS Press authored book program to produce a number of exciting new titles in areas of computer science, computing, and networking with a special focus on software engineering. IEEE Computer Society members continue to receive a 15\% discount on these titles when purchased through Wiley or at wiley.com/ieeecs.

To submit questions about the program or send proposals, please contact Mary Hatcher, Editor, Wiley-IEEE Press: Email: [email protected], Telephone: 201-748-6903, John Wiley & Sons, Inc., 111 River Street, MS 8-01, Hoboken, NJ 07030-5774.

Functional Software Size Measurement Methodology with Effort Estimation and Performance Indication

Jasveer Singh

Copyright © 2017 by the IEEE Computer Society, Inc. All rights reserved.

Published by John Wiley & Sons, Inc., Hoboken, New Jersey.Published simultaneously in Canada.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 750-4470, or on the web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/permission.

Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.

For general information on our other products and services or for technical support, please contact our Customer Care Department within the United States at (800) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002.

Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic formats. For more information about Wiley products, visit our web site at www.wiley.com.

Library of Congress Cataloging-in-Publication Data:

Names: Singh, Jasveer, 1955- author.Title: Functional software size measurement methodology with effort estimation and performance indication / Jasveer Singh.Description: Hoboken, New Jersey : John Wiley & Sons, Inc., [2017] | Includes bibliographical references and index.Identifiers: LCCN 2016037106| ISBN 9781119238058 (pbk.) | ISBN 9781119238119 (epub)Subjects: LCSH: Software measurement. | Computer software--Evaluation.Classification: LCC QA76.76.S65 S56 2017 | DDC 005.1/4–dc23 LC record available at https://lccn.loc.gov/2016037106

This book is dedicated to all the software and managementprofessionals and students, and those keen to expand theirknowledge on the topic of software size measurement.

CONTENTS

Preface

Prelude

Software Size Measurement

About the Book

Acknowledgments

About the Author

List of Acronyms

About the Companion Websites

Part One FSSM: Introduction

Chapter 1 Introduction to Functional Software Size Measurement

1.1 Introduction

1.2 Functional Size Measurement and Effort Estimation

1.3 Important Considerations for the Software Size Measurement and Effort Estimation

1.4 Introduction to the Functional Software Size Measurement Methodology with Effort Estimation and Performance Indication (FSSM)

1.5 Chapter Summary

Exercises

Chapter 2 Synopsis of the Functional Software Size Measurement Methodology with Effort Estimation and Performance Indication (FSSM)

2.1 Salient Characteristics of the FSSM

2.2 Distinguishing Unique Key Features of the FSSM

2.3 Synoptic Description of the FSSM

2.4 Lists and Brief Descriptions of the FSSM Constituents

2.5 Source of Information for the FSSM Constituents

2.6 Examples

2.7 Chapter Summary

Exercises

Part Two FSSM: Software View

Chapter 3 Software's Measurable Components in the FSSM

3.1 Software's Measurable Component (SMC) Description

3.2 Software's Measurable Components (SMCs) Characteristics

3.3 Software's Measurable Components (SMCs) Presence and Size

3.4 Examples

3.5 Chapter Summary

Exercises

Chapter 4 Software Component's Measurable Features in the FSSM

4.1 Software Component's Measurable Feature (SCMF) Description

4.2 Usage of the Software Component's Measurable Features (SCMFs)

4.3 Software Component's Measurable Features (SCMFs) Presence and Quantity

4.4 Examples

4.5 Chapter Summary

Exercises

Part Three FSSM: Measurements

Chapter 5 Software Component's Feature Points in the FSSM

5.1 Software Component's Feature Point (SCFP) Description

5.2 Usage of the Software Component's Feature Points (SCFPs)

5.3 Software Component's Feature Points (SCFPs) Presence and Quantity

5.4 Examples

5.5 Chapter Summary

Exercises

Chapter 6 Software Component's Feature Point Counts in the FSSM

6.1 Software Component's Feature Point Count (SCFPC) Description

6.2 Counting Guidelines Flowchart for the Software Component's Measurable Features (SCMFs) of the Software's Measurable Component ‘Functionality Execution’ (CFE)

6.3 Some Specific Guidelines for the Software Component's Feature Point (SCFP) Counting

6.4 Software Component's Feature Point Counts (SCFPCs) Formation

6.5 Usage of the Software Component's Feature Point Counts (SCFPCs)

6.6 Software Component's Feature Point Counts (SCFPCs) Value

6.7 Examples

6.8 Chapter Summary

Exercises

Chapter 7 Software Component's Measurements through Software Component's Feature Measurements in the FSSM

7.1 Software Component's Measurement (SCM) and Software Component's Feature Measurement (SCFM) Description

7.2 Software Component's Measurement (SCM) and Software Component's Feature Measurement (SCFM) Formulae

7.3 Examples

7.4 Chapter Summary

Exercises

Part Four FSSM: Estimations and Indications

Chapter 8 Software Size Determination and Effort Estimations in the FSSM

8.1 Software Analysis – Size Determination and Effort Estimation, Static Structure, and Dynamic Characteristics in the FSSM

8.2 Software Size and Effort Estimation (SSEE) Description

8.3 Software Size and Effort Estimation (SSEE) Formulae

8.4 Chapter Summary

Exercises

Chapter 9 Software Performance Quality Indicators for Static Structure and Dynamic Characteristics in the FSSM

9.1 Software Performance Quality Indicator (SPQI) Description

9.2 Software Performance Quality Indicator (SPQI) Construction Information Source

9.3 Software Performance Quality Indicator (SPQI) Formulae

9.4 Examples

9.5 Chapter Summary

Exercises

Part Five FSSM: Summary Charts

Chapter 10 Summary Charts of the FSSM

10.1 Summary Charts of the FSSM Constituents

10.2 Chapter Summary

Part Six FSSM: Strengths

Chapter 11 Software Diagnostics Based on the Software Component's Feature Measurements and Software Performance Quality Indicators in the FSSM

11.1 Basic Diagnostics About the Functional Requirements Specifications (FRS) and Software, Based on the Software Component's Feature Measurements (SCFMs)

11.2 Advanced Diagnostics About the System Architecture, Functional Requirements Specifications (FRS), and Software, Based on the Software Performance Quality Indicators (SPQIs)

11.3 Chapter Summary

Chapter 12 Convertibility and ISO/IEC Standards Compliance of the FSSM

12.1 Convertibility of the FSSM to Other Functional Size Measurement (FSM) Methodology Cosmic

12.2 ISO/IEC Standards Compliance of the FSSM

12.3 Chapter Summary

Chapter 13 Significant Strengths of the FSSM

13.1 Coverage Capabilities of the FSSM in Comparison with Some Existing Software Size Measurement Methodologies

13.2 Advantages of the FSSM Over the Currently Available Methodologies

13.3 Examples

13.4 Chapter Summary

Part Seven FSSM: Usage - Example

Chapter 14 Example for Using the FSSM

14.1 Mini-FSSM Application Software Development (ASD) Introduction

14.2 Functional Requirements Specifications (FRS) of the Example – ‘MINI-FSSM Application Software Development’

14.3 Software Component's Feature Point (SCFP) Counting Explanation for the Example Mini-FSSM ASD

14.4 Software Component's Feature Point (SCFP) Counting and Software Component's feature point count (SCFPC) Formation Table for the Example Mini-FSSM ASD

14.5 FSSM Results Tables for the Software Example mini-FSSM Application Software Development

14.6 Graphical Representation of the Final Output Results for the Example Mini-FSSM

14.7 Chapter Summary

Part Eight Concluding Information

Chapter 15 Effort Estimate for the Usage of the FSSM

15.1 Software Component's Feature Point (SCFP) Counting, Analysis, and Report Preparation Effort Estimate For the Usage of the FSSM

15.2 Chapter Summary

Chapter 16 Known Limitations, Improvement Scope, and Conclusion

16.1 Known Limitations of the FSSM

16.2 Improvement Possibilities in the FSSM

16.3 Conclusion

16.4 Chapter Summary

Part Nine Glossary

Chapter 17 Glossary

17.1 Terms and Their Significance

Part Ten List of Figures and Answers to Exercises

Chapter 18 List of Figures

18.1 List of Figures

Chapter 19 Answers to Exercises

19.1 Chapter 1 Exercises

19.2 Chapter 2 Exercises

19.3 Chapter 3 Exercises

19.4 Chapter 4 Exercises

19.5 Chapter 5 Exercises

19.6 Chapter 6 Exercises

19.7 Chapter 7 Exercises

19.8 Chapter 8 Exercises

19.9 Chapter 9 Exercises

References

Index

EULA

List of Tables

Chapter 1

Table 1

Table 2

Chapter 2

Table 3

Chapter 5

Table 4

Chapter 9

Table 5

Table 6

Table 7

Table 8

Chapter 10

Table 9

Table 10

Table 11

Table 12

Table 13

Table 14

Table 15

Table 16

Table 17

Table 18

Chapter 12

Table 19

Table 20

Chapter 13

Table 21

Chapter 14

Table 22

Table 23

Table 24

Table 25

Table 26

Table 27

Table 28

Table 29

Table 30

Table 31

Table 32

Table 33

Table 34

Table 35

List of Illustrations

Chapter 1

Figure 1

Software size determination model. Adapted from Software Comprehensive Count with Quality Indicators (SCCQI), Jasveer Singh, UKSMA/COSMIC Conference 2012

[5]

, SMEF 2012

[6]

, NESMA Autumn Meeting 2012

[7]

.

Chapter 2

Figure 2

The FSSM information/procedure flow diagram.

Figure 3

FSSM summary diagram (part 1/5) – general overview (1/6) FRS, SMCs, and SCMFs.

Figure 4

FSSM summary diagram (part 1/5) – general overview (2/6) FRS, SMCs, SCMFs, SCFPs, and SCFPCs.

Figure 5

FSSM summary diagram (part 1/5) – general overview (3/6) FRS, SMCs, and SCFMs.

Figure 6

FSSM summary diagram (part 1/5) – general overview (4/6) FRS, SMCs, SCFMs, SCMs, and SSEEs.

Figure 7

FSSM summary diagram (part 1/5) – general overview (5/6) SCFMs, SCMs, and SPQIs-SSIs.

Figure 8

FSSM summary diagram (part 1/5) – general overview (6/6) SCFMs, SCMs, and SPQIs-SOIs.

Figure 9

FSSM summary diagram (part 2/5) – SCFMs.

Figure 10

FSSM summary diagram (part 3/5) – SCMs.

Figure 11

FSSM summary diagram (part 4/5) – SSEEs.

Figure 12

FSSM summary diagram (part 5/5) – SPQIs (1/2) of the type SSIs.

Figure 13

FSSM summary diagram (part 5/5) – SPQIs (2/2) of the type SOIs.

Chapter 6

Figure 14

Counting guidelines flowchart (1/3) for the Software Component's Measurable Features (SCMFs) of the Software's Measurable Component ‘Functionality Execution’ (CFE).

Figure 15

Counting guidelines flowchart (2/3) for the Software Component's Measurable Features (SCMFs) of the Software's Measurable Component ‘Functionality Execution’ (CFE).

Figure 16

Counting guidelines flowchart (3/3) for the Software Component's Measurable Features (SCMFs) of the Software's Measurable Component ‘Functionality Execution’ (CFE).

Chapter 14

Figure 17

Example mini-FSSM Log-on screen layout.

Figure 18

Example mini-FSSM New Entry screen layout.

Figure 19

Example mini-FSSM Total Counts screen layout.

Figure 20

Example mini-FSSM Results screen layout

[5–7]

. Adapted from Software Comprehensive Count with Quality Indicators (SCCQI), Jasveer Singh, UKSMA/COSMIC Conference 2012

[5]

, SMEF 2012

[6]

, NESMA Autumn Meeting 2012

[7]

.

Figure 21

Example mini-FSSM KSI screen layout

[5–7]

. Adapted from Software Comprehensive Count with Quality Indicators (SCCQI), Jasveer Singh, UKSMA/COSMIC Conference 2012

[5]

, SMEF 2012

[6]

, NESMA Autumn Meeting 2012

[7]

.

Figure 22

Graphical representation of the Software Component's Measurements (SCMs) for the mini-FSSM example. Adapted from Software Comprehensive Count with Quality Indicators (SCCQI), Jasveer Singh, UKSMA/COSMIC Conference 2012

[5]

, SMEF 2012

[6]

, NESMA Autumn Meeting 2012

[7]

.

Figure 23

Graphical representation of the Software Component's Measurements (SCMs) and Software Component's Feature Measurements (SCFMs) for the mini-FSSM example.

Figure 24

Graphical representation of the Software Structural Indicators (SSIs)

[5–7]

for the mini-FSSM example. Adapted from Software Comprehensive Count with Quality Indicators (SCCQI), Jasveer Singh, UKSMA/COSMIC Conference 2012

[5]

, SMEF 2012

[6]

, NESMA Autumn Meeting 2012

[7]

.

Figure 25

Graphical representation of the Software Operational Indicators (SOIs)

[5–7]

for the mini-FSSM example. Adapted from Software Comprehensive Count with Quality Indicators (SCCQI), Jasveer Singh, UKSMA/COSMIC Conference 2012

[5]

, SMEF 2012

[6]

, NESMA Autumn Meeting 2012

[7]

.

Guide

Cover

Table of Contents

Preface

Pages

xi

xii

xiii

xiv

xv

xvii

xix

xvii

1

3

4

5

6

9

10

11

12

13

14

15

16

17

18

19

20

21

22

24

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

109

110

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

178

179

180

181

182

183

185

186

187

188

189

191

196

197

206

207

209

210

211

212

213

214

215

216

217

218

225

226

227

228

230

231

232

233

234

235

236

237

238

239

240

241

242

243

245

247

248

249

250

251

252

253

254

255

256

257

260

262

264

265

266

267

268

269

270

271

272

273

274

275

276

277

278

279

280

281

282

283

284

285

286

287

288

289

299

301

305

306

310

311

313

314

315

316

317

318

319

321

322

323

324

325

326

327

328

329

330

31

332

333

334

335

336

337

338

339

340

341

342

343

344

345

346

347

348

349

350

351

352

353

354

355

356

357

358

359

360

361

362

363

364

365

366

367

368

369

370

371

372

373

374

375

376

377

378

379

380

381

382

383

384

385

386

387

388

389

391

393

394

395

396

397

399

400

401

402

403

404

405

406

407

408

409

410

411

412

413

414

415

Preface

Prelude

Software Size Measurement is an extremely important and highly specialized part of the software life cycle. It is needed for determining the effort and cost estimations for project planning purposes of the software projects' execution, and/or for other costing/charging/productivity analysis purposes of the software projects. The software size measurement part has not received proper attention and has been neglected till now as it is well known that many software projects exceed their allocated budget limits because the currently available methodologies for software size measurement present many areas for improvements whereby better and more accurate estimations for effort can be obtained. These methodologies measure only a very limited part of the software to determine the complete software's size which is an inaccurate way for the measurement of most of the software applications because of the reasons explained later in the book.

The available standards in this area, for example, ISO/IEC 14143-1[1], ISO/IEC 14143-2[2], do not specify what the constituents of the software are, which need to be measured. So it is left to the methodologies what to measure.

Project leaders and project managers depend on the size measurement specialists for measuring the software size. Specialists measure the size based on the current techniques. Then, various multiplier factors depending on the environmental factors such as the area of application software and assumptions about the complexity of the software are used to expand the size of the remaining unmeasured parts to get the complete software size in order to include the size of the parts missing in the measurements. Using non-specific multipliers would result in an assumed measurement size for the project. Project leaders, project managers, and specialists are aware of these facts but are obliged to continue using these measurements because no other thorough technique is available.

The new software size measurement methodology presented in this book, “Functional Software Size Measurement Methodology with Effort Estimation and Performance Indication (FSSM)”, overcomes these deficiencies, and is a comprehensive, elaborate, and complete software Functional Size Measurement[1] methodology, which can help enterprises to estimate the size and required effort for all their software projects developed in High Level Languages, quite accurately. Hence, these projects can be completed within the defined budget limits because of accurate estimations obtained by using the detailed and complete approach of the FSSM.

Software Size Measurement

“Functional Size Measurement (FSM)”[1] is a very effective method to measure the software “size in terms of the functions required by the user”[1] in which the functional “size of the software derived by quantifying the Functional User Requirements (FUR)”[1] is measured. Extra care should be taken to select a specific FSM[1] method. A method which measures only very few of the various types of functions available in the software should not be selected but one which measures all the important types of functions should be selected, for the reasons explained later in the book. Many currently available, popular FSM[1] methodologies can be improved in this respect. The most desired improvement would be to increase the coverage of the measurement regarding the number of the measured type of functions. The very small number of the type of functions measured – a small subset of the complete set of various available types of measurable functions – should be increased to a more extensive functional range.

Software consists of several constituent parts or components which can be named as “Base Functional Components (BFCs)”[1]. These components have no fixed proportional relationships amongst themselves or with respect to the complete software concerning their size in different applications or in the sub-programs (modules) of the same application. Moreover, the BFCs[1] have sub-types which are called “BFC Type”[1]. Most of these sub-types have no fixed proportional relationships amongst themselves for a particular BFC[1] or with the sub-types of other BFCs[1] regarding their size. Therefore, if only one or a few BFC types[1] of one or a few BFCs[1] are measured – so only a partial measurement – the size of the other remaining sub-types and components cannot be determined correctly based on this aforementioned measured part and some multiplication factors. However, this is how the current software sizing methodologies approach the estimation.

About the Book

Software has become so ubiquitous that the importance of the software projects and their timely completion cannot be overlooked. Timely completion is dependent on correct planning which requires realistic effort estimates. Effort estimates can be realistic only if accurate and complete software size measurements are available.

Many medium- and big-sized software projects are unable to be completed within the planned limits of time, money, and resources. This book pinpoints one of the major, originating, basic root causes of the erroneous planning by disclosing the hidden errors that are made in the software size measurement, and consequently in the effort estimates and project planning. It then reveals the simple and correct manner of accurate software size measurement whereby realistic effort estimates can be obtained based on which precise project planning can be done, and successful execution of the projects can be achieved within the planned limits.

The “Functional Software Size Measurement Methodology with Effort Estimation and Performance Indication (FSSM)” presented in this book provides comprehensive and precise measurements of the complete software whereby factual software size determination, development effort estimation, and performance indications are obtained. The methodology is elaborate, effective, and accurate for software size measurement and development effort estimation. Consequently, misconstrued project planning of the software projects can be avoided.

All the major, relevant, and important aspects of the software size measurement are taken into consideration in the FSSM and are presented to the reader. They are the software's measurable components, software component's measurable features, software component's feature points, software component's feature point counts, software component's feature measurements, software component's measurements, software size and effort estimations, and software performance quality indicators. Also included are a worked-out example with counting table, explanation, and results; software diagnostics based on the software component's feature measurements and software performance quality indicators; comparison with and advantages over some of the currently available methodologies; convertibility to another FSM[1] methodology; effort estimation for applying the FSSM methodology; and details of the full compliance with the ISO/IEC 14143-1[1] standards.

The book is destined and recommended for all the management/software professionals/students, and those interested in the field of software size measurement. It is intended to be used as a text book for the full or part of the advanced, specialized course of “Software Size Measurement” at the level of Master of Technology/Engineering/Science in the curriculum of the Computer Science/Engineering/Technology courses.

It is recommended that the reader already has some exposure to the software concepts/architecture from the point of view of applications, requirements, analysis, design, coding, and testing; DBMS, object-oriented technology; and acquaintance with the existing software size measurement/estimation techniques such as COSMIC[3] and IFPUG[4].

The book comprises:

Introduction to Functional Software Size Measurement;

Synopsis of the Functional Software Size Measurement Methodology with Effort Estimation and Performance Indication;

Software's Measurable Components;

Software Component's Measurable Features;

Software Component's Feature Points;

Software Component's Feature Point Counts;

Software Component's Measurements through Software Component's Feature Measurements;

Software Size Determination and Effort Estimations;

Software Performance Quality Indicators for Static Structure and Dynamic Characteristics;

Summary Charts;

Software Diagnostics;

Convertibility and ISO/IEC Standards Compliance;

Strengths and Comparison: Methodology Coverage and Advantages;

A Worked-Out Example with Functional Requirements Specifications, Counting Table and Explanations, and Results;

Methodology Usage Effort;

Examples, Exercises, and Glossary.

The presentation of the contents of FSSM is organized in the chapters in the following manner:

Distinct parts of group of chapters:

The book is divided into distinct parts of groups of chapters. The chapters in a group are related and linked amongst themselves. The parts follow a pattern of flow of information convenient for understanding.

Flow of information in the chapter contents:

The sequence of chapters with respect to their contents follows an orderly flow according to the flow scheme of proceedings in applying the FSSM.

Organization of contents of the chapters:

In all the chapters:

The descriptions in the chapters are divided under different relevant topics.

The summary of the contents of the chapter is presented at the end of the chapter.

Use of examples and exercises:

Suitable examples and exercises are included at the end of the chapters where appropriate. Some examples presented in the chapters are part of a large example which is presented completely in a separate chapter.

References:

Superscripted numbers point to the references of which a list is presented at the end of the book.

Use of new terms and acronyms:

Since the methodology is new and comprehensive, there is an abundance of terms which are associated with the methodology and are used in the book. To convey the meaning of the terms properly, the names of some of them are long. To make the use of terms simple, acronyms are utilized.

A complete acronym list is presented at the beginning of the book. Most of the acronyms used in the example chapter are not included in the complete list because their use is limited to the example chapter only and not elsewhere in the book.

In order to get familiar with the acronyms and terms, and get used to them, an attempt is made to adhere to the following conventions for their use in the text of the chapters: if the terms are used many times in a paragraph or a series of sequentially connected paragraphs, their first time use in the paragraph(s) utilizes the full-term name followed by the acronym in parentheses, the next time use utilizes the acronym followed by the full-term name in parentheses, and the further uses afterward utilize the acronym only. This way, it is easier to get familiarized with and get used to the terms and acronyms.

Acknowledgments

Special contribution and help, in the form of meticulous reviews, valuable suggestions for improvements in the structure and contents of the book throughout the period of book preparation, of the author's son, Seenu Singh, who is a concert pianist (Master of Music, Royal Conservatory of Flanders, Antwerp, Belgium) and holder of Master of Information Management degree (Katholieke Universiteit Leuven, Leuven, Belgium) and Master of Business Administration degree (IE Business School, Madrid, Spain), deserve special thanks and acknowledgment from the author who appreciates enormously their value and importance.

At the same time, the author is very thankful to the reviewers, amongst whom are Anupam Kumar (Senior Manager, Capgemini, Belgium), Bernard Tinant (ICT Consultant, Belgium), and Ramesh Dhar (IT Principal, Cigna Inc., USA), of the book at the proposal and final manuscript stages for their critical, valuable, and useful comments which helped to improve significantly the contents of the book. Also, the author is sincerely thankful to Mary Hatcher and Melissa Yanuzzi of Wiley/IEEE Press and all others involved in the publication of this book for their excellent professional support without which the publication of this book would not be possible.

Equally important are the permissions granted for using the material from the following organizations for which the author is very thankful:

ISO/IEC: The authorization to reproduce text from the ISO/IEC standards is given by NBN, the Belgian national standardization body. The standards can be obtained from ISO and any ISO member. .

IFPUG: This book contains material which has been extracted from the IFPUG Counting Practices Manual. It is reproduced in this book with permission of IFPUG.

UKSMA: This book is based on the concepts in the presentation “Software Comprehensive Count with Quality Indicators (SCCQI)” made at the UKSMA/COSMIC 23rd Annual Conference 2012.

SMEF: This book is based on the concepts presented in the paper “Software Comprehensive Count with Quality Indicators (SCCQI)” published in the Proceedings of the 9th Software Measurement European Forum, Rome, 2012.

NESMA: This book is based on the concepts in the presentation “Software Comprehensive Count with Quality Indicators (SCCQI) for Software Size Measurement” made at the NESMA November 2012 najaarsbijeenkomst (Autumn Meeting).

About the Author

The author of this book, Mr. Jasveer Singh, holds a Master of Technology degree in Computer Technology from the Indian Institute of Technology, Delhi, and has studied Executive Master in Management at École de Commerce Solvay, Brussels, Belgium.

He has about 30 years of valuable senior-level international experience in the Information and Communication Technology area and has worked in the top Information Technology/Telecom equipment manufacturer, operator, consultancy, and service companies in different countries (Bharat Electronics Limited, Alcatel, Siemens Business Services, WorldCom, Logica, and Keynote Sigos in India, France, Australia, Belgium, and Germany). A significant part of this experience has been in the management of software development (analysis, design, coding, testing), system design, quality assurance/control, and project management while working with different programming languages, object-oriented technology, database management systems, etc. His in-depth experience in these software domains led him to realize the improvements needed in the currently available methodologies for software size measurement and to develop the Functional Software Size Measurement Methodology with Effort Estimation and Performance Indication (FSSM) which is a thorough methodology and great help for software projects.

Currently, he is based in Belgium. He has extensive experience of working in multi-cultural environments and has very good communication skills in multiple languages. He has had the opportunity to visit about 25 countries for his work, enriching his knowledge both professionally and individually.

List of Acronyms

AECP

Action Execution Content Proportion

AEL

Action Execution Level

AEO

Action Execution Operations

ASD

Application Software Development

BFC Type

Base Functional Component Type[1]

BFC

Base Functional Component[1]

CFD

Software's Measurable Component ‘Functional Data’

CFDM

Software Component ‘Functional Data’ Measurement

CFE

Software's Measurable Component ‘Functionality Execution’

CFEM

Software Component ‘Functionality Execution’ Measurement

CFP

COSMIC Function Point[3]

CM

Class Method

CMDE

Class Method Entities

CME

Software's Measurable Component ‘Message Exchange’

CMEM

Software Component ‘Message Exchange’ Measurement

CNC

Computer Numerical Control (machine)

CO

Computational Operations

COCP

Computational Operation Content Proportion

COL

Computational Operations Level

COSMIC

Common Software Measurement International Consortium[3]

CRDM

Software Components Requirement Deficiency Measurement

CUI

Software's Measurable Component ‘User Interface’

CUIM

Software Component ‘User Interface’ Measurement

DAE

Data Class Attribute Entities

DBMS

Data Base Management System

DCE

Data Class Entities

DCL

Data Collection

DECP

Decision Execution Content Proportion

DEL

Decision Execution Level

DEO

Decision Execution Operations

DFE

Data Class Field Entities

ECDL

External Communication Functional Data Level

ECL

External Communication Level

ECP

External Communication Proportion

EFCCP

Execution Flow Control Content Proportion

EFCL

Execution Flow Control Level

EFCO

Execution Flow Control Operations

EHC

Error Handling Capability

EHO

Error Handling Operations

EHP

Error Handling Proportion

EI

External Input[4]

EIF

External Interface File[4]

EO

External Output[4]

EOFE

Message Exchange Operations Functional Data Entities

EODP

Message Exchange Operations Functional Data Proportion

EQ

External Inquiry[4]

ERP

Enterprise Resource Planning

FCCM

Software Component's Feature Point Count for ‘Class Method’

FCDA

Software Component's Feature Point Count for ‘Data Attribute’

FCDC

Software Component's Feature Point Count for ‘Data Class’

FCDF

Software Component's Feature Point Count for ‘Data Field’

FCDI

Software Component's Feature Point Count for ‘Data Input’

FCDM

Software Component's Feature Point Count for ‘Data Missing’

FCDO

Software Component's Feature Point Count for ‘Data Output’

FCDR

Software Component's Feature Point Count for ‘Data Read’

FCDW

Software Component's Feature Point Count for ‘Data Write’

FCFA

Software Component's Feature Point Count for ‘Function Action Execution’

FCFC

Software Component's Feature Point Count for ‘Function Computational Operation’

FCFD

Software Component's Feature Point Count for ‘Function Decision Execution’

FCFE

Software Component's Feature Point Count for ‘Function Error Handling’

FCFL

Software Component's Feature Point Count for ‘Function Logical Operation’

FCFM

Software Component's Feature Point Count for ‘Functionality Missing’

FCFO

Software Component's Feature Point Count for ‘Function Execution Flow Control’

FCFR

Software Component's Feature Point Count for ‘Function Repeat Execution’

FCLG

Software Component's Feature Point Count for ‘General Operations Functional Data’

FCLI

Software Component's Feature Point Count for ‘Input/Output Operations Functional Data’

FCLM

Software Component's Feature Point Count for ‘Memory Operations Functional Data’

FCLS

Software Component's Feature Point Count for ‘Message Exchange Operations Functional Data’

FCM

Software Component's Measurable Feature ‘Class Method’

FCMF

Software Component's Feature Point Count for ‘Message Field’

FCMM

Software Component's Feature Point Count for ‘Message Missing’

FCMR

Software Component's Feature Point Count for ‘Message Receive’

FCMS

Software Component's Feature Point Count for ‘Message Send’

FCNM

Software Component's Feature Point Count for ‘Notifying Message’

FCUF

Software Component's Feature Point Count for ‘User Screen Field’

FCUI

Software Component's Feature Point Count for ‘User Screen Input Link’

FCUM

Software Component's Feature Point Count for ‘User Screen Missing’

FCUO

Software Component's Feature Point Count for ‘User Screen Output Link’

FCUS

Software Component's Feature Point Count for ‘User Screen’

FD

Functional Data

FDA

Software Component's Measurable Feature ‘Data Attribute’

FDC

Software Component's Measurable Feature ‘Data Class’

FDCP

Functional Data Component Proportion

FDCS

Functional Data Complexity and Size

FDF

Software Component's Measurable Feature ‘Data Field’

FDI

Software Component's Measurable Feature ‘Data Input’

FDM

Software Component's Measurable Feature ‘Data Missing’

FDME

Functional Data Missing Entities

FDO

Software Component's Measurable Feature ‘Data Output’

FDR

Software Component's Measurable Feature ‘Data Read’

FDW

Software Component's Measurable Feature ‘Data Write’

FE

Functionality Execution

FECP

Functionality Execution Component Proportion

FECS

Functionality Execution Complexity and Size

FEDM

Functionality Execution Data Manipulation Measurement

FEME

Functionality Execution Missing Entities

FEODM

Functionality Execution Operations Dynamic Measurement

FEOM

Functionality Execution Operations Measurement

FFA

Software Component's Measurable Feature ‘Function Action Execution’

FFC

Software Component's Measurable Feature ‘Function Computational Operation’

FFD

Software Component's Measurable Feature ‘Function Decision Execution’

FFE

Software Component's Measurable Feature ‘Function Error Handling’

FFL

Software Component's Measurable Feature ‘Function Logical Operation’

FFM

Software Component's Measurable Feature ‘Functionality Missing’

FFO

Software Component's Measurable Feature ‘Function Execution Flow Control’

FFR

Software Component's Measurable Feature ‘Function Repeat Execution’

FLG

Software Component's Measurable Feature ‘General Operations Functional Data’

FLI

Software Component's Measurable Feature ‘Input/Output Operations Functional Data’

FLM

Software Component's Measurable Feature ‘Memory Operations Functional Data’

FLS

Software Component's Measurable Feature ‘Message Exchange Operations Functional Data’

FMF

Software Component's Measurable Feature ‘Message Field’

FMM

Software Component's Measurable Feature ‘Message Missing’

FMR

Software Component's Measurable Feature ‘Message Receive’

FMS

Software Component's Measurable Feature ‘Message Send’

FNM

Software Component's Measurable Feature ‘Notifying Message’

FP

Function Point[4]

FPCM

Software Component's Feature Point for ‘Class Method’

FPDA

Software Component's Feature Point for ‘Data Attribute’

FPDC

Software Component's Feature Point for ‘Data Class’

FPDF

Software Component's Feature Point for ‘Data Field’

FPDI

Software Component's Feature Point for ‘Data Input’

FPDM

Software Component's Feature Point for ‘Data Missing’

FPDO

Software Component's Feature Point for ‘Data Output’

FPDR

Software Component's Feature Point for ‘Data Read’

FPDW

Software Component's Feature Point for ‘Data Write’

FPFA

Software Component's Feature Point for ‘Function Action Execution’

FPFC

Software Component's Feature Point for ‘Function Computational Operation’

FPFD

Software Component's Feature Point for ‘Function Decision Execution’

FPFE

Software Component's Feature Point for ‘Function Error Handling’

FPFL

Software Component's Feature Point for ‘Function Logical Operation’

FPFM

Software Component's Feature Point for ‘Functionality Missing’

FPFO

Software Component's Feature Point for ‘Function Execution Flow Control’

FPFR

Software Component's Feature Point for ‘Function Repeat Execution’

FPLG

Software Component's Feature Point for ‘General Operations Functional Data’

FPLI

Software Component's Feature Point for ‘Input/Output Operations Functional Data’

FPLM

Software Component's Feature Point for ‘Memory Operations Functional Data’

FPLS

Software Component's Feature Point for ‘Message Exchange Operations Functional Data’

FPMF

Software Component's Feature Point for ‘Message Field’

FPMM

Software Component's Feature Point for ‘Message Missing’

FPMR

Software Component's Feature Point for ‘Message Receive’

FPMS

Software Component's Feature Point for ‘Message Send’

FPNM

Software Component's Feature Point for ‘Notifying Message’

FPUF

Software Component's Feature Point for ‘User Screen Field’

FPUI

Software Component's Feature Point for ‘User Screen Input Link’

FPUM

Software Component's Feature Point for ‘User Screen Missing’

FPUO

Software Component's Feature Point for ‘User Screen Output Link’

FPUS

Software Component's Feature Point for ‘User Screen’

FRS

Functional Requirements Specifications

FS

Functional Size[1]

FSM

Functional Size Measurement[1]

FSSM

Functional Software Size Measurement Methodology with Effort Estimation and Performance Indication

FSU

Functional Size Unit

FUF

Software Component's Measurable Feature ‘User Screen Field’

FUI

Software Component's Measurable Feature ‘User Screen Input Link’

FUM

Software Component's Measurable Feature ‘User Screen Missing’

FUO

Software Component's Measurable Feature ‘User Screen Output Link’

FUR

Functional User Requirements[1]

FUS

Software Component's Measurable Feature ‘User Screen’

GODL

General Operations Execution Functional Data Level

GODP

General Operations Functional Data Proportion

GOFE

General Operations Functional Data Entities

GPS

Global Positioning System

ICT

Information and Communications Technology

IE

Instituto de Empresa

IEC

International Electrotechnical Commission

IFPUG

International Function Point Users Group[4]

ILF

Internal Logical File[4]

IODP

Input/Output Operations Functional Data Proportion

IOFE

Input/Output Operations Functional Data Entities

IOO

Input/Output Operations

ISO

International Organization for Standardization

KSI

Key Software Indicator

LDM

Logical Data Model

LO

Logical Operations

LOCP

Logical Operation Content Proportion

LOL

Logical Operations Level

ME

Message Exchange

MECP

Message Exchange Component Proportion

MECS

Message Exchange Complexity and Size

MEME

Message Exchange Missing Entities

MEO

Message Exchange Operations

MFE

Message Field Entities

MO

Memory Operations

MODP

Memory Operations Functional Data Proportion

MOFE

Memory Operations Functional Data Entities

MTDL

Memory Traffic Functional Data Level

MTL

Memory Traffic Level

MTP

Memory Transaction Proportion

N/L/M/H/VH

Nil/Low/Medium/High/Very High

NESMA

Netherlands Software Metrics Users Association[7]

NME

Notifying Message Entities

QR

Quality Requirements

QRS

Quality Requirements Specifications

RDG

Requirements Deficiency Grade

RECP

Repeat Execution Content Proportion

REL

Repeat Execution Level

REO

Repeat Execution Operations

SADCE

Software Analysis, Design, and Coding Effort

SCCM

Software Comprehensive Count Method

SCCQI

Software Comprehensive Count with Quality Indicators

SCDS

Software Code Statements

SCE

Software Code Effort

SCFP

Software Component's Feature Point

SCFPC

Software Component's Feature Point Count

SCM

Software Component's Measurement

SCFM

Software Component's Feature Measurement

SCMF

Software Component's Measurable Feature

SCS

Software Comment Statements

SDADE

Software Data Analysis and Design Effort

SDS

Software Data Statements

SFADE

Software Functional Analysis and Design Effort

SLS

Software Logical Size

SMC

Software's Measurable Component

SMEF

Software Measurement European Forum[6]

SOA

Service-Oriented Architecture

SOI

Software Operational Indicator[5–7]

SPQI

Software Performance Quality Indicator

SSEE

Software Size and Effort Estimation

SSI

Software Structural Indicator[5–7]

STCM

Software Total Components Measurement

STDE

Software Total Development Effort

STE

Software Testing Effort

TDS

Technical Design Specifications

TR

Technical Requirements

UI

User Interface

UICP

User Interface Component Proportion

UICS

User Interface Complexity and Size

UIDL

User Interaction Functional Data Level

UIFE

User Interface Field Entities

UIIE

User Interface Input Link Entities

UIL

User Interaction Level

UIME

User Interface Missing Entities

UIOE

User Interface Output Link Entities

UIP

User Interaction Proportion

UISE

User Interface Screen Entities

UKSMA

United Kingdom Software Metrics Association[5]

URL

Uniform Resource Locator

About the Companion Websites

This book is accompanied by a companion website hosted by Wiley:

http://booksupport.wiley.com

The website includes:

FSSM 1.0 Calculations Template for Results Tables and Graphs, containing the Calculations, and Results Tables/Graphs for the Mini FSSM Example.

There is also an official FSSM website hosted by the author:

www.fssm.software

It provides additional interesting and relevant information related to the methodology presented in this book.

Part OneFSSM: Introduction

Chapter 1Introduction to Functional Software Size Measurement

1.1 Introduction

For software projects, it is very important to determine the size of the software for development effort estimation, project planning, and cost/productivity analysis.

How much effort will be spent on the software development – analysis, design, coding, testing, and documentation – for a particular application depends on the size of the software to be developed.

The size of the software to be developed depends on the functionality required by the application, and the effort is spent to develop all the required functionality.

The functionality required by the application is described in the Functional User Requirements (FUR)[1] which are the specifications of the required functionality and hence are also known as the Functional Requirements Specifications (FRS). These terms – FUR (Functional User Requirements)[1] and FRS (Functional Requirements Specifications) – denote the same thing, that is, the specifications of the user functionality required by the application.

1.2 Functional Size Measurement and Effort Estimation

Functional Size Measurement (FSM)[1] is an effective method for measuring the size of the software because it is meant to measure the functionality which is described in the FRS and on which the effort is spent for analysis, design, coding, testing, documentation, and maintenance.

All the functionality of the application is distributed in different constituent components of the software. These components are defined as Base Functional Components (BFCs)[1] in the ISO/IEC 14143-1[1] standards. Measurement of the size of software is achieved by measuring the size of the BFCs[1] and computing the total size based on the sizes of the BFCs[1].

The constituent components, that is, the BFCs[1], of the software comprise sub-types of the BFCs[1], defined as the Base Functional Component Types (BFC Types)[1] in the ISO/IEC 14143-1[1] standards. Measurement of the size of the BFCs[1] is achieved by measuring the size of the BFC Types[1] and computing the size of the BFCs[1] from the sizes of the BFC Types[1].

After deciding the boundaries which define the limits of the software measurement to a particular area of functionality specified in the FUR[1], the functional size of the BFC Types[1] is calculated by assigning the Units of Functional Size[2] to the BFC Types[1]. The functional size unit is defined in the methodologies mostly as Function Point[4]. Function Points[4] are thus assigned to various BFC Types[1] and are summed up for the entire functionality within the defined boundaries to produce the total software size of the corresponding BFCs[1], and then the sum of the Function Points[4] of the BFCs[1] produces the total software size.

Because of some substantial limitations (details of which are described in this and later chapters), in some of the popular and widely used software size measurement methodologies available, various multiplication factors which are different according to the type/field and functional contents of applications are used subsequently in order to estimate the effort required for development. The use of multiplication factors is required because a very limited part of all the measurable BFC Types[1] of a part of all the measurable BFCs[1] is measured, and from that small partial measurement, an attempt is made to estimate the effort of development for the whole software based on the assumption that the multiplication factors will take care of the unmeasured part and will thus produce the correct effort estimation. This approach may give erroneous results as clarified in further description. The FSSM is specially designed to overcome such limitations.

1.3 Important Considerations for the Software Size Measurement and Effort Estimation

Care should be taken while selecting a methodology to use for the Functional Size Measurement[1]. The methodology should be such that it measures all the major, relevant functionality on which the effort is required to be spent on development; otherwise – in case of measurement of only a small part of the software functionality – the significance of measurement is lost. The methodology should be simple and easy to use as well. Hence, there is a need of an integral software size measurement methodology which is presented in this book.

The following are some important facts that should be considered regarding the Functional Size Measurement[1], and methodologies to measure the functional size:

Software is composed of several distinct components which are inter-related but do not have any obligatory fixed size proportion relationship with respect to one another in any software application. That means, if there are four components: c1, c2, c3 and c4, their size may have any proportion according to the functional requirements concerning these components in different applications. So the magnitude of c1 may be much greater (measured by any method, e.g., counts, units) than c2 in one software application but it may be the opposite in another application. Similarly, the size proportion of c1 to other components in one application may be entirely different than in another application.

Each component has several features. For example, component c1 may have two features: c1f1, c1f2; component c2 may have three features: c2f1, c2f2, c2f3; component c3 may have four features: c3f1, c3f2, c3f3, c3f4; and component c4 may have one feature: c4f1. The size of different features varies according to the application. For most of the features, there is no fixed size relationship of different features of a component amongst themselves and with the features of other components. For example, in one application, the size of one feature c1f1 may be about 10 times bigger (measured by any method, e.g., counts, units) than the size of c2f3, but in another application, it may be of approximately the same size or even of opposite proportion.

If an application is made of several sub-programs or modules, the sub-programs have different proportions of different features of the components and may not have any similar size proportionate relationship with respect to one another or with respect to the whole software.

Size and complexity of a software component are interrelated.

What is meant by the complexity of the software components here is the level and degree of effort and time required for understanding, analyzing, designing, coding, testing, and maintaining the components.

The more the effort and time are required for these activities, the more complex the component is. For example, regarding data component, 1 table with 10 columns in a database application, or 1 data record with 10 fields in a program is quite simple, but 20 tables with 15–20 columns each, or 20 data records with 15–20 fields each, respectively, are more complex, and 80 tables with 20 columns each, or 80 data records with 20 fields each, respectively, are highly complex as far as the effort and time required for their understanding, analyzing, designing, coding, testing, and maintaining are concerned. The same is true for other components – functionality execution, user interfaces, and message communication.

As a general rule, the bigger the size of the component, the more the effort and time required to understand, analyze, design, code, test, and maintain it; and the more the effort and time required to understand, analyze, design, test, and maintain it, the more complex the component is.

Effort for software life cycle activities – development (analysis, design, coding, and testing), maintenance, documentation, etc. – is spent on all the features of all the components. Of course, not all the minute details of all the functionality can be taken into account for measurement, but it is important that the most relevant, major components and all their important features should be considered for size determination, effort estimation, and performance indication. If an accurate estimation of the total software size is needed for correct project planning, the size of all the measurable features for all the components should be computed. Hence, no major and relevant component and at the same time, no major and relevant feature should be ignored for measurement and estimation.

If we consider various application programs in different domains and see the magnitude of the presence of different features of the constituent components, it will vary from one application to the other. Not only that, the magnitude will vary in different sub-programs or modules of these applications programs with respect to one another.

The relationship of size between the components and their features depends on only the functionality required and it varies from one application to the other, and from one sub-program (module) to the other of any particular application.

For example, in the signaling part of the application of telecom call handling (call handling would normally consist of signaling, call control, number analysis, routing, charging, subscriber data, etc.), there will be much more amount of input/output operations from the input/output devices and much more message communication to/from other modules than the disk memory read/write operations. On the other hand, subscriber data will have more disk memory read operations to access the subscriber data, and message communication to/from call control module than computational/logical and decision operations. Routing may have more proportion of decision operations to decide about the routing.

In the radar application which will normally consist of input/output for image data, image extraction, filtering, etc., there will be high amount of input/output operations, high amount of computational operations, and medium amount of disk memory read/write operations in the complete application.

In a data warehouse report preparation application, there will be high amount of disk memory read/write operations and high amount of computational operations.

Table 1 shows the approximate magnitude (size) of some software constituents – components, features, and operations – and their size and complexity in terms of very low, low, medium, high, and very high depending on the number of functional operations or number of functional data elements being almost none, very few, a few, many, and too many, respectively, for the sub-programs of two applications: Telecom Call Handling and Radar. In this table, the sub-programs (or modules) of these applications are considered separately and individually, and their interactions with the other sub-programs (or modules) of the same application program are considered. The table contents are a rough estimate based on practical experience and assessment, and not based on any measurements.

Table 2 shows the approximate magnitude (size) of different components and features of components in different applications. In this table, the whole applications are considered and not separate sub-programs (modules) of the applications individually. For example, for the application Telecom Call Handling, all the sub-programs (modules) for signaling, call control, number analysis, routing, and charging are considered together as a whole application. Similarly, for radar application, all the sub-programs (modules) for input data, image extraction, filtering, and output display are considered together as a whole application. Only one instance of the program execution is considered and not the execution and operations for multi-users with multi-instances of the program running simultaneously. The table contents are a rough estimate based on practical experience and assessment, and not based on any measurements.

The purpose of Tables 1 and 2 is just to show how various applications differ in the size of the components and in the size of the features of the components.

If only a few features of one component or of a few components are measured (by any method, e.g., counts, units) and based on that the complete software size is calculated by using various multiplication factors, it may give unreliable results because there is no fixed proportional relationship of the size of one feature to the other feature(s) of the same component or of the other components for the majority of features as explained before. For example,

Example 1   In one application, there may be 50 data tables for which there may be one memory data read and write operation each from/to disk for each table, so the count for memory data read/write operations will be 100. In another application, there may be 2 data tables of which there may be 25 memory data read and write operations each from/to disk for each table, so the count for memory data read/write operations will be 100. In both the applications, the number of memory data read/write operations is the same but the data complexity and effort required from the point of view of development is much more in the former application. If we do the measurement of only memory data read and write operation, we would not know how big and complex the data part is, and whether database expertise is required for the development.

Example 2   In an application, there may be 2 user screens, one for input data and the other for output data, being used for input/output data 50 times each, so there will be 100 input/output operations. In another application, there may be 50 user screens for input data being used for 1 input operation each and 50 user screens for output data being used for 1 output operation each, so the total number of input/output operations will be 100. In both the applications, the number of input/output operations is the same but the user interface design in the latter application is more effort-consuming than the former. Only the size of input/output operations does not give a right indication about the input/output interface size and complexity, and thus the effort required for designing the screens, that is, screen structures, cannot be estimated based on the size of the input/output operations.

Moreover, in the aforementioned examples, the size of memory data read/write and input/output operations, respectively, does not indicate the magnitude of other operations in the program, for example, computational, logical, decision, repeat, execution flow control, and message exchange operations, and thus the effort required for these operations cannot be estimated.

The existing methodologies of software size measurements measure only a few features of a few components and try to estimate the total software size with the help of some multipliers based on type/field of applications and past experience with similar projects. Effort estimation done in this manner may be inaccurate in most of the cases.

Different skills and expertise may be needed for different activities of the software life cycle; for example, for an application which uses huge amount of data deploying databases, database skills would be required. Hence, it is necessary/desirable to know the size and complexity of different components of the software which can help in project planning activities from the point of view of human expertise and skills required.

Real effort depends on many factors such as expertise, experience, knowledge, productivity, and efficiency of the project team members but the average effort which has, more or less, approximate fixed proportionate relationships with the type of components to be developed, tested, and maintained can be calculated taking into consideration the average productivity, efficiency, and knowledge.

Static and dynamic (run-time) characteristics of any software application may be different. For example, in a program, there may be one disk memory read operation which is in a loop of one thousand times. While counting the Function Points

[4]

for the memory read operation, it will be counted as one Function Point

[4]

which is correct from the point of view of software development because it will lead to the effort for writing the statement(s) for one such operation, but at run-time, it will create high disk memory read traffic. If it is desired to assess the run-time characteristics based on the Function Points

[4]

, careful selection of the right kind of parameters (Function Points

[4]

) will be required.

Real run-time performance characteristics can best be obtained by capturing data at real run-time and analyzing that to find out what type of operations are being performed because the analysis based on static structure of data may not indicate the true performance due to the presence of decision operations. For example, if in a program there is one decision statement which leads to many:

memory data write operations if it is evaluated true;

data output operations for data display if it is evaluated false;

and if, at the execution time, the possibility of its being true is about 75%, the result will be high memory write traffic in about 75% of the cases and high output traffic for data display in the other 25% of the cases whenever the program is run. Based on the static structure analysis only, we will assess the program to have high memory as well as high output traffic which is also correct from the point of view of design because care will have to be taken to provide suitable design for both high memory traffic as well as high output traffic since both the situations can occur.

Table 1 Software Constituents' Approximate Relative Magnitude (Size) in Different Applications Sub-programs

Approximate Relative Magnitude (Size) of Some Software Constituents in the Sub-programs of Two Different Applications

Sl. No.

Software Application Sub-program

Memory Read/Write Operations

User Interface Input/ Output Operations

Message Communication with Internal Modules, External Application Programs

Functionality Execution: Computational Operations

Functionality Execution: Logical Operations

Functionality Execution: Actions, Decisions, Repeat Operations, Execution Flow Control Operations

Functional Data Size and Complexity: Diversity, Variety and Width (Number of Classes, Their Attributes and Fields)

1.

Telecom Call Handling: Signaling

Very low

High

High

Very low

Low

High

Medium

2.

Telecom Call Handling: Subscriber Data

High

Very low

Medium

Very low

Medium

High

High

3.

Telecom Call Handling: Routing

High

Very low

Medium

Medium

High

High

High

4.

Radar: Input Data

Low

High

High

Low

Low

Low

Medium

5.

Radar: Image Extraction

Low

Low

High

High

High

High

Medium

6.

Radar: Filtering

Low

Low

High

High

High

High

Medium

7.

Radar: Output Image

Medium

High

High

Low

Low

Low

Medium

Table 2 Software Constituents' Approximate Relative Magnitude (Size) in Different Applications

Approximate Relative Magnitude (Size) of Some Software Constituents in a Few Applications

Sl. No.

Software Application

Memory Read/Write Operations

User Interface Input/Output Operations

Message Communication with Internal Modules, External Application Programs

Functionality Execution: Actions, Decisions/ Repeat/Execution Flow Control Operations, Computational/Logical Operations

Functional Data Size and Complexity: Diversity, Variety and Width (Number of Classes, Their Attributes and Fields)

1.

Telecom Call Handling

Low

Medium

Medium

High

High

2.

Telecom Billing

High

Low

Low

High

High

3.

Video Games

Low

High

Low

High

Medium

4.

ERP – Inventory, Sales, Marketing, HR Management

High

High

High

High

Very high

5.

Radar – Image Extraction, Filtering, Input, Output

Low

High

Medium

High

High

6.

Online Shopping

High

High

Medium

Low

High

7.

Data Warehousing

High

Medium

Medium

High

Very high

8.

Text Processing

High

High

Low

Low

Low

9.

Computer Numerical Control (CNC) Machine

High

High

Low

High

Medium

1.4 Introduction to the Functional Software Size Measurement Methodology with Effort Estimation and Performance Indication (FSSM)