Estimating SAP Software Development Projects Using a Customized Basic COCOMO Technique

Ivon Denzil Silvano

This article is about a customized version of the widely used software project effort estimation Basic COCOMO technique focusing on SAP software projects. The COCOMO (Constructive Cost Model) technique is a parametric function point based estimation technique developed by Barry Boehm which is widely used for software development estimation using open system technologies such as J2EE, JAVA, C++ etc. Currently there is no standardized estimating process for ABAP (the SAP programming language) development projects that can be combined with COCOMO for estimates. This paper bridges the gap and allows SAP Software Development estimation using COCOMO technique using standardized metrics based on ABAP.

Introduction

As the usage and industry penetration of SAP software in the ERP (Enterprise Resource Planning) world is increasing, the demand for more and more customized usage of SAP in the form of WRICEFs (Workflows, Reports, Interfaces, Conversions, Enhancements and Forms) has also increased. Companies are now looking at custom developments that help maximize their utilization of the standard SAP software. The need for custom development is to not only improve utilization but also gain organizational efficiency using the software that caters to the specific business requirements of the organization rather than just functioning as industry standard software.

SAP software development project estimation is a very critical piece since it is associated with heavy costs. The SAP (ABAP) resource cost is one of highest among software development technologies / programming languages. Apart from high costs risks, underestimation can lead to risk of project failure in cases where there is no additional budget available to successfully complete the project leaving the organization’s dependency on the same as a high risk. Proper estimation is also a key to make sure all aspects; related technologies etc. are covered to make the SAP development software a success. A traditional approach to estimation of such projects and the judgment of the SME (subject matter expert), without whom you could get incorrect estimation by the Project Manager.

Risk factors in high level judgment based estimation

• Risk of major deviation exists if SME is not very well versed with area (known unknowns, unknown unknowns)
• High level estimates can lead to miss out of areas which can be seen only via a deep dive
• Incorrect estimates can lead to actual budget exceeding planned budget
• Prolonged projects can lead to missing out critical business deadlines
• Using a non-standard scale for effort estimation can lead to incorrect estimates
• Overestimation can lead to relaxed timelines and procrastination with lesser work trying to stretch into a longer schedule thereby increasing costs unnecessarily

The Customized Basic COCOMO method covered in this paper will minimize the above risks using a parameter based estimation technique tailor-made for SAP (ABAP) development projects.

Estimation Methodology

Basic COCOMO Overview

The Basic COCOMO computes software development effort (and cost) as a function of program size. Program size is expressed in estimated thousands of source lines of code (KLOC).

COCOMO applies to three classes of software projects:

Organic projects - "small" teams with "good" experience working with "less than rigid" requirements

Semi-detached projects - "medium" teams with mixed experience working with a mix of rigid and less than rigid requirements

Embedded projects - developed within a set of "tight" constraints. It is also combination of organic and semi-detached projects.(hardware, software, operational, ...)

The basic COCOMO equations take the form

Effort Applied (E) = a_b(KLOC)^b_b [man-months]

Development Time (D) = c_b(Effort Applied)^d_b [months]

People required (P) = Effort Applied / Development Time [count]

Where, KLOC is the estimated number of delivered lines (expressed in thousands) of code for project. The coefficients a_b, b_b, c_b and d_b are given in the following table (note: the values listed below are from the original analysis, with a modern re-analysis producing different values):

Software project	ab	bb	cb	db
Organic	2.4	1.05	2.5	0.38
Semi-detached	3.0	1.12	2.5	0.35
Embedded	3.6	1.20	2.5	0.32

The Basic COCOMO is a good approach for quickly estimate of software costs. However it does not account for differences in hardware constraints, personnel quality and experience, use of modern tools and techniques, etc.

Application of Basic COCOMO

As the methodology of this article uses the Basic COCOMO method as a basis for estimation, the overall steps and flow are similar between the two approaches. It starts with the Rating Basis for each component (defined and adapted in the context of SAP projects), then using a weighting chart (Low, Medium, High) for each Component using Record Element Type / File Type Referenced and Data Element Type counts, this gives the Unadjusted Function Point (UFP) count. Once the weighting is applied to the count of each component, we get the estimation factors. A rating is then performed on 14 influencing factors giving each factor an influence value of 0 (no influence) to 5 (Essential). The Technical Complexity Factor (TCF) is then calculated using the standard equation TCF = 0.65 + 0.01 *DI (Degree of Influence), this finally gives the adjusted Function Point count = UFP * TCF.

In order to get the Software Lines of Code (SLOC) estimate, we use the QSM published estimates for ABAP (SAP programming language). We finally apply the COCOMO coefficients on the Function Point Count and SLOC to get the project effort.

Rating Basis

The Rating Basis has been defined in terms of what it means to ABAP (SAP) development projects rather than just a generalized software rating basis. This section defines what each element means in the SAP context and then maps it to each of the components showing which element is valid for which component(s).

Element Types

Record Element Type (RET):

A RET is user recognizable sub group of data elements within a Master File or an Interface. It is best to look at logical groupings of data to help identify them.

File Type Referenced (FTR):

A FTR is a file type referenced by a transaction. A FTR must also be a Master File or Interface.

Data Element Type (DET):

A DET is a unique user recognizable, non-recursive (non-repetitive) field. A DET is information that is dynamic and not static. A dynamic field is read from a file or created from DET’s contained in an FTR. Additionally, a DET can invoke transactions or can be additional information regarding transactions. If a DET is recursive then only the first occurrence of the DET is considered not every occurrence.

Components

External inputs (EI):

EIs are processes in which derived data passes across the boundary from outside to inside. For example in a SAP Financial Accounting System, enter an existing Vendor number

External outputs (EO):

EOs are processes in which derived data passes across the boundary from inside to outside. For example in a SAP Financial Accounting System, display a list of invoices of an existing Vendor in an ALV

External queries (EQ):

EQs are processes with both input and output components that result in data retrieval from one or more logical files. For example in a SAP Financial Accounting System, find and display what invoices are currently open for a Vendor

Internal log files (ILF):

ILFs are groups of logically related data that resides within the applications boundary and are maintained through external inputs. For example in a SAP Financial Accounting System, the Vendor Master database table

External log files (ELF):

ELFs are groups of logically related data that are used for reference purposes only, and which reside entirely outside the system. For example in a SAP Financial Accounting System, purchase order from SAP MM for a goods receipt Accounting Document

Below is the mapping table that links various components to elements in the SAP context, this serves as an example of the rating basis used for estimating SAP projects using basic COCOMO.

Weighting tables

EI, EO and EQ are rated based on FTR and DET. ILF and ELF are rated based on RET and DET. Rate each component as Low, Average or High, below tables show respective values for each set in round brackets "( )".

Below are the weighting tables for all 5 element pairs, these weightings are multiplied with the respective element counts and sum the same to get the UFP (Unadjusted Function Point count).

The example calculation below is for developing a hypothetical SAP accounting custom software report that should have the following features:

• Allows entering a vendor number on the screen
• Gives the option to fetch and display master data for the Vendor
• Contains and ALV list screen to display invoices associated with the Vendor
• Gives the option to fetch and display all open invoices for the Vendor as a list
• Gives the option to fetch purchase order from the SAP MM system for a goods receipt Accounting Document associated with the Vendor

Assuming that there are 2 each of the 5 components, that is External inputs (EI), External outputs (EO), External queries (EQ), Internal log files (ILF) and External log files (ELF); the table below shows the count of each element for each of the components.

The above table gives the Total Unadjusted Function Point Count (UFP) of 98.

Next are the 14 influencing factors as per Basic COCOMO that are applied in the SAP example project context which eventually give the Degree of Influence (DI) after summing up which leads to calculating the Technical Complexity Factor (TCF). The influence of each factor can be taken at a scale from 0 to 5 based on the degree of influence each factor exerts.

Below is the scale score table for each influencing factor in the context of the example SAP project:

Technical Complexity Factor (TCF) =0.65 + 0.01 * DI = 0.65 + 0.01 * 16 = 0.81

Function Points (FP)= TCF * UFP = 0.81 * 98 = 79.38

Software Lines of Code per Function Point (SLOC/FP) is defined using the data below published by QSM for ABAP (SAP programming language):

Assuming average for the SAP example project, we get SLOC/FP as 28

Kilo-lines of Code (KLOC) for the project = FP* (SLOC/FP) / 1000 = 79.38*28/1000 = 2.22

Now we select the complexity of the project based on the following 3 categories that the basic COCOMO uses (Source Wikipedia):

Organic projects - "small" teams with "good" experience working with "less than rigid" requirements

Semi-detached projects - "medium" teams with mixed experience working with a mix of rigid and less than rigid requirements

Embedded projects - developed within a set of "tight" constraints. It is also combination of organic and semi-detached projects.(hardware, software, operational, ...)

The basic COCOMO equations take the form:

Effort Applied (E) = a_b* (KLOC)^b_b [man-months]

Development Time (D) = c_{b *} (Effort Applied)^d_b [months]

People required (P) = Effort Applied / Development Time [count]

The coefficients a_b, b_b, c_b and d_b are given in the following table:

For our example SAP project we choose the project as an Organic project, so the coefficients take the values as a_b = 2.4, b_b = 1.05, c_b = 2.5 and d_b = 0.38

Finally we apply the COCOMO equations using the coefficients and other calculated parameters:

Effort Applied (E) = 2.4 _* ((2.22)^{^}1.05) = 5.54 [man-months]

Development Time (D) = 2.5 _* ((5.54)^0.38) = 4.79 [months]

People required (P) = 5.54 / 4.79 = 1.16 [count]

This gives us the final estimation of the example SAP development project that we intended to estimate.

Conclusion

Estimating some of the most expensive software development projects in the IT industry, that is the SAP software projects, with a high level of accuracy is mostly desirable. Challenges can occur while using COCOMO methods especially due to the issues of applying the generic software parameters and elements of the methodology to the SAP context. With the rating basis, components and element types of COCOMO explained and mapped in the SAP context described in this paper with examples, the application of the Basic COCOMO estimation becomes more accurate for SAP software development projects. This helps in estimating the projects correctly, thereby effectively budgeting and delivering the projects, which leads to higher chances of success. COCOMO is a quick and fairly accurate method can be used better in the application of SAP context if you apply the methodology described in this article.

References

Boehm, B. (1981). Software Engineering Economics, Prentice-Hall

Putnam, L. and W. Myers (1992). Measures for Excellence, Yourdon Press

Wikipedia (2016) https://en.wikipedia.org/wiki/COCOMO

Barry Boehm, Chris Abts, A. Winsor Brown, Sunita Chulani, Bradford K. Clark, Ellis Horowitz, Ray Madachy, Donald J. Reifer, and Bert Steece. (2000). Software Cost Estimation with COCOMO II (with CD-ROM). Englewood Cliffs, NJ:Prentice-Hall

Kemerer, Chris F. (1987). An Empirical Validation of Software Cost Estimation Models

Quantitative Software Management Inc (2016). http://www.qsm.com/resources/function-point-languages-table

ABAP and SAP are the trademark(s) or registered trademark(s) of SAP SE in Germany and in several other countries.

---

Related software development articles

#NoEstimates - Alternative to Estimate-Driven Software Development

Fingers in the air: a Gentle Introduction to Software Estimation

Estimating With Use Case Points

---

Click here to view the complete list of archived articles

This article was published in August 2017