Oracle Corporation et al v. SAP AG et al

Filing 775

Declaration of Tharan Gregory Lanier in Support of 774 MOTION Defendants' Notice of Motion and Motion to Exclude Expert Testimony of Paul C. Pinto filed bySAP AG, SAP America Inc, Tomorrownow Inc. (Attachments: # 1 Exhibit 1, # 2 Exhibit 2, # 3 Exhibit 3, # 4 Exhibit 4, # 5 Exhibit 5, # 6 Exhibit 6, # 7 Exhibit 7, # 8 Exhibit 8, # 9 Exhibit 9, # 10 Exhibit 10, # 11 Exhibit 11, # 12 Exhibit 12, # 13 Exhibit 13, # 14 Exhibit 14, # 15 Exhibit 15, # 16 Exhibit 16, # 17 Exhibit 17, # 18 Exhibit 18, # 19 Exhibit 19, # 20 Exhibit 20, # 21 Exhibit 21, # 22 Exhibit 22, # 23 Exhibit 23, # 24 Exhibit 24, # 25 Exhibit 25)(Related document(s) 774 ) (Froyd, Jane) (Filed on 8/19/2010)

Oracle Corporation et al v. SAP AG et al

Doc. 775 Att. 2

EXHIBIT 2

Dockets.Justia.com

2009

Expert Report of Paul C. Pinto
Oracle USA, Inc., et al. v. SAP AG, et al. Designated Highly Confidential Pursuant to Protective Order

Paul C. Pinto Managing Partner, Sylvan VI. Inc. November 16, 2009
A/73216633.3

TABLE OF CONTENTS Page I. II. INTRODUCTION AND SUMMARY OF OPINIONS .................................................... 1 QUALIFICATIONS OF EXPERT WITNESS.................................................................. 3 A. B. C. D. E. III. A. B. C. IV. V. Background ............................................................................................................ 3 Publications............................................................................................................ 4 Compensation ........................................................................................................ 4 Prior Testimony ..................................................................................................... 4 Material considered................................................................................................ 4 General Approach .................................................................................................. 5 Additional Value to Infringers ............................................................................... 6 Selection of Function Point Analysis..................................................................... 7

BACKGROUND ............................................................................................................... 4

SCOPE OF ANALYSIS .................................................................................................. 10 FUNCTION POINT METHODOLOGY ........................................................................ 11 A. B. Stratification of Products by Source Code Language .......................................... 12 Multi-Step Function Point Analysis..................................................................... 12

VI.

TEN-STEP ANALYSIS TO DETERMINE THE COST OF DEVELOPMENT USING FUNCTION POINT ........................................................................................... 14 A. B. C. D. E. F. G. H. I. Step One: Identify and Group Source Code Components .................................. 14 Step Two: Count the Number of Source Lines of Code ..................................... 15 Step Three: Determine the Amount of Functionality ......................................... 17 Step Four: Determine the Number of Pages of Documentation ......................... 20 Step Five: Derive the Productive Hours of Effort .............................................. 21 Step Six: Distribute the Effort across the Product Development Life-Cycle ..... 24 Step Seven: Allocate Productive Hours of Effort to Team Roles....................... 26 Step Eight: Derive the Cost of Localization and Documentation Translation.... 28 Step Nine: Apply Hourly Rates to Determine the Development Costs .............. 30 1. 2. J. JD Edwards EnterpriseOne Development Costs...................................... 32 PeopleSoft Development Costs................................................................ 32

Step Ten: Analyze the Estimated Development Costs ....................................... 33 Constructive Cost Model (COCOMO) ................................................................ 34 i

VII.

ALTERNATE ESTIMATES ........................................................................................... 34 A.

TABLE OF CONTENTS (continued)

Page

B. C. D. E. VIII. IX. X. A.

COCOMO II Estimate for JD Edwards EnterpriseOne ....................................... 36 COCOMO II Estimate for PeopleSoft ................................................................. 38 COCOMO II Estimate for JD Edwards World .................................................... 39 COCOMO II Estimate for Siebel......................................................................... 41 Summary of Analysis........................................................................................... 43

RESULTS ........................................................................................................................ 43 REFERENCE MATERIALS........................................................................................... 44 OPTION TO REVISE...................................................................................................... 45

ii

Expert Report of Paul Pinto

Highly Confidential

I.

INTRODUCTION AND SUMMARY OF OPINIONS I, Paul Pinto, submit the following expert report in the case Oracle USA, Inc., et al. v.

SAP AG, et al., Civil No. 07-CV-1658 (N.D. Cal.), on behalf of Plaintiffs Oracle USA, Inc., Oracle EMEA, Oracle International Corporation, and Siebel Systems, Inc. (collectively, "Oracle" or "Plaintiffs"). I am the co-founder and managing partner of Sylvan VI, Inc., an advisory services firm that provides management consulting services to clients contemplating the selection of a packaged software product or engaging an external service provider to customdevelop software. Prior to founding Sylvan VI, I served as a Senior Executive with Infor Global Software and Epicor Software, both of which publish software products that directly compete with Oracle and SAP. In these roles, I was responsible for running the Software Product Implementation and Managed Services business lines, which focused on implementing, upgrading, customizing, and supporting a variety of ERP and Financial Management software products. The law firm Bingham McCutchen, on behalf of Oracle, engaged my expert services to estimate the costs associated with development of certain products Oracle alleges were accessed, copied, and used by Defendant TomorrowNow, Inc. ("SAP TN") through the actions specified in the Fourth Amended Complaint ("Complaint"). I have reached the opinions expressed in this report based on my experience and review and analysis of certain materials produced in this matter. As explained in more detail below, to reach a conclusion regarding the cost of development, I conducted a series of formal analysis techniques on certain software applications identified in the Complaint to estimate what it would have cost SAP AG, SAP America, Inc., and SAP TN (together, "Defendants") to independently develop certain software applications accessed, copied, and used by SAP TN as alleged in Complaint. As part of that assessment, I analyzed the available materials and employed industry-accepted methods for estimating the costs associated with conducting all phases of the Product Development Life-Cycle (PDLC), including Plan, Specify, Design, Build, Test, Document, and Deploy, for what I understand to be
Page 1 of 45

Expert Report of Paul Pinto

Highly Confidential

the most current copyrighted versions of certain JD Edwards and PeopleSoft software products for which SAP TN provided support services to customers: · JD Edwards EnterpriseOne, Version 8.12, · PeopleSoft 8.8 Customer Resource Management ("CRM"), · PeopleSoft 8.8 Human Resources Management System ("HRMS"), · PeopleSoft 8.4 Financial Supply Chain Management - rev 1 ("FSCM"), · PeopleSoft 8.0 Student Administration ("Student Admin"), and · PeopleSoft 8.8 Enterprise Performance Management - rev 1 ("EPM") Using two industry-accepted and reliable methodologies known as Function Point Analysis and COCOMO, I estimated Defendants would have incurred costs in the range of $764M to $2,323M (depending on the selected staffing model) to independently develop JD Edwards EnterpriseOne and PeopleSoft CRM, HRMS, FSCM, Student Admin, and EPM modules. Further, the Complaint also alleges Defendants violated Oracle's intellectual property rights with respect to JD Edwards World and Siebel products. While I did not conduct a lowlevel Function Point Analysis for these two products, I did conduct a high-level COCOMO analysis. Based on reasonable assumptions regarding likely costs of development of these additional products, in light of the range of costs of development estimated for JD Edwards EnterpriseOne and PeopleSoft products, I estimated that Defendants would have incurred costs in the range of $1,134M to $3,477M (depending on the selected staffing model) to independently develop the most current version of JD Edwards EnterpriseOne, JD Edwards World, PeopleSoft, and Siebel applications. Based on my analysis, it is estimated that 9,772,236 person-hours of productive effort would be required to perform full life-cycle application development for the cited software products (JD Edwards EnterpriseOne, JD Edwards World, PeopleSoft, and Siebel). Assuming there are 144 productive hours in a month, this translates into 67,863 person-months of effort. If the development effort were to be completed within a two-year time frame, the organization would require access to, and the ongoing retention of, more than 2,828 well-trained resources,
Page 2 of 45

Expert Report of Paul Pinto

Highly Confidential

throughout the 24-month duration of the project. II. QUALIFICATIONS OF EXPERT WITNESS A. Background

A copy of my curriculum vitae is attached as Appendix A. I have worked in the field of Software Development and Enterprise Resource Planning ("ERP") system related services for 24 years. I spent the first half of my career as a delivery agent assuming progressively more challenging roles in providing Product Development, System Integration, and Managed Services associated with SAP, Oracle, PeopleSoft, and JD Edwards products. The second half of my career has been focused on leveraging my product knowledge to serve as a backdrop for evolving my skills as a management consultant that is focused on providing product development and outsourcing advisory services to global clients. I am the co-founder of Sylvan VI, Inc., an advisory services firm, which provides management consulting services to clients contemplating the selection of a packaged software product or considering engaging an external service provider to custom develop software. In this role, I leverage my deep knowledge of the software industry and system development life-cycle to provide independent and unbiased advice associated with a client's "buy" vs. "build" decision. Prior to founding Sylvan VI, I served as a Senior Executive with Infor Global Software (a $2.3B Software company in 2008) and Epicor Software (a $480M Software company in 2007), both of which publish software products that directly compete with Oracle and SAP. In these roles, I was responsible for running the Software Product Implementation and Managed Services business lines, which focused on implementing, upgrading, customizing, and supporting a variety of ERP and Financial Management software products. Prior to my employment with Epicor, I served as a Senior Vice President for NIIT Technologies (one of the largest India-based systems integration firms). In this role, I was responsible for the day-to-day operations of the U.S. business entity, along with overseeing the sales, estimating, and product development functions for a number of India-based software development centers.
Page 3 of 45

Expert Report of Paul Pinto

Highly Confidential

In the 1990s, I was employed by Computer Task Group (a $500M system integration firm). Throughout my 7-year tenure, I held multiple roles as a delivery agent, where I led a number of high-profile product development projects, provided guidance to troubled projects, and served as a Management Consultant focused on providing ERP package implementation and customization services. B. Publications

I have no publications from the last ten years. C. Compensation

My agreed-upon compensation in this litigation is $381/hour. My compensation is in no way contingent on the results of my analysis. D. Prior Testimony

I have provided expert witness services in one other matter, Dibon Solutions Inc. v. Chugach Alaska Corporation (Case No. 3 AN-08-10957 CI, Case Filing Date: October 3, 2008), where I performed an assessment of a failed software development effort and submitted an expert report. As part of my services, I conducted an analysis of multiple versions of delivered source code, as well as a comparison of two specific versions of source code to identify any copyright violations. As of the date of this report, the Dibon v. CAC case is still active, with trial scheduled for January, 2010. Given that this is an active case, under which I am currently governed by a confidentiality agreement, I am disallowed to provide details about my work product. E. Material considered

A list of materials I have considered in preparing this report is attached as Appendix B. III. BACKGROUND My understanding of the scope of SAP TN's activities is based on the Complaint and my discussion with Kevin Mandia of Mandiant Consulting, who is also retained by Bingham McCutchen on behalf of Oracle in this litigation. I understand that SAP TN provided third party software support services for Oracle's JD Edwards, PeopleSoft, and Siebel applications. Further,
Page 4 of 45

Expert Report of Paul Pinto

Highly Confidential

I understand that SAP TN maintained entire copies of Oracle's PeopleSoft, JD Edwards, and Siebel enterprise software applications, as well as fixes, patches, and updates to those enterprise software applications, on SAP TN's computer systems and that SAP TN used these sources in providing support services to its customers. I also understand that SAP TN used copies of Oracle's database software1 in the provision of support services to its customers. In light of SAP TN's use of the underlying JD Edwards, PeopleSoft and Siebel enterprise software applications (in addition to using the fixes, patches, and updates for these applications) in providing support for its customers, I have quantified what it would have cost Defendants to independently create the underlying applications - and not just particular fixes, patches, and updates - for the Oracle products identified herein. The cost of development of the underlying body of applications including the time and technical and litigation risks associated with such development would, in my opinion, and based on my experience, significantly factor into a decision by a potential licensee whether to license a product from the original developer, as well as factoring into the reasonable amount to be paid for that license. In addition, while I do not quantify the cost of development of the database software involved in Defendants' allegedly illegal activities through this report, the cost of development of the database software would also factor into this analysis. A. General Approach

In light of the above circumstances, I have focused my analysis on what it would have cost Defendants to independently develop the underlying software applications used in administration of maintenance services provided by SAP TN. I understand that Paul Meyer of Navigant Consulting, who is also retained by Bingham McCutchen on behalf of Oracle in this litigation, will be quantifying actual copyright damages based on the fair market value of Defendants' use. My analysis is related to this fair market value of use analysis because it

1

The term "database software" as used herein refers to any version and edition of Oracle's Relational Database Management System software.
Page 5 of 45

Expert Report of Paul Pinto

Highly Confidential

demonstrates a portion of Defendants' avoided costs and avoided risks and avoided delays from infringing, rather than independently developing, the cited products. Further, over my career as an outsourcing advisor and software company executive, I have been involved in hundreds of license negotiations, from the perspective of both the buyer and the seller of products. In negotiating the price of licenses, I would regularly consider the avoided costs, including saved time and avoided risks (such as avoided Research and Development ("R&D") missteps and avoided litigation from the IP owner) associated with licensing productized software, as opposed to independently developing software. Time and cost, are indeed, the most important considerations to potential licensees in my experience. My estimation of the cost of development is evidence of the investments avoided by not independently developing the products at issue in this litigation. B. Additional Value to Infringers

Through my years of industry experience and active consulting work, I am very familiar with the challenges and efforts associated with the development of enterprise application software and the provision of support services for that software. By infringing Oracle's intellectual property rights rather than independently creating the products specified in the Complaint, Defendants would have avoided the costs associated with independent development. Defendants also received a number of other benefits related to avoided cost, in the form of quicker time to market and avoided risks, including the avoidance of: the significant upfront monetary outlay necessary to create the intellectual property; the risk of taking wrong turns or making errors in the development process; the risk that the personnel necessary to complete the project were unavailable; and the risk that the creation of the product would take longer than anticipated and therefore the desired customer base would remain with the original support provider. As discussed above in my summary of opinions, the ramp-up needed for a software development effort of this size would require access to, and the ongoing retention of, more than 2,828 well-trained personnel, for a period of no fewer than two years, to develop all of the cited
Page 6 of 45

Expert Report of Paul Pinto

Highly Confidential

software products. A development effort of this scope and complexity would be an extremely large project, very aggressive, and of high-risk to be pursued within this timeframe. It would be exceedingly difficult for a project of this magnitude to be successfully completed within a 24 month period, but equally difficult for business reasons (e.g., pursuing a time sensitive market opportunity) for the development effort to exceed 24 months. Based on the required level of business and technical knowledge and expected attrition, however, it would be tenuous to retain a team of this size and caliber for the required duration within a single U.S. city. While there are a limited number of U.S. cities that possess a large enough, technically qualified talent pool, these same cities house a number of established software development shops which actively compete for the best technical resources. As a whole, these circumstances highlight why my cost estimate is particularly conservative in light of the constraints at issue. Infringement, rather than independent development, would save not only the costs of development identified through my Function Point and COCOMO analyses, but the significant time and risk associated with independent development. Further, testimony from this litigation reflects the additional value that would come from hiring personnel with experience through former employment by JD Edwards, PeopleSoft, Siebel, and/or Oracle.2 The desire to hire an even smaller subset of available personnel, namely, personnel with experience in similar roles at JD Edwards, PeopleSoft, Siebel, or Oracle, could potentially drive up the labor costs even further. C. Selection of Function Point Analysis

While the benefits to Defendants from infringement rather than development are extensive, this report specifically quantifies a sub-set of those benefits associated with the dollar value of avoided R&D expenses. As described in Section V, I created an estimated cost of development for JD Edwards EnterpriseOne and PeopleSoft applications, using Function Point

See, e.g., December 5, 2008 Deposition of Matthew Bowden at 46:13-47:25; January 6, 2009 Deposition of Shai Agassi at 119:17-120:2; May 21, 2009 Deposition of Seth Ravin at 11:15-12:20, 19:11-21:12.

2

Page 7 of 45

Expert Report of Paul Pinto

Highly Confidential

Analysis. This method of analysis is focused on assessing the size of a software product, in normalized terms that are directly related to the amount of business functionality provided to the end-user of the application. As such, this approach can be applied across a wide range of application development environments and throughout the full life-cycle of the software development effort. When coupled with a series of business metrics, such as productivity and the hourly rates for assigned personnel, the total cost of application development can be readily derived. The method of Function Point Analysis was introduced in 1979 (by IBM), and is actively maintained by the International Function Point Users Group ("IFPUG") as part of its Functional Size Measurement Method. Function Point Analysis provides an objective, comparative measure that assists in the evaluation, planning, management, and control of software production. Among other things, it is used, as applied here, to develop an estimated cost of development of a software product.3 I chose to use Function Point Analysis for this assessment because it is recognized by the International Standards Organization ("ISO") as a valid method for assessing the size of a software product and for deriving the associated cost of product development.4 It is also recognized by a number of the world's largest I.T. consulting companies and has been used by IBM, TCS, and Infosys since its inception. Also, I have considerable experience applying the required techniques in real business scenarios, where it is regularly used to estimate software development efforts and associated costs that are based on a set of defined requirements, which is known as "forward-engineering." I have also applied this method in situations where legacy software products needed to be redeveloped onto a modern computing platform, while maintaining the existing functionality.

International Function Point Users Group, About IFPUG, http://www.ifpug.org/about. [ORCLX-PIN-000008] International Standard ISO/IEC, 20926, Manual, October 2003, Software engineering - IFPUG 4.1 Unadjusted functional size measurement method - Counting practices manual, http://webstore.iec.ch/preview/info_isoiec20926%7Bed1.0%7Den.pdf. [ORCLX-PIN-000009]
4

3

Page 8 of 45

Expert Report of Paul Pinto

Highly Confidential

D.

Selection of COCOMO Analysis To confirm the estimates reached through Function Point Analysis for the JD Edwards

EnterpriseOne and PeopleSoft products, and to assess the cost of development for the JD Edwards World and Siebel products, I applied an alternate estimating method known as Constructive Cost Model (COCOMO) analysis. COCOMO is an industry-accepted method that provides a reliable approach to performing high-level "top-down" estimating, as a valid alternate method to performing a low-level "bottom-up" analysis as is required for Function Point Analysis. COCOMO is an algorithm-based software cost estimation model that employs the use of regression formulas, coupled with parameters that were derived from historical project characteristics. The model was originally published in 1981 as a method for estimating the level of effort, project duration, and costs associated with developing software. This original model was referred to as COCOMO 81. 5 In 2001, the second version of the model, COCOMO II, was published. This recent iteration is better suited for estimating modern software development projects, by providing an updated set of project characteristics that are more aligned with today's software development tools, iterative approaches, and relational databases. The need for this new model was prompted by the evolution of software development technologies, which moved away from mainframe and overnight batch processing, and moved toward desktop development and code reusability. 6 COCOMO II estimates the software development effort as a function of a limited set of "scaling drivers" that describe the development process, and a set of "cost drivers" that include subjective assessments about the product, platform, personnel, and project attributes. The end result of a COCOMO II analysis is the estimated total cost of development.

COCOMO Model II, Center for Systems and Software Engineering, http://csse.usc.edu/csse/research/COCOMOII/cocomo_main.html. [ORCLX-PIN-000003] 6 Id.

5

Page 9 of 45

Expert Report of Paul Pinto

Highly Confidential

I chose to apply COCOMO II analysis here (which I also refer to generally as "COCOMO"), because it provides a reliable method for confirming the development costs for JD Edwards EnterpriseOne and PeopleSoft that were estimated through Function Point Analysis. COCOMO analysis also allows the JD Edwards EnterpriseOne and PeopleSoft estimates to be reasonably extrapolated to the JD Edwards World and Siebel products, respectively. IV. SCOPE OF ANALYSIS As described in Section III above, I understand that SAP TN used copies of Oracle's PeopleSoft, JD Edwards, and Siebel enterprise software applications, as well as fixes, patches, and updates to those software applications, to provide support services to SAP TN customers. In light of the overall volume of material put at issue by SAP TN's actions, I focused the majority of my effort on a targeted subset of this material. Specifically, I analyzed the cost of development for the following Oracle products using a Function Point Analysis: · JD Edwards EnterpriseOne, Version 8.12, · PeopleSoft 8.8 Customer Resource Management ("CRM"), · PeopleSoft 8.8 Human Resources Management System ("HRMS"), · PeopleSoft 8.4 Financial Supply Chain Management - rev 1 ("FSCM"), · PeopleSoft 8.0 Student Administration ("Student Admin"), and · PeopleSoft 8.8 Enterprise Performance Management - rev 1 ("EPM") These products offered the advantage of providing relatively easy access to the components of Source Code, which was required for my analysis. I also understand that these products represent the latest copyrighted versions of these products that were also supported by SAP TN. After concluding my Function Point Analysis, I performed a COCOMO analysis on the products listed above, as well as on the JD Edwards World and Siebel products that I understand are also at issue in this litigation. If I were to assume a less conservative posture, I could have reasonably analyzed the cumulative development costs associated with each of the prior product versions, along with the development costs associated with producing the ongoing fixes, patches, and updates for each
Page 10 of 45

Expert Report of Paul Pinto

Highly Confidential

version. I did not do so in order to ensure that there was no double counting of any development efforts between versions. I also could have analyzed the value of time associated with acquiring instant access to the software applications, as opposed to enduring the time required for developing the cited products. Instead, however, I focused my analysis on the pure cost of development of the underlying products themselves. These examples demonstrate ways in which my report represents a conservative position. V. FUNCTION POINT METHODOLOGY The approach of Function Point Analysis was carefully selected, based on the existence of well-documented and widely-accepted estimating practices that provided the ability to reverse-engineer the costs associated with full life-cycle product development, using the size and complexity of the underlying Source Code as a proxy for the total cost of development. IFPUG, www.ifpug.org, which is a non-profit, member-governed organization, provides a measurement technique called Function Point Analysis ("FPA") for the functional sizing of software. IFPUG endorses FPA as its standard methodology for software sizing. Furthermore, IFPUG participates as a Lead Member in the International Software Benchmarking Standards Group Ltd. ("ISBSG"). 7 In adopting a conservative posture in the scope of my analysis, I determined that only the most recent copyrighted versions of JD Edwards EnterpriseOne and PeopleSoft that were supported by SAP TN would be analyzed to derive the cost of development for purposes of my analysis. By focusing on the most recent versions, I thereby assumed that all of the work effort associated with creating prior versions would be accounted for when estimating the costs associated with developing the most recent version. JD Edwards World and Siebel products are also at issue in this litigation. Although these two products were not analyzed using Function Point Analysis, the alternate method of

International Standard ISO/IEC, 20926, Manual, October 2003, Software engineering - IFPUG 4.1 Unadjusted functional size measurement method - Counting practices manual, http://webstore.iec.ch/preview/info_isoiec20926%7Bed1.0%7Den.pdf. [ORCLX-PIN-000009]

7

Page 11 of 45

Expert Report of Paul Pinto

Highly Confidential

COCOMO analysis was applied. JD Edwards World and Siebel products were estimated based on the results of the PeopleSoft and JD Edwards EnterpriseOne analyses, my industry experience with these products, and input from Oracle, which combined, reasonably and reliably inform the expected total cost of development of the entire body of stolen products/modules, with the exception of the Oracle database software. The following description of my analysis applies to the explicit steps taken only to analyze JD Edwards EnterpriseOne and PeopleSoft. Section VIII provides my opinions regarding what can be reasonably opined regarding all of the infringed products. A. Stratification of Products by Source Code Language

For the purpose of conducting my analysis, I extracted the underlying Source Code from the analyzed products as described in Section IV. This underlying Source Code next had to be organized into groups, based on the affinity of their underlying programming languages. Below, Table 1 (ORCLX-PIN-000065 Table 1) describes these groupings.8
Stratification by Programming Language Software Product Version JDE EnterpriseOne Version 8.12 PeopleSoft Version 8.X Programming Language Groupings C Java J2EE COBOL/400 SQC, SQR, DMS and SQL RPT and MDL PeopleCode

Table 1 - Language Groupings

B.

Multi-Step Function Point Analysis

To develop an accurate and demonstrable cost estimate associated with developing the intellectual property contained within the products, I adopted a "bottom-up" approach to performing my assessment. This micro-approach required a detailed analysis of the underlying Source Code components for each product. The approach to estimating encompassed a ten-step

Throughout my report, references to "PeopleSoft Version 8.X" refers to the PeopleSoft modules I described in Section IV ("Scope of Analysis"). The "8.X" reflects that for different modules, there are different numbering conventions within Version 8. For example, my model includes version 8.8 of module HRMS, but version 8.4 of module FSCM.

8

Page 12 of 45

Expert Report of Paul Pinto

Highly Confidential

process, with each step building on the results of previous steps. As part of this process, I applied a variety of conversion and translation techniques that are based on well-documented, industry-recognized metrics and standards. To maintain a conservative posture, I elected to use the most conservative weighting/conversion factors from the provided metrics, whenever it made sense to do so. In certain instances, and based on my personal field experience, I elected to assume a more conservative metric than was stipulated by the cited source. Below, Table 2 (ORCLX-PIN-000065 Table 2) provides a high-level description of this process, along with a brief description of the required input information, activities performed, techniques applied, and resulting output information. Section VI explains each of these steps in greater detail.
Estimating Approach (high-level view) Step Number 1 Input Information Code Components Stratified Source Code Components Number of Source Lines of Code Number of Function Points Number of Function Points Activity Performed Identify, group, and count the source code components for the most recent versions of the Analyzed Products Count the number of Source Lines of Code in each grouping, within each of the Analyzed Products Determine the amount of functionality contained in each grouping, within each of the Analyzed Products Determine the number of pages of documentation associated with each of the Analyzed Products Derive the effort associated with performing full life-cycle product development for each grouping, within each of the Analyzed Products Distribute effort across the product development life-cycle for each of the Analyzed Products Allocate phase effort to the product development team roles for each of the Analyzed Products Derive the level of effort associated with localizing and translating the required documentation into a number of foreign languages Technique Applied Output Information Stratified Source Code Components Number of Source Lines of Code Number of Function Points Number of Pages of Documentation

Manual identification

2

Automated counting of source lines of code Applying conversion tables that converts source lines to function points Applying conversion tables that converts function points to pages of documentation Apply development phase metrics and documentation metrics Apply development rolebased metrics

3

4

5

Effort Estimate

6

Effort Estimate

Effort Distribution by Phase Effort Allocation by Role Estimated Cost of Document Translation

7

Effort Distribution by Phase Number of Pages of Documentation

Apply productivity tables that associate roles with effort

8

Apply localization/translation metrics

Page 13 of 45

Expert Report of Paul Pinto

Highly Confidential

Estimating Approach (high-level view) Step Number 9 Input Information Effort Allocation by Role Estimated Cost of Development Activity Performed Apply hourly rates and determine the cost of development for each of the Analyzed Products, across a number of staffing scenarios Analyze the estimated development costs for each of the Analyzed Products
Table 2 - Estimating Approach

Technique Applied

Output Information Estimated Cost of Development Per Unit Cost Calculations

Apply resource costs

10

Automated calculations

VI.

TEN-STEP ANALYSIS TO DETERMINE THE COST OF DEVELOPMENT

USING FUNCTION POINT A. Step One: Identify and Group Source Code Components

The purpose of identifying and grouping the Source Code components, from the total population of application components, was to identify and isolate those components from which meaningful estimates could be derived. While other components, such as application code, utilities, database files, screens, and documentation are all relevant and interesting, Function Point Analysis is designed to derive the effort required to create all of these other components as a function of understanding the size and characteristics of the associated Source Code. By applying Function Point Analysis, the development costs for all components can be extrapolated from understanding the underlying Source Code. The entire set of software components was reviewed, with a focus on identifying the components that represented Source Code. This was done by reviewing the file extensions to identify the file types that could contain Source Code, and then opening each suspected file to confirm that it did indeed contain valid Source Code. As the components of Source Code were identified, they were then grouped by product, module, version, and programming language.9

As the components of Source Code were identified, they were then grouped by product, module, version, and programming language. For the JD Edwards EnterpriseOne and PeopleSoft products, I was provided with the complete applications in the form of ISO files (images of CDs or hard drives), which were physically delivered in a series of external hard drives. With regard to PeopleSoft, a significant component of the Source Code was written in PeopleCode, which resided as objects within the database. For the purpose of my analysis, Oracle extracted these objects en masse from the PeopleSoft modules listed in Section IV and provided me with the set of PeopleCode as

9

Page 14 of 45

Expert Report of Paul Pinto

Highly Confidential

The original input for Step One was the software products/modules for the Analyzed Products. Below, Table 3 (ORCLX-PIN-000065 Table 3) displays the number of Source Code programs, for the identified groupings.
Number of Source Code Programs Software Product Version JDE EnterpriseOne Version 8.12 PeopleSoft Version 8.X Programming Language Groupings C Java J2EE COBOL/400 SQC, SQR, DMS and SQL RPT and MDL PeopleCode Totals: Number of Source Code Programs 28,471 10,163 3,657 12,146 1,663 14 56,114 Programs Programs Programs Programs Programs Files (w/multiple programs) Programs/Files 38,634 Totals Programs

17,480 56,114

Programs/Files Programs/Files

Table 3 - Source Code Programs

Detailed inventories of Source Code files, grouped by stratum, have been produced as bates number ORCLX-PIN-000063 for JD Edwards EnterpriseOne, and bates number ORCLX-PIN-000064 for PeopleSoft. B. Step Two: Count the Number of Source Lines of Code

The next step involved counting Source Lines of Code ("SLOC") using speciallydesigned counting utilities. Counting SLOC is a simple procedure that provides an accurate predictor of development effort. 10 When development effort is appropriately attributed to the roles that participate in the Product Development Life-Cycle, and then combined with hourly rates, enough information is available to develop a reliable estimate of the cost of product development.11 Counting SLOCs still requires a certain amount of nuance, however. Imbedded within Source Code are various statements such as: physical lines of code, logical source lines of code, blank lines, and commented (unused or educational) lines of code. Each software development

text files produced at ORCLX-PIN-000024 to ORCLX-PIN-000062. 10 Software Size Measurement: A Framework for Counting Source Statements, Technical Report CMU/SEI-92-TR020, ESC-TR-92-020, September 1992, Robert E. Parker, Software Engineering Institute at Carnegie Mellon University, pgs. 13-15. [ORCLX-PIN-000017] 11 Id. at 1-15.

Page 15 of 45

Expert Report of Paul Pinto

Highly Confidential

language has rules for constructing its Source Code, in the same way that the English language has rules for constructing statements and sentences. These software coding rules, or standards, enable software utilities to be built that can distinguish the different rules and, therefore, count the different types of statements. The end product is the total number of logical Source Lines of Code. Since 1984, the Software Engineering Institute (SEI), at Carnegie Mellon University, has established standards for defining a Logical Source Code Statement. SEI is a federally-funded research and development center that conducts software engineering research in acquisition, architecture and product lines, process improvement and performance measurement, security, and system interoperability and dependability.12 I relied on these standards for this portion of my analysis. In order to use the logical Source Lines of Code count as the foundation for estimating software size and ultimately deriving the total cost of development, I constructed a number of software utilities that counted the logical Source Lines of Code, which are produced as ORCLXPIN-000066 to ORCLX-PIN-000085. Each line counting utility was specifically designed and tailored to address the specific needs of each type of source code that was analyzed (e.g., COBOL, C, SQL, SQR, etc). Below, Table 4 (ORCLX-PIN-000065 Table 4) is a sample of the output from the automated code counting utility for a series of "C" program files.
Sample SLOC Counting Utility Output (for JDE EnterpriseOne example) File Name Total Lines of Source Code Logical Source Lines of Code n4002340.c 701 379 SLOC n4002350.c 984 519 SLOC n4002380.c 882 315 SLOC n4002400.c 192 81 SLOC n4002440.c 801 410 SLOC
Table 4 - Sample SLOC Counting

In sum, Step Two involved counting the number of logical SLOC within each grouping, which then served as the basis for establishing the size of the code base in subsequent steps. The

12

Id. at 13-21.

Page 16 of 45

Expert Report of Paul Pinto

Highly Confidential

Source Code components, as identified in Step One, were used as the input for determining the number of logical SLOC. Below, Table 5 (ORCLX-PIN-000065 Table 5) displays the size of code base, for the identified groupings, expressed as the number of logical SLOC.
Number of Source Lines of Code Software Product Version JDE EnterpriseOne Version 8.12 PeopleSoft Version 8.X Programming Language (stratum) C Java J2EE COBOL/400 SQC, SQR, DMS and SQL RPT and MDL PeopleCode Totals: Number of logical Source Lines of Code 6,906,168 868,623 2,057,468 2,282,005 244,760 3,066,260 15,425,284 Totals 7,774,791 SLOC

7,650,493 15,425,284

SLOC SLOC

Table 5 - Source Lines of Code

C.

Step Three: Determine the Amount of Functionality

Step Three involves a process known as Backfiring to determine the amount of functionality. As explained above in Section V, Function Point Analysis is a method for determining the size of a software product, by describing it in terms of the amount of work being performed within the programming code. The major objective of Function Point Analysis is to describe the quantity of functionality that is contained in a component of Source Code, and to establish an objective statement of software size, which is independent of the technology in which it is written. Function Point Analysis, when paired with Backfiring, is a valuable technique for deriving the size of software in normalized terms. Backfiring refers to the process of using the end-product, in this case the Source Code, to determine the size of the application development effort that was used to produce it. Considerable research has been performed regarding the expressive power of computer languages. In particular, this research indicates how many logical SLOCs are required to implement a Function Point of work, with a single Function Point of work consisting of an elementary process that performs one of the following types of system-related activities:13

13

Function Point Counting Practices Manual, Release 4.2, ISBN 0-963-1742-9-0, The International Function Point

Page 17 of 45

Expert Report of Paul Pinto

Highly Confidential

·

Internal logical File (ILF) ­ holds and maintains information that is stored within the boundaries of a specific program/module. For every piece of data that is stored, updated, maintained, and retrieved from within the database, the system is acknowledged as performing a corresponding Function Point of work.

·

External Interface File (EIF) ­ controls information that is passed to other related application programs/modules that are outside the boundaries of the specific program/module. For every piece of data that is passed from the database to another program, the system is acknowledged as performing a corresponding Function Point of work.

·

External Input (EI) ­ controls information that is entered into the system from a User of the application. For every piece of data that is keyed into an application through a User's screen, the system is acknowledged as performing a corresponding Function Point of work.

·

External Output (EO) ­ sends processed information outside of the program/module, so it can be viewed by a User. For every calculation that occurs and returns a value to the User's screen, the system is acknowledged as performing a corresponding Function Point of work.

·

External Inquiry (EQ) ­ presents requested information to the User that is retrieved from the database, without any further processing. For every piece of information that is displayed on the User's screen, as a result of a lookup in the database, the system is acknowledged as performing a corresponding Function Point of work.

In particular, this research has produced a series of tables that indicate how many logical Source Lines of Code (SLOC) are required to implement a Function Point of work. These figures vary by computing language, in direct relationship with the language's level of

Users Group, January 2004, at 2-6 to 2-8. [ORCLX-PIN-000007]

Page 18 of 45

Expert Report of Paul Pinto

Highly Confidential

sophistication. As a language becomes more robust and powerful, fewer logical SLOCs are required to perform one Function Point of work. To complete Step Three, I estimated how many Function Points were present based on the number of logical SLOCs contained in each grouping by applying a set of conversion rules. For example, there was a component of JD Edwards EnterpriseOne Source Code that was counted to have 91,182 logical SLOCs of C Code. By applying the conversion rate cited in the Backfiring table, I determined that there were 914.56 Function Points of work being performed by this specific component of code. The complete set of conversion tables (SPR PLT) can be found in a study that is provided by Software Productivity Research LLC (SPR). 14 Below, Table 6 (ORCLX-PIN-000065 Table 6) is an excerpt from the SPR-provided conversion tables (SPR PLT). Based on the languages that were relevant to performing my analysis, I applied the low values for determining the number of logical source statements per Function Point (FP). My selection of the low values was based on my assessment of the source code as being produced in an efficient manner, by a professional product development shop that clearly adhered to a set of application coding standards.

Logical Source Lines of Code (SLOC) Mapping to Function Points (FP) SLOC/FP Programming Language Low Median C 99.7 139.2 COBOL/400 85.3 91.9 Java J2EE 13.6 19.4 SQC, SQR, DMS and SQL (comparable to SQL) 10.5 13.3 RPT and MDL (comparable to Crystal Reports) 14.9 22.3 PeopleCode (comparable to Visual Basic 6) 21.6 28.2
Table 6 - SLOC Mapping to FP

High 178.8 98.6 25.1 16.2 29.8 34.9

I converted the number of logical SLOC, for each grouping, into a number of Function Points (FPs). The number of logical SLOC, as identified in Step Two, along with an industry-

SPR Programming Languages Table Version PLT2007c, December 28, 2007, SPR Tables, Software Productivity Research, LLC, pgs. 16-21. [ORCLX-PIN-000019]

14

Page 19 of 45

Expert Report of Paul Pinto

Highly Confidential

accepted SLOC-to-FP conversion table (ORCLX-PIN-000065 Table 6), was used as the input for determining the number of Function Points. Below, Table 7 (ORCLX-PIN-000065 Table 7) displays the amount of functionality for the identified grouping, expressed as Function Points of work.
Number of Function Points Software Product Version JDE EnterpriseOne Version 8.12 PeopleSoft Version 8.X Programming Language Groupings C Java J2EE COBOL/400 SQC, SQR, DMS and SQL RPT and MDL PeopleCode Totals:
Table 7 - Function Points

Number of Function Points 69,269 FPs 63,869 FPs 24,120 FPs 217,334 FPs 16,427 FPs 141,956 FPs 532,976 FPs

D.

Step Four: Determine the Number of Pages of Documentation

Step Four estimates the number of pages of documentation that will accompany a software product. As the functionality of a software product increases, so does the required amount of documentation. With regard to producing a commercially-available product, the documentation must include a set of User Documentation as well as Support Documentation. User Documentation includes all documentation that is expressly developed to educate the End User about how to use the software to perform their daily work activities, while Support Documentation is targeted at aiding Technicians in installing and maintaining the software. Based on industry metrics, the number of pages of documentation required to provide an appropriate level of support for a commercial software product is equal to the number of Function Points contained within the product, multiplied by a factor that ranges between 2.50 and 3.33 pages.15 For the purposes of my analysis, I assumed a conservative posture, and elected to use a multiplier of 2.50 pages (the low-end of the range) for deriving the number of pages of

Estimating Software Effort, SoftwareMetrics.com website, http://www.softwaremetrics.com/Articles/estimating.htm. [ORCLX-PIN-000005]

15

Page 20 of 45

Expert Report of Paul Pinto

Highly Confidential

documentation. Below, Table 8 (ORCLX-PIN-000065 Table 8) displays the type of documentation, the contents, and the number of pages that are produced for each Function Point.
Pages of Documentation per Function Points (FPs) Type of Documentation Contents Quick start users guide Full users guides Feature users guides HELP text README files Training course materials Instructors guides Reference manuals Glossaries CD-ROM information Operators guides Maintenance Guides Range:
Table 8 - Pages per FP

Number of Pages per FP (low-end)

Number of Pages per FP (high-end)

User Documentation

2.14

2.86

Support Documentation

0.36 2.50

0.47 3.33

In Step Four, therefore, I determined the number of pages of documentation for the analyzed products from the number of Function Points. The count of Function Points, as identified in Step Three, along with a Function Point-to-Page conversion table (ORCLX-PIN000065 Table 8), were used to determine the number of pages of documentation. Below, Table 9 (ORCLX-PIN-000065 Table 9) displays the number of pages of documentation (in English) that are required for the analyzed products.
Number of Pages of Documentation (in English) Software Product Version Number of Pages of English Documents JDE EnterpriseOne Version 8.12 332,847 Pages PeopleSoft Version 8.X 999,594 Pages Totals: 1,332,441 Pages
Table 9 Pages of Documentation

E.

Step Five: Derive the Productive Hours of Effort

The next step in the Function Point Analysis is to determine the number of hours of work required to develop a single Function Point, also known as the Productive Hours of Effort (PHE). The PHE refers to the number of person-hours that are required to produce one Function Point of work, within a specific programming language. As the sophistication of the underlying

Page 21 of 45

Expert Report of Paul Pinto

Highly Confidential

computing language increases, so does its ability to increase productivity by providing more functionality with fewer logical SLOC. It is commonly accepted, in the product development arena, that one staff month is equal to 144 productive hours.16 To facilitate the extension of development efforts into costs, I have used productive hours as the base unit of development time. Below, Table 10 (ORCLX-PIN-000065 Table 10) identifies the productivity levels for the coding languages that are required for developing the analyzed products (ORCLX-PIN000065).17 The "Median" language level was assigned because it is best suited for the typical product development scenarios, and represents the most fair and objective metric.
Language Level Relationship to Productivity Language C Java J2EE COBOL/400 SQC, SQR, DMS and SQL (comparable to SQL) RPT and MDL (comparable to Crystal Reports) PeopleCode (comparable to Visual basic 6) Language Level (Median) 2.5 18.1 3.5 25.1 16.1 12.0 Productivity (FPs per month) 8.75 19.50 10.36 30.71 15.21 19.50 Productivity (Hour per FP) 16.46 7.38 13.90 4.69 9.46 7.38

Table 10 - Language Levels and Productivity

I also needed to calculate the PHE associated with producing the required amount of commercial documentation. To accomplish this, I applied an alternate set of metrics that is based on the number of pages of documentation. Each page of documentation is developed through an iterative writing process that includes a series of interviews, drafts, and reviews. With regard to producing documentation for a commercially-available software product, the process becomes even more rigorous. Based on industry metrics, the number of hours required to produce commercial documentation is equal to the number of pages of documentation multiplied by a factor that ranges between 1.75 and 3.25 hours of effort.18 For the purposes of
16

The ESA Initiative for Software Productivity Benchmarking and Effort Estimation, D. Greves & B. Schreiber, ESA Cost Analysis Division, ESTEC. http://www.esa.int/esapub/bulletin/bullet87/greves87.htm, at pg. 4. [ORCLX-PIN-000013] 17 SPR Programming Languages Table Version PLT2007c, December 28, 2007, SPR Tables, Software Productivity Research, LLC, pg 8, 15-21. [ORCLX-PIN-000019] 18 Estimating Tech Writing Jobs, Tech-writer.net website article, Estimating Tech Writing Jobs, http://www.tech-

Page 22 of 45

Expert Report of Paul Pinto

Highly Confidential

my analysis, I assumed a conservative posture, and elected to use a multiplier of 1.75 hours (the low-end of the range) for deriving the level of effort required to produce the base product documentation in English. Below, Table 11 (ORCLX-PIN-000065 Table 11) displays the writing activities and their associated amount of effort (in hours).
Effort (hours) per Page of Documentation (in English) Writing Activity Interview/Discussions Draft Graphics (1 every 2-3 pages min.) Edit/Review Index Total: Time Required per Page (high-end) 0.50 1.00 1.00 0.50 0.25 3.25 Time Required per Page (low-end) 0.25 Hours 0.50 Hours 0.50 Hours 0.25 Hours 0.25 Hours 1.75 Hours

Table 11 - Effort per Page of Documentation

Thus, for Step Five, I converted the number of FPs within each grouping by product language into Productive Hours of Effort (PHE), and converted the number of pages of documentation into PHE. The count of FPs, as identified in Step Three, along with a number of FP-to-effort conversion tables (ORCLX-PIN-000065 Table 11), were used as the input for converting the number of FPs into the PHE. Below, Table 12 (ORCLX-PIN-000065 Table 12) displays the amount of PHE required to perform full life-cycle product development (including documentation), for the identified groupings, expressed as person-hours of effort.
Number of Productive Hours of Effort Software Product Version JDE EnterpriseOne Version 8.12 Programming Language (stratum) C Java J2EE Documentation (in English) COBOL/400 PeopleSoft Version 8.X SQC, SQR, DMS and SQL RPT and MDL PeopleCode Documentation (in English) Totals:
Table 12 - Productive Hours of Effort

Total number of Productive Hours of Effort 1,139,978 471,650 582,482 335,356 1,019,095 155,477 1,048,294 1,749,289 6,501,622

Total Hours of Effort 2,194,111 Hours

4,307,511

Hours

6,501,622

Hours

writer.net/estimatingtechwritingjobs.html. [ORCLX-PIN-000016]

Page 23 of 45

Expert Report of Paul Pinto

Highly Confidential

F.

Step Six: Distribute the Effort across the Product Development Life-Cycle

After determining the amount of PHE required to perform full life-cycle product development, it is necessary to distribute that effort across the Product Development Life-Cycle (PDLC). This is an interim step to ultimately assigning particular hours to specific roles that perform the activities within the PDLC. The PDLC refers to the activities associated with constructing a software application from inception to deployment, and underpins many types of software development methodologies, which form the framework for estimating the software development effort. The International Software Benchmarking Standards Group (ISBSG) defines the standard phases for the PDLC as Plan, Specify, Design, Build, Test, and Implement.19 Below, Table 13 (ORCLX-PIN-000065 Table 13) provides a listing of the ISBSG phases, their associated components, and their associated Productivity Benchmarks.
Effort Distribution by Phases of the PDLC Activities Percentage of Effort per Phase Product Management Preliminary Investigations Overall Project Planning 14% Feasibility Study Cost Benefit Study Project Initiation Report Terms of Reference System Analysis Requirement Specification 11% Review & Rework Requirements Specification Architecture Design / Specification Review & Rework Architecture Specification Functional / External Design 21% Create Physical / Internal Design(s) Review and Rework Design(s) 34% Construct Code and Program Software Review or Inspect and Rework Code Package Customization / Interfaces Unit Test Integrate Software Configuration Management

Phase of the PDLC

1. Plan

2. Specify

3. Design 4. Build

Industry Software Cost, Quality and Productivity Benchmarks, whitepaper, April 2004, by Donald J Reifer, Reifer Consultants, Inc., http://www.compaid.com/caiinternet/ezine/Reifer-Benchmarks.pdf. [ORCLX-PIN-000014]

19

Page 24 of 45

Expert Report of Paul Pinto

Highly Confidential

Phase of the PDLC

5. Test

6. Localize / Document

7. Deploy

Effort Distribution by Phases of the PDLC Activities Percentage of Effort per Phase Multiple Platforms Localization Plan System or Performance Testing System Testing 12% Performance Testing Create & Run Automated Tests Acceptance Testing Prepare User Documentation Prepare Technical Documentation Defined as part of an alternate Prepare User Training Curriculum estimating technique Prepare Computer-based Training Prepare Web-based Training Alpha-Release Beta-Release Prepare Releases for Delivery 8% Install Software Releases for Users Deliver User Training Provide User Support Total: 100%
Table 13 - Effort Distribution Across PDLC

While the PDLC is acknowledged to accurately represent the full life-cycle of the software development process, it is also acknowledged that it does not include the development of documentation, and its localization/translation into foreign languages. For this reason, the cost associated with developing documentation was estimated through an alternate method as described in Step Five and Step Eight. Step Six therefore involved distributing the PHE, for the analyzed products, across the entire PDLC. The PHE, as identified in Step Five, along with the standard PDLC effort allocation distribution percentages (ORCLX-PIN-000065 Table 13), were used as the input for distributing the PHE across the PDLC. Below, Table 14 (ORCLX-PIN-000065 Table 14) displays the PHE distributed across the phases of the PDLC, including the localization and documentation, for each software product version.

Page 25 of 45

Expert Report of Paul Pinto

Highly Confidential

Productive Hours of Effort (PHE) Distributed by Phase of Product Development Life-cycle (PDLC) Phase of the PDLC JDE EnterpriseOne version 8.12 PeopleSoft Version 8.X 225,628 358,151 Hours 1. Plan 177,279 281,404 Hours 2. Specify 338,442 537,227 Hours 3. Design 547,954 869,795 Hours 4. Build 193,395 306,987 Hours 5. Test 582,482 1,749,289 Hours 6. Localize / Document 128,930 204,658 Hours 7. Deploy Totals: 2,194,111 4,307,511 Hours
Table 14 - PHE by PDLC

G.

Step Seven: Allocate Productive Hours of Effort to Team Roles

Within the phases of the PDLC, there are a number of Team Roles that are involved in performing specific work activities. The next step in the Function Point Analysis was to appropriately distribute the total work effort across all of the involved Roles, by using the following distribution method.20 Below, Table 15 (ORCLX-PIN-000065 Table 15) displays this distribution method.
Effort Distribution by Project Roles Team Role Percentage of Effort by Role Program Manager 3% Project Manager 9% Quality Manager 2% Product Manager 3% Business Analyst 8% Technical Leader 6% Technical Architect 6% Technical Analyst 9% Developer 21% Database Administrator 9% Configuration Manager 4% Test Lead 3% Tester 7% Quality Auditor 2% Documentation Lead Defined as part of an alternate Technical Writer estimating technique Curriculum Developer Implementation Lead 2% Functional Lead 3% Implementation Analyst 3% Total: 100%

Phase of the PDLC 1. Plan 2. Specify 3. Design

4. Build

5. Test 6. Localize / Document 7. Deploy

20

Id.

Page 26 of 45

Expert Report of Paul Pinto

Highly Confidential

Phase of the PDLC

Effort Distribution by Project Roles Team Role Percentage of Effort by Role
Table 15 - Effort Distribution by Project Roles

Thus, for Step Seven, I allocated the PHE, for the analyzed products, to the appropriate team member Roles within each phase of the PDLC. The PHE distributed across the PDLC, as identified in Step Six, along with the standard team member effort allocation distribution percentages (ORCLX-PIN-000065 Table 15), were used as the input for distributing the PHE across the Roles. Below, Tables 16 (ORCLX-PIN-000065 Table 16) display the PHE distributed across the development team Roles, for each software product version.
Productive Hours of Effort Distributed by Project Roles Phase of the PDLC 1. Plan 2. Specify 3. Design Team Role Program Manager Project Manager Quality Manager Product Manager Business Analyst Technical Leader Technical Architect Technical Analyst Developer Database Administrator Configuration Manager Test Lead Tester Quality Auditor Documentation Lead Technical Writer Curriculum Developer Implementation Lead Functional Lead Implementation Analyst Totals: JDE EnterpriseOne Version 8.12 48,349 145,047 32,233 48,349 128,930 96,698 96,698 145,047 338,442 145,047 64,465 48,349 112,814 32,233 87,372 407,738 87,372 32,233 48,349 48,349 2,194,111 PeopleSoft Version 8.X 76,747 Hours 230,240 Hours 51,164 Hours 76,747 Hours 204,658 Hours 153,493 Hours 153,493 Hours 230,240 Hours 537,227 Hours 230,240 Hours 102,329 Hours 76,747 Hours 179,076 Hours 51,164 Hours 262,393 Hours 1,224,502 Hours 262,393 Hours 51,164 Hours 76,747 Hours 76,747 Hours 4,307,511 Hours

4. Build

5. Test 6. Localize / Document 7. Deploy

Table 16 - Effort Distribution by Project Roles

Based on these effort estimates, it would require a team of more than 1,881 people, to be dedicated on a full-time basis (1,728 productive hours per year), for a period of not less than two years, to complete the development effort for JD Edwards EnterpriseOne and PeopleSoft. Further, while a two year period would likely be the goal of SAP TN if undertaking this effort (because a longer development time would impact the business feasibility of the project overall),

Page 27 of 45

Expert Report of Paul Pinto

Highly Confidential

the complexity of identifying and organizing a development team of this size makes achieving these results in this timeframe extremely challenging, which in turn highlights the risk that would be involved in undertaking this process. H. Step Eight: Derive the Cost of Localization and Documentation Translation

Step Eight involves deriving the cost of localization and documentation of the User Documentation. For the analyzed products to be viable for use by global clients there must be an acceptable level of User Documentation that has been localized and translated into 21 languages, as specified in the installation manuals for each product. To determine the number of pages of User Documentation that must be translated into non-English languages, I applied the metric of 2.14 pages (the low end of the scale) of User Documentation.21 This assumes that Support Documentation can remain in English, and does not need to be translated into any other languages. To determine the cost for translating the User Documentation (from English) into a number of different languages, I applied the most conservative translation cost of $60 per every 1,000 words ($15.00 per page). 22 Although a number of published sources cite the minimum translation costs to be $169 per 1,000 words, I have experienced situations in which high volume translation costs can be negotiated down to a lower cost per word, so I have elected to use this most conservative measure. Below, Table 17 (ORCLX-PIN-000065 Table 17) shows the published costs for translating documentation from English to a variety of target languages.23

Estimating Software Effort, SoftwareMetrics.com website, http://www.softwaremetrics.com/Articles/estimating.htm. [ORCLX-PIN-000005] 22 Generally Accepted Number of Words per Page, Google.com website, October 2009, generally accepted number of words per page of documentation, posed to Google Search engine, http://answers.google.com/answers/threadview?id=608972. [ORCLX-PIN-000023] 23 Competitive Translation Price List, www.hll.co.uk Internet site, January 2009; for document translation rates from English, http://www.hll.co.uk/rates-list.aspx. [ORCLX-PIN-000020]

21

Page 28 of 45

Expert Report of Paul Pinto

Highly Confidential

Cost for Localizing and Translating English Documentation into Foreign Languages Target Language French, Italian, Spanish, and German Portuguese, Polish, Russian, Ukrainian, Czech, Slovak Danish, Dutch, Norwegian, and Swedish Albanian, Bulgarian, Estonian, Hungarian, Latvian, Lithuanian, Romanian, Serbo-Croat, Slovene Chinese, Japanese, Arabic, Greek, Finnish, Hebrew, Maltese, Turkish Bengali, Farsi, Gujarati, Hindi, Punjabi, Urdu Indonesian, Kurdish, Malay, Tagalog Korean, Thai Cost of Localization/Translation from English (based on 250 words per page) $169 / 1,000 words (4-pages) $176 / 1,000 words (4-pages) $216 / 1,000 words (4-p