105,99 €
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:
Seitenzahl: 705
Veröffentlichungsjahr: 2017
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.
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.
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
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
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]
.
Cover
Table of Contents
Preface
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
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.
“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.
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.
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).
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.
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
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.
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.
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.
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