1 of 51

From Software ConOps to ROM

in Six Easy Steps

Carol Dekkers, CFPS (Fellow), PMP, CSM Dan French, CFPS (Fellow) PMP, CSM

President, Quality Plus Technologies, Inc Domain Expert, COBEC

Office: +1 813-816-1329 Office: +1 571-225-0380

Dekkers@qualityplustech.com dfrench@cobec.com

Quality Plus Technologies, Inc.

2 of 51

2

U.S. expert and project editor for ISO/IEC JTC1 SC7 SW Engineering standards. IFPUG Past President & committee chair (Industry Standards), ICEAA Board Member

Independent consultant, author and speaker (30+ countries) with US & international clients

ICEAA 2022 Educator of the year & Lead Author of CEBOK-S; o 2023 Global Leader in Consulting; 2022 IFPUG Honorary Fellowl

Certified FP Specialist (CFPS-Fellow), SCEC, Certified Scrum Master (CSM), PMP, P.Eng.

Resides in FL, USA. Interests include: festival event & volunteer management, tennis, travel, craft beverages and gourmet food

Highlights - Carol Dekkers, _{PMP, CFPS (Fellow), P.Eng. CSM}

Quality Plus Technologies, Inc.

3 of 51

Highlights - Dan French, _{PMP, CFPS (Fellow), CSM}

B.S. in Economics from Virginia Tech
Graduate of the Chubb Institute Top Gun Program
Over 20 years experience in software cost estimation
Counting function points for 24 years and been a Certified Function Point Specialist (CFPS) for 22 years (IFPUG Fellow)
Experience in a number of estimation techniques and tools including SEER-SEM, COCOMO, SLiM, Delphi, and Estimating by Analogy
Certification Chair for the International Function Point Users Group (IFPUG)
Recent Certification Director for the IFPUG Board of Directors
Former Chairman of the IFPUG Functional Software Sizing Committee (FSSC)
GAO Agile and Cost guides expert team member
Project Management Institute (PMI) Project Management Professional (PMP)
Agile Alliance Certified SCRUM Master (CSM)

3

Quality Plus Technologies, Inc.

4 of 51

Topics

Software development cost drivers

Software size
Productivity

Process to create a ROM from early docs (e.g., Concept of Operations (ConOps))

6-steps (assumes knowledge of Functional Size)

Case study
Conclusion

4

Quality Plus Technologies, Inc.

5 of 51

A. Software Development Cost Drivers¹

Software Size¹

Size of the development (scope)
An important cost driver
Key measures of size:

Physical size
Functional, and �non-functional size
Relative effort size
Others (requirements, RICEFW)

Productivity

Represents the speed at which software can be developed, … often output size /input effort
Non-linear relationship (diseconomy) with size
Productivity is based on:

Software complexity
Development team capability
Schedule (duration constraints)

5

Cost drivers are variables in an analogy (e.g., effort per size measure) or parametric, regression-based CER (cost estimating relationship) where effort is estimated as a function of one or more explanatory variables

Reference: ICEAA CEBoK-S Lesson 3: Cost Drivers

Quality Plus Technologies, Inc.

The two primary cost drivers, or elements that influence cost, associated with developed software are size and productivity.

Size (separate sub-lesson): See Lesson X:

Software size, which is known colloquially to many by its popular measures. Source Lines of Code (SLOC) or Function Points (FP), is a measure of how big is the software development effort and typically represents the software size under development. Size can be measured in a number of different ways and expressed with a commensurate number of units of measure Because software size is one of the most significant drivers of software costs, it is critical that the software cost estimator understands what a software size and its units of measure represent. We provide an overview with ample backup slides of the most widely used measures of software size, together with consistency considerations, and a series of questions for the software cost estimator to ask. The SCEBoK goal is for a software cost estimator to ask the right questions to ensure the software size estimate is credible, as complete as possible at the time of the estimate, and aligns with the technical baseline. SCEBoK recommends using Effective Size to account for reused and adapted code.

In software development, size is the most important cost driver, and typically, size has a non-linear, but direct relationship to development effort. In other words, the larger the software, typically, the larger the amount of effort it will take to develop, but the relationship is not as simplistic as may first appear depending on economies or diseconomies of scale, as outlined here and in the next lesson, Lesson 4, on custom Cost Estimating Relationships (CER.)

The best software size method for development is whichever one provides the most complete and accurate cost-able size based on the software product being developed. When it comes to maintenance, other factors become relevant such as number of users, number of installations, frequency of use, etc..

Note: The discussion of software size and the methods and options for measuring it are included in a sub-lesson, Lesson X.

Productivity (separate sub-lesson): See Lesson Y.

“Productivity” has various meanings in software development as both a concept and a measure.

In the productivity lesson, we define what productivity is as both a concept and a measure, discuss what it does and does not cover pertaining to software development, and outline the key considerations when using productivity factors. We also explore the major factors that drive productivity – complexity, capability, and schedule.

Productivity is a measure of efficiency and represents the speed at which software can be developed. Productivity is usually expressed as a ratio of either units of output software size per unit of effort, or the inverse.

Productivity is influenced by a number of factors including the complexity of the development effort (both the complexity of the product and the complexity of the work), the capability of the development team, and time or schedule constraints. Productivity can be derived through a custom Cost Estimating Relationship, CER, or using a general CER such as the COCOMO II equation.

With the analogy technique, we start out with an appropriate productivity rate based on a historical analogous program, assume a linear relationship between size and effort, and estimate development effort with an equation of the type:

Effort (in hours or person months depending on the units of productivity) = Size * Productivity rate.

To illustrate, consider that a software development effort, sized as 150 units of size, can be developed into software at a rate of 1.5 units per person hour (based on a completed similar project with comparable complexity, team capability and minimal schedule constraint.) The effort would be E = 150 units / 1.5 units per person hour = 100 person hours.

Productivity is a function of size, complexity, capability, schedule, and effort – and is influenced by economies, diseconomies or constant linear scale. As we’ve state, for the analogy estimating technique, size and productivity are assumed to have a constant linear relationship with effort.

We have two additional review slides: one on Software Size and one on Productivity that follow this one.

We will cover the software sustainment cost factors in Lesson 5.

6 of 51

B. ConOps to ROM 🡪 6 steps

6

Step 0:

Concept of Operations document

ConOps

Step 1: SW Boundary

Step 2: SW FUR

Identify DEV Scope

Step 3: Size the LF

Step 4: Size the EP

Estimate SW Size (SFP)

Step 5: Historical Productivity

Step 6. ROM: effort, cost, schedule

Create ROM Estimate

Quality Plus Technologies, Inc.

7 of 51

Step 0: Concept of Operations (ConOps)_/2

Concept of Operations (ConOps) for Program

xxx

7

A conceptual description of the operational part of the system solution.
The operational part of the system solution is that part of the solution which is intended to meet the requirements on the system which serve an end-use purpose. �Source: https://www.ppi-int.com/resources/systems-engineering-faq/what-is-the-difference-between-an-ocd-conops/

Contains a high-level description of software functional requirements (and other requirements)

Quality Plus Technologies, Inc.

8 of 51

Concept of Operations (ConOps)

8

ConOps, EPICS and other documents outline HIGH-LEVEL, EARLY requirements

Quality Plus Technologies, Inc.

9 of 51

Identify DEV Scope_/2

Step 1: Software Boundary:

Conceptual line between the software under analysis and its users- IFPUG
Most crucial step in the software sizing process
ConOps could contain MULTIPLE pieces of software to be developed 🡪 separate size estimates

9

Quality Plus Technologies, Inc.

10 of 51

Identify DEV Scope

Step 2: SW Functional User Requirements (FUR): -

A sub-set of the user requirements that describe what the software shall do, in terms of tasks and services.
Look at data (stored or referenced) and the processes that move or manipulate data (elementary processes):
Examples:

Data entry processes (CRUD, batch data entry)
Business processes (approvals, payments, disbursements, audits, orders, consolidation of data, etc.)
Inputs from and outputs to “users”

Exclude non-functional and technical requirements*

10

Quality Plus Technologies, Inc.

Note that FUR are distinct from, and should not be mistaken for, other types of software requirements: technical, quality, or non-functional requirements (NFR), that describe other aspects of the software including how the software must perform (NFR), the quality of the software (also NFR), the development environment (technical) or the programming language. A few further examples of software requirements that are NOT functional requirements include: the hardware or hosting platform(s), quality requirements, response time (to meet service level agreements), data capacity, industry or organizational standards and policies, and processing loads. Many of these requirements can be measured using a different methodology and units of measure, such as the IFPUG Software Non-Functional Assessment Process (SNAP) and associated SNAP points.

11 of 51

Estimate Software Size

CEBoK-S: Software size (Lesson X)

Software Size¹

Size of the development effort
An important cost driver
Key measures of size:

Physical size
Functional, and non-functional size
Relative effort size
Others (requirements, RICEFW²)

11

Functional size:

the size of the functional user requirements
Can be measured at delivery
Can be estimated during development
Multiple standardized methods & units (some ISO)
For this presentation 🡪 International Function Point User Group (IFPUG) Simple Function Points (SFP)

Quality Plus Technologies, Inc.

12 of 51

What is Functional Size?

Software requirements�

(Note: ALL types of software requirements impact cost and duration)

2. Non-Functional Requirements (HOW GOOD)

3. Technical Requirements (HOW TO BUILD)

Functional Size

(in units of FP or SFP)

Non-functional and technical requirements are evaluated (sized) as part of productivity (complexity, skills, etc.) when selecting analogy or via IFPUG SNAP or VAF methods

1. Functional (User) Requirements (WHAT does SW do?)

Quality Plus Technologies, Inc.

13 of 51

History of Functional Size �(Function Points)

Mid-1970’s: Function Points (FP) developed at IBM as an alterative to Source Lines of Code (SLOC)
1984-1986: Formation of the International Function Point Users Group (IFPUG) and publication of IFPUG FP Counting Practices Manual v1.0
1998: ISO/IEC 20926 (IFPUG FP) and other ISO standards for Functional Size
2010: IFPUG publishes v4.3.1 - current version. Assigns FP to 5 function types and 3 complexities (low, avg, high) based on detailed software requirements. At the same time: Simple FP v1.01 introduced by Dr Roberto Meli in Italy.
2019: IFPUG acquires/merges with Simple FP association
2021: IFPUG Simple FP (SFP) v2.1 (= IFPUG 4.3.1 simplified)�with 2 function types (one complexity) – especially useful for early estimates. (Compatible units: Simple FP)

13

Quality Plus Technologies, Inc.

14 of 51

IFPUG Simple Function Points (SFP) v2.1

Simplified (and standardized) method fully compatible with IFPUG v4.3.1
Functional size based on two functional components (single complexity):

Logical files (Data Groups) 🡪 7 SFP each
Elementary Processes 🡪 4.6 SFP each

Especially suitable for early software sizing (when details are not yet known)

14

Quality Plus Technologies, Inc.

15 of 51

IFPUG FP v4.3.1 �versus IFPUG SFP v2.1

15

Elementary Processes EP

(4.6 SFP each)

Logical (data) Files LF�(7 SFP each)

IFPUG FP v4.3.1

IFPUG Simple FP v2.1

To “count” IFPUG FP 🡪 Identify function type (ILF, EIF, EI, EO,EQ) 🡪Evaluate DET, RET, FTR 🡪 Determine functional complexity (Low/Avg/High) 🡪 Translate # FP

To “estimate” IFPUG SFP 🡪 Identify Logical Files & Elementary Processes

🡪 Translate # FP

Quality Plus Technologies, Inc.

16 of 51

Estimate Software Size

Step 3: Size the Logical files (LF)

functionality provided to the user to meet internal and external data storage requirements <Data group>
user recognizable group of logically related data or control information maintained and/or referred within the boundary of the application being measured.”
The term file here does not mean physical file or table. In this case, file refers to a logically related group of data and not the physical implementation of those groups of data.

Each LF = 7 SFP

16

Quality Plus Technologies, Inc.

17 of 51

Estimate Software Size

Step 4: Size the Elementary Processes (EP)

smallest unit of activity, which is meaningful to the user, that constitutes a complete transaction, it is self-contained and leaves the business of the application being measured in a consistent state

Examples include :

CRUD (Create, Read, Update, Delete) = 4 Elementary Processes
Report = 1 elementary process
Display data = 1 elementary process

Each EP = 4.6 SFP

17

Quality Plus Technologies, Inc.

18 of 51

Estimate Software Size

Step 3: Size the Logical Files

All data whether internal (maintained) or external (referenced) = 7 SFP

Step 4: Size the Elementary Processes (EP)

All types of transactional functions (inputs, outputs, queries) = 4.6 SFP

18

Data out

Data In

c

Quality Plus Technologies, Inc.

19 of 51

Create ROM Estimate

Step 5: Historical data productivity

Find analogous data
Similar project(s), normalize data

Step 6: ROM (Rough order of magnitude) using CER*

Estimate effort (based on size & historical productivity)
Estimate cost (from effort)
Estimate sched duration (from effort)

19

Step 5: Historical productivity

Step 6: ROM Estimated effort

ROM Estimated cost

ROM Estimated schedule (duration)

* CER = Cost Estimating Relationship

Quality Plus Technologies, Inc.

20 of 51

Historical Productivity Data

Use organizational data (if available) 🡪 OR obtain industry data from other sources such as ISBSG D&E and/or commercial tool repositories or COCOMO II
Key to successful (analogous) estimating:

“Similar” data
Analyzed, & normalized by adjusting for driver factors (size, productivity)

Multiple matched projects 🡪 create composite analogy
May need to also adjust for development “scope”

20

Quality Plus Technologies, Inc.

21 of 51

Create ROM Estimate

Step 5: Historical Productivity Data

Find similar project(s) in historical data

Similar functional size (range of applicability)
Similar productivity factors:

Complexity (non-functional)
Developer capability
Schedule compression (if applicable)
Development language, approach, etc.

May need to adjust for scope

Industry data sources:

SRDR (US DoD) or own data
International Software Benchmark Standards Group (ISBGS) Application Development & Enhancement data (www.isbsg.org)
Commercial tool datasets (SEER-SEM, TrueProject, SLIM, etc.)

21

Quality Plus Technologies, Inc.

22 of 51

Match / adjust scope of activities in Historical data

22

Stake-holder Req.	System Req.	System Arch. Design	SW Req.	SW Arch. Design	SW Detail Design	SW Construction	SW Integration	SW Qual. Testing	System Integration	System Qualification	System Installation	System Acceptance

SW Development “end to end”

System Development “end to end”

Design, Code, Test, Integration

(DCTI)

Quality Plus Technologies, Inc.

23 of 51

Historical ISBSG D&E Repository

In lieu of historical data, can use the ISBSG Development & Enhancement (D&E) Repository (2020)¹
Typical database filters for selecting analogous projects

Data Quality Rating 🡪 A or B
Size (range close to your SFP functional size estimate)
Year of Project
Industry Sector and Organization Type
Application Group and Application Type.
Development Type. New development or enhancement.
Count approach.🡪 IFPUG 4.0 and above

23

ISBSG Development and Enhancement (D&E) Repository, Corporate Release 2020 R1, August 2020, with 9,592 completed projects. Newer versions may be available see www.isbsg.org

Quality Plus Technologies, Inc.

The ISBSG D&E Repository (2020) is an Excel spreadsheet that contains 9,592 records (rows) of completed software development and enhancement projects. Each record contains 253 data fields, but not all of them have a complete set of data. The completeness of the data records is indicated by the Data Quality field, depicting whether they contain complete and reliable data (Data Quality = A), a majority of completed data (Data Quality = B), or lesser quality data (Data Quality levels C and D.) It is critical that the potentially analogous records we select contain at a minimum the sizing, effort, and categorizations that match FFS as depicted by the fields we’ve chosen to filter on in the above slide:

Year of Project: while this is not the most important field, because the FFS development will follow an agile-hybrid, iterative paradigm, we do not want to include projects completed before iterative development was mainstream (i.e., prior to 2010);

Industry sector and organization type: These may be important discriminators if our filtered records dataset is too large or varied;

Application group and application type: may also be important discriminators in the same way as industry sector and organization type;

Development type: as we outlined in both approach #1 and approach #2, it is important to be aware of whether the development is for brand new software (i.e., all functionality is new) or if it is an enhancement project to enhance existing software (i.e., the software will be built on the base of an existing software where interfaces are already in place)

Count approach: because the ISBSG D&E repository features primarily functional size units of measure, and the various functional size measurement units are not equal, and may not be convertible to each other, we need to ensure that we select the same units of software size as FFS

24 of 51

Create ROM Estimate

Step 6: ROM Estimate effort, cost & schedule (duration)

Linear analogy (or applicable CER/SER) within range of applicability:

Estimated effort (hours) = Estimated functional size * historical effort (hours) / historical functional size
Estimated Cost $ = Estimated effort (hours) * labor rate/hour
Estimated Schedule (duration) months = Estimated effort (hours) / (hours/person month * team size)
May want to iterate/re-estimate functional size (SFP) using 1-2% growth factor per schedule month (ref: Capers Jones)

Cross check using COCOMO II /commercial tool / other
Acceptable variance range between estimate and cross check should be between 10 – 20% (maximum)

24

Quality Plus Technologies, Inc.

25 of 51

ConOps Case Study

25

Adapted from ICEAA CEBoK-S Lesson X (Size) – Assume a ConOps document outlined SW scope

Quality Plus Technologies, Inc.

26 of 51

C. ConOps Case Study �Case Study

26

Adapted from ICEAA CEBoK-S Lesson X (Software Size)
High level use case list & diagram for Course Registration System – without details
Software will provide functions needed to maintain professor, student, and course information as well as class registration functions
Note: used only high-level diagram and description (ICEAA CEBoK-S case study is more detailed 🡪 Different estimated size)

Quality Plus Technologies, Inc.

27 of 51

Identify DEV Scope�Step 1: Identify Software Boundary(ies)

27

Boundary

In same s/w Boundary

ONE software boundary identified

Quality Plus Technologies, Inc.

28 of 51

Identify DEV Scope: �Step 2: Identify FUR

28

Req #	Requirement (Use Case)
1.	Logon (by all users)
2.	Maintain professor information (by the registrar)
3.	Select courses to teach (by professors)
4.	Maintain student information (by the registrar)
5.	Register for course(s) (by students)
6.	Close registration (by the registrar)
7.	Submit grades (by professors)
8.	View report card (by students)
Note:manual or non-functional software reqs could also be in ConOps

Functional?

Quality Plus Technologies, Inc.

Note that FUR are distinct from, and should not be mistaken for, other types of software requirements: technical, quality, or non-functional requirements (NFR), that describe other aspects of the software including how the software must perform (NFR), the quality of the software (also NFR), the development environment (technical) or the programming language. A few further examples of software requirements that are NOT functional requirements include: the hardware or hosting platform(s), quality requirements, response time (to meet service level agreements), data capacity, industry or organizational standards and policies, and processing loads. Many of these requirements can be measured using a different methodology and units of measure, such as the IFPUG Software Non-Functional Assessment Process (SNAP) and associated SNAP points.

29 of 51

Estimate Software Size�Step 3: Size the Logical Files (LF)

29

#	Use case for Course Registration System
1.	Logon (by all users)
2.	Maintain professor information (by the registrar)
3.	Select courses to teach (by professors)
4.	Maintain student information (by the registrar)
5.	Register for course(s) (by students)
6.	Close registration (by the registrar)
7.	Submit grades (by professors)
8.	View report card (by students)

USER

PROFESSOR

CATALOG OF COURSES CATALOG

STUDENT

COURSE SESSION (Incl Grades)

ESTIMATE

LF = 35 SFP

Quality Plus Technologies, Inc.

30 of 51

Estimate Software Size�Step 4: Size the Elementary Processes

30

#	Use case for Course Registration System
1.	Logon (by all users)
2.	Maintain professor information (by the registrar)
3.	Select courses to teach (by professors)
4.	Maintain student information (by the registrar)
5.	Register for course(s) (by students)
6.	Close registration (by the registrar)
7.	Submit grades (by professors)
8.	View report card (by students)

Logon = 1 EP

CRUD = 4 EP

Select= 1 EP

CRUD = 4 EP

Register= 1 EP

Close = 1 EP

Submit = 1 EP

Rpt card = 1 EP

14 EP * 4.6 SFP each

= 65 SFP

TOTAL EST SIZE = 35 + 64.4 = 100 SFP

Quality Plus Technologies, Inc.

31 of 51

Create ROM Estimate

Estimated functional size = 100 SFP

SFP LF = 35 SFP
SFP EP= 64.4 SFP

Estimated effort
Estimated cost
Estimated schedule (duration)

31

Step 4: Estimated functional size

Step 5: Historical productivity

Step 6: ROM Estimated effort

ROM Estimated cost

ROM Estimated schedule (duration)

Quality Plus Technologies, Inc.

32 of 51

Create ROM Estimate�Step 5: Historical data (analogy)

Industry data sources:

SRDR (US DoD) or own data
International Software Benchmark Standards Group (ISBGS) Application Development & Enhancement data (www.isbsg.org)
Commercial tool datasets (SEER-SEM, TrueProject, SLIM, etc.)

Find similar project(s) in historical data

Similar functional size (range of applicability) 🡪 approx. 100 SFP
Similar productivity factors:

Complexity (non-functional) 🡪 MIS
Developer capability 🡪 Average
Schedule compression (if applicable) 🡪 N/A
Development language, approach, etc.

May need to adjust for scope 🡪 See next page

32

Quality Plus Technologies, Inc.

33 of 51

Create ROM Estimate�Step 5: Historical data (analogy)

In lieu of historical data, we can use the ISBSG Development & Enhancement (D&E) Repository (2020)¹
For case study 🡪 2007 D&E Repository version (exemplar data)
Typical database filters for selecting analogous projects

Data Quality Rating = A or B
Size = 75-200 FP
Industry Sector and Organization Type
Application Group and Application Type.
Development Type. New development
Count approach. Select IFPUG 4.0 and higher

COULD USE ADDITIONAL FILTERS IF TOO MANY PROJECTS ARE FOUND

ISBSG Development and Enhancement (D&E) Repository, Corporate Release 2020 R1, August 2020, with 9,592 completed projects

33

Quality Plus Technologies, Inc.

The ISBSG D&E Repository (2020) is an Excel spreadsheet that contains 9,592 records (rows) of completed software development and enhancement projects. Each record contains 253 data fields, but not all of them have a complete set of data. The completeness of the data records is indicated by the Data Quality field, depicting whether they contain complete and reliable data (Data Quality = A), a majority of completed data (Data Quality = B), or lesser quality data (Data Quality levels C and D.) It is critical that the potentially analogous records we select contain at a minimum the sizing, effort, and categorizations that match FFS as depicted by the fields we’ve chosen to filter on in the above slide:

Year of Project: while this is not the most important field, because the FFS development will follow an agile-hybrid, iterative paradigm, we do not want to include projects completed before iterative development was mainstream (i.e., prior to 2010);

Industry sector and organization type: These may be important discriminators if our filtered records dataset is too large or varied;

Application group and application type: may also be important discriminators in the same way as industry sector and organization type;

Development type: as we outlined in both approach #1 and approach #2, it is important to be aware of whether the development is for brand new software (i.e., all functionality is new) or if it is an enhancement project to enhance existing software (i.e., the software will be built on the base of an existing software where interfaces are already in place)

Count approach: because the ISBSG D&E repository features primarily functional size units of measure, and the various functional size measurement units are not equal, and may not be convertible to each other, we need to ensure that we select the same units of software size as FFS

34 of 51

Create ROM Estimate�Step 5: Historical data scope of activities

34

Stake-holder Req.	System Req.	System Arch. Design	SW Req.	SW Arch. Design	SW Detail Design	SW Construction	SW Integration	SW Qual. Testing	System Integration	System Qualification	System Installation	System Acceptance

SW Development “end to end”

System Development “end to end”

Design, Code, Test, Integration (DCTI)

Quality Plus Technologies, Inc.

35 of 51

Create ROM Estimate�Step 5: Historical data scope of activities

Attribute	Student Registration	Mapping Required / Criteria for Inclusion
Data Quality	A or B	Include data points that have all or a majority of fields provided for the project – that is data quality = A or B only
Size	75-200 FP	Limited by ISBSG database version… >2000
Industry Sector, Organization Type	Any sector and type	Not used as an initial filter, unless we need to further refine our dataset
Application Group and Application Type	Not particular	Include only data points that map to the Application Group: Business Application, and Application Type: Application software or Financial
Development Type	New Development	Include only data points that are new development
FP Counting approach	IFPUG 4+	Include only data points that have sizing units of measure IFPUG 4.0 or newer (compatible with current IFPUG 4.3.1)

Filter the ISBSG D&E (2007 version) records

35

Quality Plus Technologies, Inc.

36 of 51

Create ROM Estimate�Step 5: Historical data (analogy)

After filtering based on our criteria, then normalizing (as necessary) the activities and effort,: 6 potentially analogous records that match

We want to further refine the selection to find the most analogous project. We selected and highlighted two projects (see 1 and 2) as our potential best-fit analogous projects. (#2 would need to normalize for planning)
Note: an alternate approach would be to use these 6 records as the basis for a parametric CER. See ICEAA CEBoK-S lesson 4 for details.

2

1

36

Quality Plus Technologies, Inc.

Filtering ISBSG D&E records with our chosen criteria returns us a set of 11 matching records.

From this list, our next step would be to examine and, if necessary, normalize the data to ensure that all development team effort is included, that it covers the full development phases, (recall that FFS will cover software development end-to-end), and that all records contain data that indeed matches the FFS. Some of the normalization of data was already done by the ISBSG data manager who maintains the D&E repository, but we need to be sure that we can answer the questions: what’s in the numbers?

After this analysis and normalization, we have the same 11 potential data points we can now use to select the best-fit analogy for FFS.

At this point, we could use regression on this data set to derive a custom CER, following the steps outlined with Approach #1: Parametric (Derived CER), however, we are interested in finding an analogous project that matches our FFS development effort.

We could do this by observation and examination of the various data records, notably those within a similar sizing range, that matches the most criteria of FFS. The result we chose is included on the next page and was chosen based on Java programming language, an iterative development paradigm, and a windows based operating environment.

37 of 51

Create ROM Estimate�Step 6: ROM Effort, Cost, Schedule

Identify any applicable CERs/SERs (linear analogy):

Estimate Effort (hours) = SFP Size * ISBSG analogy effort (hours) / ISBSG analogy size

Est Effort (hours) = 100 SFP * 4599 hours / 188 FP = 2446 hours
Note: using the average of 152 hour/PM = 16 Person Months

Estimate Cost = Estimated effort (hours) * labor rate per hour

Assumed labor rate = $60 USD / hour
Cost = $146,760

Estimate Duration (months) = Estimated effort (hours) / (hours/PM * team size) - assumed team size = 2 people

Duration (months) = 2446 hours / (152 hours/PM *2 people) = 8 months
ISBSG project elapsed time = 9 months (see previous page)

37

Quality Plus Technologies, Inc.

38 of 51

Create ROM Estimate�Step 6: ROM Effort, Cost, Schedule

Can include data for Effort per SFP, SFP/Mo, $/SFP
Based on the adjustments made to the historical data, CERs, and SERs, the estimate can be developed.
Need to cross check using COCOMO II or commercial tool or other estimating methods
Typically, acceptable variance range between estimates should be between 10 – 20% (maximum)

38

Quality Plus Technologies, Inc.

39 of 51

Cross-check ROM Estimate�with COCOMO II

COCOMO II™ web tool http://softwarecost.org/tools/COCOMO/

Created by Ray Madachy at the Naval Postgraduate School. Email: rjmadach@nps.edu

39

Assumptions:

100 FP (Selected Java)
Labor rate = $ 9120/PM (152 hours/PM * $60/hour)
All nominal settings

Quality Plus Technologies, Inc.

40 of 51

COCOMO II cross check results

40

Results:

Est Effort (Elaboration + Construction) = 18.4 PM *152 hours/PM = 2798 hours
Est Cost = $167,814
Est Schedule = 9.3 months (with 1-2.4 team size)

Quality Plus Technologies, Inc.

41 of 51

ROM Estimate & COCOMO II Cross-check�Summary

41

ROM estimate (based on Est Size = 100 SFP)	Analogy Estimate	COCOMO II Cross Check	Variance (%)
Estimated Effort (in hours and in PM)	2446 hours 16 PM	2798 hours 18.4 PM	14.4%
Estimated Cost ($)	$147 K USD	$167 K USD	13.7%
Estimated Schedule (months)	8 -9 months (2 people)	9.3 months (team size varied from 1-2.4 people)	5-16%

Additional cross checks/ next steps: (if this was a real ROM estimate)

Adjust Functional Size with 1-2% growth per schedule month
Research other applicable historical data and CER/SERs:

U.S. Dept of Homeland Security (DHS) CAD CERs/SERs (Dr. Wilson Rosa)
ISBSG D&E repository 2022 (much larger database)
Commercial tools

Quality Plus Technologies, Inc.

42 of 51

Summary: ConOps to ROM 🡪 6 steps

42

Step 0:

Concept of Operations document

ConOps

Step 1: SW Boundary

Step 2: SW FUR

Identify DEV Scope

Step 3: Size the LF

Step 4: Size the EP

Estimate SW Size

Step 5: Historical Productivity

6. ROM: effort, cost, schedule

Create ROM Estimate

Quality Plus Technologies, Inc.

43 of 51

Conclusions

IFPUG functional size methodologies (IFPUG 4.3.1 and SFP 2.1) are tried-and-true, standardized methods
Early size estimates are possible from ConOps and high-level requirements!
Use the IFPUG Simple Function Points (SFP) v2.1 when :

high-level ConOps or EPICS or user stories (no details)
cost analysts are not trained/certified
ROM estimates are acceptable

NOW is the best THE TIME to start collecting <good> historical data:

Actual IFPUG FP counts (for delivered software)
Actual software development effort, cost and schedule
Ensure you also record Productivity Factors and Contextual data

43

Quality Plus Technologies, Inc.

44 of 51

Resources

International Cost Estimating and Analysis Association (ICEAA) https://www.iceaaonline.com/ -

CEBoK-S Lesson X: Software Size includes authoritative software sizing (and full case study using multiple functional sizing methods)
Extensive techniques for estimating software programs (including hybrid)

International Function Point User Group (IFPUG) http://ifpug.org/

IFPUG Function Point Analysis v4.3.1
IFPUG Simple Function Points (SFP) v2.1

International Software Benchmarking Standards Group (ISBSG) http://www.isbsg.org D&E and Maintenance repositories
Carol (dekkers@qualityplustech.com and Dan (dfrench@cobec.com)

44

Quality Plus Technologies, Inc.

45 of 51

�Carol Dekkers, CFPS (Fellow), PMP, CSM Dan French, CFPS(Fellow), PMP, CSM

President, Quality Plus Technologies, Inc Domain Expert, COBEC

Office: +1 813-816-1329 Office: +1 571-225-0380

Dekkers@qualityplustech.com dfrench@cobec.com

THANK YOU FOR YOUR TIME AND INTEREST

Quality Plus Technologies, Inc.

46 of 51

CEBoK-S Case Study – See Lesson X: Software Size

46

Quality Plus Technologies, Inc.

47 of 51

History of Simple Function Points

2009: Dr. Roberto Meli of DPO introduces the Early & Quick Function Points (E&Q FP) based on the IFPUG method. New concepts:

Generic Functions
Typical Process (TP) (CRUD)
Generic Process (GP)
Macro Process (MP)

2010: Meli refined E&Q FP into Simple Function Points (SiFP) with 2 generic function types:

Elementary Process (EP)
Logical File (LF)

2019: IFPUG acquired the SiFP method
2021: IFPUG releases IFPUG Simple Function Point (SFP) manual v.2.1

47

Quality Plus Technologies, Inc.

48 of 51

IFPUG FP vs Simple FP

International Function Point Users Group (IFPUG) SFP v2.1 (2021)
Originally developed by Dr. Roberto Meli/Italian researchers v1.1 (2010))
Simplifies functional sizing into two types of functions:

Generic elementary processes (transactional functions)
Generic logical files (data groups)

48

Quality Plus Technologies, Inc.

49 of 51

IFPUG FP & SFP Measurement Process

49

Quality Plus Technologies, Inc.

50 of 51

Backup: IFPUG FP vs IFPUG SFP (1 of 2)

50

Concept	IFPUG FP	IFPUG SFP
IFPUG standardized glossary	Yes	Yes, same
Intent to measure functional size based on FUR	Yes	Yes, same
Method owned by IFPUG	Yes	Yes
IFPUG FP measurement steps: 1. Gather available documentation 2. Purpose/scope/boundary, identify FUR 3a. Measure data functions 3b. Measure transactional functions 4. Calculate functional size 5. Document and report	Yes, but steps 3a and 3b involve additional sub-steps: subclassification into 3 types of transactional functions and 2 types of data functions, and a complexity classification (into Low, Average, or High) to get FP values	Yes
Base functional components (BFC): transactional functions and data functions	Yes: Transactional functions are subdivided into EI, EO, EQ, and Data functions are subdivided into ILF, EIF	Yes: Transactional functions are called “Elementary Processes” and Data Functions are called “Logical Files”

Table 1: IFPUG FP compared to IFPUG SFP

Quality Plus Technologies, Inc.

51 of 51

Backup: IFPUG FP vs IFPUG SFP (2 of 2)

51

Table 1: IFPUG FP compared to IFPUG SFP

Number of different FP values allocated across function types	3 FP values allocated as Low, Average or High across 5 function types (total of 8 different values)	2 SFP values allocated, one each to two function types
Range of FP values by category	Transactional functions are worth between 3 and 7 FP depending on type and complexity. Logical files are worth 7 to 15 FP depending on type and relative complexity	All transactional functions are considered to be EP and assigned 4.6 SFP. All data functions are considered to be logical files and assigned 7 SFP
Unit of measure	Function Points (FP)	Simple Function Points (SFP)
Convertibility	1 FP = 1 SFP	1 SFP = 1 FP

Quality Plus Technologies, Inc.