Enterprise Applications are known as one of the best practices of software reuse. They are complex applications, including most of the business processes. In this domain, size measurements and effort predictions are mostly performed in an ad-hoc fashion, and they frequently suffer from schedule and budget overruns. We developed a size measurement method for Enterprise Applications and explained this novel method in this paper. We categorized transactions as “unchanged”, “changed”, and “new” in this method. We defined a size measurement unit, Data Transaction Point (DTP), and measured size as DTP in these categories. We conducted a sample size measurement with a well-known business process to demonstrate the implementation of the method.
Best Practices: Enterprise Applications are designed to handle generic business processes. Organizations redesign their business processes to adopt the EA package’s best practices. Business process reengineering is an essential part of EA projects. Integration: In many cases, EA adopters need to interface the EA package to the organization’s existing software. Configuration: During the EA project, the configuration is done by setting software parameters based on the business processes to be implemented. The process of configuring an EA package for an organization is significantly different from software programming. Evolving: Enterprise Applications are rapidly changing based on industry expectations.
Enterprise Applications include all processes, interactions, and financial transactions of different organizations on the same platform, which makes their structure complex. Daneva and Wieringa [5] stated that EA projects, unlike other types of software projects, include thousands of business activities, require diverse configuration and modification activities, and do not have a master architecture.
Enterprise Applications are distinguished from other software with their high reuse rates by reusing many of the pre-built functions to meet customer requirements. “Software reuse” is defined as the “use of existing software or software knowledge to construct new software” [6]. By allowing adopters to handle various business requirements by configuration and customization, EA projects are considered as one of the most successful reuse implementations in Software Engineering [7].
In EA projects, applying required changes to the package is performed by using configuration and customization. “Configuration” is defined as setting necessary business-specific parameters in the system to run the EA package; configuration does not comprise source code changes. On the other hand, customization comprises source code changes. Customization is a term in EA that is used for modifications made to the software to handle the customer’s requirements that are not supported by pre-built functionalities of the software [8], [9], [10]. Customization is implemented by modifying the source code of the software. The relationship between customization and reuse is inverse; as customization increases in an EA project, the reuse rate decreases. Due to the structure of EA projects, customization is inevitable in these projects. Results of the EA research [11] showed that 64.3% of organizations participating in the research performed customization in their projects.
Daneva [12] performed an empirical study to explore reuse, and she measured the levels of reuse in three SAP projects in the same business sector. According to the results of the study, reuse rate was up to 80% at best, and reuse levels varied based on the type of implemented module. With these findings, she argued that the reusability of the ERP projects should not be overvalued. She claimed that companies adopting ERP should be ready to the minimum of 20% (in some cases presenting 40%) of pre-built functionality would not fit their business requirements, and customization would be inevitable.
In EA projects, size measurements and effort estimations are often performed in an ad-hoc fashion. They often suffer from time and budget overruns, as demonstrated by many reports such as [11] published in the field. After Stensrud [13] published the first study claiming that conventional size measurement and effort estimation methods are not suitable for such complex projects, several research studies have been conducted handling the EA size measurement problem. Function points-based size measurement methods were mostly evaluated in these studies, and “Business Blueprint” is the most used resource for sizing [14].
Software size is used as a major input for project time scheduling, effort estimation, quality management, productivity measurement, risk management, and outsource management processes. It could also be used as a base unit for software acquisition, scope changes, and normalization of base project measures [15]. For software size measurement, various methods have been developed over the years. Function point-based methods such as COSMIC, IFPUG, and NESMA are widely used in software engineering [16]. These functional size measurement methods have been evaluated as potential methods for EA projects. Although many size measurement methods have been studied for EA projects, none of the methods is widely accepted and validated as a suitable method for EA size measurement [14].
Considering the features that distinguish EA projects from other software projects, we developed a size measurement method for EA projects. In this method, “changes”, where pre-built functionality was insufficient for the customer requirements, are measured. We defined a new size measurement unit, namely Data Transaction Point (DTP), for EA projects. We counted “data groups” in transactions and measured “changes” at the transaction level. This paper presents this proposed size measurement method with a detailed size measurement sample.
The rest of the paper is organized as follows: Section 2 reviews related research regarding software size measurement and effort estimation for EA projects. Section 3 describes the proposed size measurement method. In Section 4, a sample size measurement is explained in detail. The main conclusions are presented in Section 5. In Section 6, possible directions for future work is presented.
Size measurement is accepted as one of the most critical processes of software project management. Ozkan et al. [15] defined functional size as the major input for effort, cost, and schedule prediction, and they also stated that project scope changes could be measured using functional size. They listed many other contributions of functional size to software project management, being used as a software acquisition unit, and normalizing base project measures, such as performance and quality [15].
The first measure for sizing software was the Lines of Code (LOC), where size measurement is done by counting the lines of source codes of the software. It is an easily applicable and automated size measurement method, but it cannot be used for measurement at the requirements elicitation phases of the projects. In order to handle size measurement based project management problems, various size measurement/estimation approaches have been developed over the years, and the most used ones were approaches based on measuring functionality [16].
The first study in the literature on this issue was the study of Stensrud [13]. He claimed that existing effort estimation methods are unsuitable for comprehensive projects such as EA projects. He argued that specific metrics should be defined for size measurement/effort estimation of these projects and identified potential metrics, namely modules, software interfaces, business units, users, sites, EDI interfaces, custom-developed reports, data conversions, and modified screens [13].
Daneva and Wieringa [5] evaluated if existing size measurement and effort estimation methods were applicable to the EA domain in their study. Daneva defined the existing state-of-art for size and effort estimation of cross-organizational ERP projects [17]. In this study, asynchronous focus groups, including representatives from different stakeholders of ERP projects, were constructed; according to the results, there was no consensus among representatives about how to define and measure size, and whenever size is used in a project, it was mostly functional size [17]. Daneva [18] proposed to integrate COCOMO II, Monte Carlo simulation, and portfolio management methods for effort estimation and validated this approach by a case study. In this study, it was concluded that such an approach increases the probability of success in projects with high uncertainty.
RICE (Reports, Interfaces, Conversions, Enhancements) objects of EA projects have also been examined for measuring size. Wilson [19] developed a statistical model to predict size and effort with RICE objects and conducted a case study. Case study results showed a strong correlation between the RICE objects and the development effort [19].
Erasmus and Daneva [20] indicated that new in-memory database technologies such as SAP HANA enabled all ERP solutions to run on the same platform, and this increased the level of uncertainties and customizations in the projects. They analyzed if the Expert Judgment method could be applicable in these conditions. Erasmus and Daneva continued their studies [21], [22] with an integrated method including Function Points and Expert Judgments.
The applicability of Function Point based size measurement methods in EA projects has been investigated in many studies. Vogelezang [23] measured size with COSMIC-FFP and estimated effort by using historical productivity rates. Téllez [24] developed and explored a new size measurement method, namely “eEPC-COSMIC” in his thesis study. Erasmus [25] proposed another function pointsbased method, “COSMIC EPC”, in which COSMIC function points were calculated based on business process models.
The “reuse” concept in EA projects has also been examined in the studies. Daneva [12], [26] explored how to measure reuse in EA projects, where she used IFPUG function points for measuring size. In the study [27], an approach to measuring reuse reflective size of EA projects was proposed. This approach was implemented in an SAP project, and results showed that reuse reflective size led to more accurate effort estimations.
An SLR (Systematic Literature Review) study [14] was published for size measurement and effort estimation in this domain. 41 primary studies were reviewed in this study; it was concluded that various size measurement/effort estimation methods were explored in this domain, and the most used ones were function point-based ones. The main implication of the study was no consensus occurred on how to measure the size of these kinds of projects.
Recently, cloud technology has been leading SaaS (Software as a Service) models for Enterprise Applications as well. In this way, smaller-scale organizations have a chance to implement the EA. EA has already a big share in the software industry, and by offering cloud-based implementation models, the market share of EA is expected to increase. One of the most significant shortcomings of the EA domain is the lack of a valid and effective size measurement method for these projects and the resulting budget and schedule overruns. As the EA market share grows, this problem will become more visible.
Considering the implications of the SLR [14] and exploratory case studies [27], [28] we conducted, we developed a size measurement method for EA projects. We concluded that the most critical feature of these projects that affecting sizing was “high reuse rates”. Reuse rates determines also customization levels; if reuse rate is low, this means there would be more customization. There could be cases where pre-built functionality is not sufficient for the customer requirements, even with customization. In these cases, new transactions could be developed using EA’s programming language. Thus, we need to measure “changes” where customization is required and “new” transactions are developed.
For measuring “changes” and “new” transactions, we propose to count “data groups” used in each “transaction”. We defined a novel size unit, namely “Data Transaction Point (DTP)”, as a measure of EA projects’ size. DTP is a size unit showing the number of data groups executed by transactions; in other words, it shows data points of a transaction. We claim that a change in a transaction containing multiple data groups has more effect on size than a change in a transaction containing one data group. We argue that if a transaction has a large number of data groups, it will have a greater impact on size since the change in that transaction will be reflected across all data groups.
We list data groups and transactions based on business processes. We defined three categories and measured the size based on these categories: Unchanged: For the business process, data groups in “no change required/used as is transactions” are counted Changed: For the business process, data groups in “change/customization required transactions” are counted New: For the business process, data groups in “new developed transactions” are counted We calculate size as DTP for all the transactions in these categories and take to reach the size of the business processes.
This proposed size measurement method has five main steps, which are presented in Figure 1. Step 1 Step 2 Step 3 Step 4 Step 5 •Determine the business processes included in the project •List transactions and data groups for the business processes •Identify required changes in transactions and new transactions needed •Calculate size for business processes •Sum up size for each category (unchanged, changed and new)
In an EA project, based on the customer requirements, several business scenarios are implemented. A business scenario includes many business processes. A “business process” is defined as a collection of operations that takes a particular business input and convert it into a valuable business output through a series of transactions [29].
In the scope determination phase of the EA projects, the business scenarios and corresponding business processes are determined. In this first step of size measurement, the “Project Scope Document” is reviewed, and “Business Scenarios” and “Business Processes” are listed for the project, as presented in Figure 2.
The second step of the size measurement is listing “Transactions” and “Data Groups” included in the business processes. For this step, the “Business Process Repository” of the EA could be used as the primary resource. Inputs and outputs of this step are presented in Figure 3.
•List of Business Processes •Business Process Repository of the EA •List of Transactions •List of Data Groups
A “transaction” is basically defined as executing a program in EA terminology, whether transactions are called via system-defined/user-specific transaction codes or invoked by other programs [30]. Many programs in EA are run by users vith transaction codes, but also some programs are run by periodic jobs or called by integration programs. For example, a report can be created and sent to users via e-mail by a periodic program, or the included raw data can be transmitted to integrated systems by a program. Because in all of these programs, data groups are processed to comply business process requirements, we consider them as transactions, regardless of whether they are run by a user with a transaction code or not.
In EA, each transaction uses a number of data groups to fulfill the business request. A “data group” is defined as “a unique, non-empty, non-ordered group of data attributes, explaining the same one object of interest” [31]. In an EA, there exist two main data categories: master data and transactional data. Master data is permanent data that contains information for customers, suppliers, materials, etc., whereas transactional data is temporary data that contains information for purchase orders, invoices, etc. [29]. We include both categories in the definition of “data group”.
It may be helpful to use an example to explain the concept of a data group for an EA. In the “sales order processing” business process, “create sales order”, “change sales order”, and “display sales order” are the main transaction codes. We can list four main data groups as “Customer”, “Material”, “Pricing” and “Sales Order” for these transactions. “Customer”, “Material” and “Pricing” are master data containing the required information to create a sales order. “Sales Order” is the transactional data that occurred during the execution of the transactions. Consider a business requirement such as “If the customer is a local customer and the price of the material is higher than 100 $, set the status of the sales order as to be approved”. In order to apply the required customization to fulfill this requirement, these four different data groups would be handled. Thus, we count all of these data groups in the size calculation. 3.3.
Depending on the customer requirements, some transactions are used as is, and some transactions are used by applying customization or code changes. If customer requirements cannot be met by the pre-built functionality of the EA, new transactions can be developed using the programming language of the EA.
In this step of the size measurement, change required transactions, new transaction needs, and related data groups should be figured out. The main input of this step is “The Business Blueprint/Functional Requirement Document” of the EA project. By examining in detail the Business Blueprint / Functional Requirement Document of the project, it should be determined which category (unchanged, changed, new) each transaction belongs to. Inputs and outputs of this step are presented in Figure 4.
For a better understanding of the method, we applied the method on a well-known business process, the “Purchase Order” process. A “Purchase Order (PO)” is an official document showing the description, quantity, price, and purchase conditions of the ordered products or services. It is created by the buyer and forwarded to the vendor to start the purchasing process officially. The purchase order process is included in the MM (Material Management) Module of SAP. The main transactions run for this process are presented in Figure 7 in Appendix A.
In this process, the PO is created, changed, displayed, reported, and in most of cases an approval (release) step is applied. A sample view for the PO is presented in Figure 5.
We use the Project Scope Document to understand that a process would be implemented within the scope of that project. A sample section from the Scope Document showing that the PO process is implemented in the project could be as in Figure 6.
The purchasing process will be carried out through the system for both investment and noninvestment purchases. MRP will be carried out through the system, minimum stock quantities for materials will be defined, and Purchase Requests will be opened automatically according to the needs. Purchase Orders will be created for purchase requisitions, and the approval process for both purchase requisitions and purchase orders will be carried out through the system. The printout of the purchase orders can be taken over the system or, if desired, sent to the seller by e-mail.
In order to list “Transactions” and “Data Groups” included in the business process, we use the “Business Process Repository (BPR)” of the EA and EA itself as the resource. As described in the method, we consider both master data and transactional data when determining Data Groups.
We firstly checked the master data list for the MM module defined in BPR of SAP, as presented in Table 4 in Appendix B, and determined the master data of the PO process as “Buyer”, “Vendor”, “Material”, “Conditions”, “Supplement” and “Release Strategy”. “Purchase Order” is the main transactional data of this process. As described in the scope, PO is created depending on the Purchase Requisition, so we determined “Purchase Requisition” as another transactional data.
We listed related “transactions” and “data groups” of the PO process as presented in Table 1.
After listing “transactions” and “data groups”; change required transactions, new transaction needs and related data groups should be figured out. For this purpose, we use the “Business Blueprint Document” as the resource. The “Business Blueprint Document” includes both configuration and customization details of the project, and new transaction requirements are also defined in this document.
For this sample calculation, we listed “customer requirements”, “related transactions”, and “new transactions and their data groups” for the PO process in Table 2.
For the business process, we calculated the size of each category by using the size calculation equations. The calculation sheet is presented in Table 3. 7 7 7 7 7 6 6 6 5 5 5 5 7 ui ci ni Based on these calculations, size of the PO process is as follows: unchanged (DTP) 5 0 46
We developed a size measurement method for EA projects. In this method, we proposed measuring "changes" and “new” transactions where pre-built functionality does not fulfill customer requirements. We counted “data groups” in the categorized transactions. Claiming that a change in a transaction with one data group would not have the same effect on the size as a change in a transaction with multiple data groups, we defined a novel size measurement unit, namely Data Transaction Point (DTP), for EA projects. We measured size as DTP in three categories: “unchanged (no change required transactions)”, “changed (customization required transactions)”, and “new (new developed transactions)”. We defined five main steps to apply this method as presented in Figure 1. We implemented the method on a wellknown business process, “Purchase Order”.
The main contribution of this study is the proposed size measurement method. This is a novel size measurement method developed by taking into account the unique characteristics of EA projects. We claim that this size measurement method can be applied by a novel user with general knowledge about the implemented EA. Using this method could lead to reducing size measurement variances and subjectivity. We believe that, as the method is used many times in an organization, productivity values will be more reliable, and subsequent effort estimations will be more accurate.
The second contribution is the novel size measurement unit DTP for EA projects. This specific size measurement unit can be used as a base unit for these types of projects. Since size measurement is performed at the business process level in the proposed method, size measurement unit DTP can be used for of the project management processes such as monitoring, planning, and control.
Another contribution of this thesis is the useful yet simple definition and application of the concepts “reuse” and “change” in EA projects. By making these definitions, we have revealed how EA projects can be evaluated.
In order to observe the validity of the size measurement method, we plan to conduct a multiple case study with different EA projects. This size measurement method can also be applied in other changeintensive project types like software maintenance and upgrade projects. We also plan to extend our studies to evaluate the method’s applicability for these types of projects.
There exist some EA project tools, such as SAP Solution Manager, which are also used to generate automatically Business Blueprint document. Since these tools comprise the required data for size measurement, the proposed method can be automated via these tools. This would reduce the overall time required for the DTP calculation.
We would like to thank the support of the Scientific and Technological Research Council of Turkey (TUBITAK) ARDEB 1001 [Project number: 121E389] program. [28]