Estimation

Introduction
Estimation lays the foundation for all project planning activities. It is the process of determining the Resources, Cost and Schedule requirements for the development of a software system. Estimation, in the field of software development, is a difficult, inexact and subjective science. Yet, this is an important activity and should not be conducted in a haphazard manner. There are certain useful techniques available for size, effort and schedule estimation. These reduce subjectivity and inconsistencies inherent in the process of estimation. Purpose The purpose of this document is To define a standard procedure for estimation in order to ensure a consistent and repeatable process in the Organization. Scope and Objective To define a set of estimation techniques to be used for estimating the size, effort and schedules for projects and product-releases. This process covers 1. 2. 3. 4. 5. 6. Concept of an Estimation Lifecycle for projects. Procedures in estimating the size, effort and schedule for projects. Concepts and the method of estimation for a product-release. Program-complexity Method for size and effort estimation of projects. Rules for Function Point Counting. Program/Task Complexity Method of Effort estimation for product-releases

Roles and Responsibilities 1. Project Manager Preparing Estimates 2. SQA Review of the Estimates 3. Sr. Mgmt Review of the Estimates Entry Criteria RFP Initiation of a new project

Inputs RFP

Scope of work for the project Development environment for the project Customer profile Requirements and Functional specification Design Specifications General Design Strategy Notes

Project Estimation Process

The accuracy of the estimates for a project is directly dependent on the quality of information available at that point in time. As the project progresses through its lifecycle, the quality of information improves and this in turn improves the accuracy of the estimates. It is therefore appropriate that the initial estimates for a project are continually refined during the development lifecycle. This forms the rationale behind the concept of the Project Estimation Lifecycle (PELC).

The PELC Concept

The Project Estimation Lifecycle is an event-driven process. Dependent on the progress of the SDLC, it is divided into five phases which are closely linked to the SDLC. They are: Phase 1: Pre-RS Estimation, carried out before the RS to estimate for the RS phase. Phase 2: Initial Estimation, carried out after the RS to arrive at the initial estimate for the rest of the SDLC. Phase 3: Indicative Estimation, carried out after the FS or after General Design Strategy Note (GDSN) depending on the availability of environmental data. Phase 4: Detailed Estimation, carried out after the Design and before the Construction phase. Phase 5: Revalidation of Estimates, carried out after completion of Construction and System Testing but prior to the release of software. Each of these phases involves estimating for Size, Effort and Schedule, as defined, and therefore have some implications on h/w and other facilities. Size: This is an estimate of the volumetric measure of a software project. Unit of measure used is FP (Function Points). Effort: This is an estimate of the person-days, months or years required to complete a software project. The Effort estimate is a function of the estimated Size of the software project, hardware, software technology, methodology, people and environmental factors. Schedule: This is an estimate of the elapsed days, months or years required to complete a software project. Schedule estimates are derived from Effort estimates. This is the maximum elapsed days available from a customer's point of view. Also it could be a function of internal and external dependencies.

General Guidelines for Estimation

The following are a set of guidelines applicable to the entire process of estimation. It is recommended that these guidelines are followed throughout. 1. The assumptions underlying the estimates should be stated and included along with the estimates. 2. When drawing the estimates, detailed estimates of all the remaining SDLC phases of the project should be prepared. When estimation is done using FPA, the system size is estimated and the SDLC phases come as a percentage. Even in PCM method, estimation of other phases come as a percentage of something (C + UT). 3. Explicit and implicit requirements with regard to security of the product should also be considered during estimation. Focused security related testing should also be performed to verify that the product and the third party software used (if any) to build the product are secure. These efforts for testing should also be accounted during estimation. Please refer security compliance process for more details 4. Initial estimates should not be committed as firm estimates but only as indicative one. 5. Detailed estimates and commitments should be made when full details are known, understood and all assumptions are validated. In case of commitments made even when full details are not known (due to business pressures), all such issues need to be documented and marketing needs to be advised to provide enough room in the proposal or contract. 6. The effort required during SDLC phases such as design, coding, testing for product accessibility related activities should be accounted for during estimation. Accessibility related testing should also be performed to verify that the product meets the Oracle Accessibility Guidelines and standards. Please refer Product Accessibility guidelines for more details. for more details. Estimating for Proposals: (Recommended practice for large projects in the Service Area) It is recommended that two individuals perform estimations independently. They may use the same inputs and preferably the same estimation technique, but they should not consult each other or share their opinions and assumptions before estimation. These two independent estimates should be reconciled / suitably collated to arrive at a final estimate. The reconciliation shall be done by both estimators and may be moderated by an independent person, such as the PM or any other individual designated for the purpose, if needed. This recommended practice should be used for any one or all-possible combinations of the following

1. 2. 3.

large projects, where higher stakes are involved, fixed price commitments are made, for estimating effort and / or schedule (as appropriate),

4. any other intrinsic merit / demerit of the project that demands for better accuracy in estimation. Phase 1: Pre-RS Estimation This phase covers estimating the effort and the schedule for the Requirement Study(RS) phase of the SDLC. The Estimation for the RS phase should be carried out by the Project Manager before the RS to estimate for the RS phase. It involves estimating the Effort and the Schedule for the RS, using the method "Estimation for Requirement study" as described in Chapter 3. A review of this estimate should be organized by the SQA function. Phase 2: Initial Estimation This phase covers preparing initial estimates for the rest of the SDLC. After the conclusion of the RS phase, the initial estimates for the rest of the SDLC should be done by the Project Manager using the estimation procedure "Estimation for the Rest of the SDLC", as described in Chapter 3. The estimate at this phase being an initial one, one should not be committed to the customer. A review of this estimate should be organized by the SQA function during the CPP review. Phase 3: Indicative Estimation These estimates for size, effort and schedule for the SDLC phases should be prepared by the Project Manager after the Functional Specification or after the General Design Strategy. Note: The Design phase for the project is completed. If environmental factors like hardware and software platforms are expected to be known during GDSN stage of the Design phase then it is recommended to do Indicative estimation after the GDSN is completed. Indicative Estimates for the rest of the SDLC should be done by the Project Manager using the method "Estimation for the Rest of the SDLC", as described in Chapter 3. It is recommended to use IFPUG method for size estimation at this stage. The SQA function should organize a review of the estimates. It is preferable to communicate the Detailed / Firm estimates to the client. These Indicative estimates should be communicated only when no further delay in submitting the estimates is possible. Phase 4: Detailed / Firm Estimation This phase covers estimates for the SDLC phases following the Design. These estimates should be prepared by the Project Manager after the completion of the Design Phase, and just before the construction begins. Firm Estimates for the rest of the SDLC should be done by the Project Manager using the method "Estimation for the Rest of the SDLC", as described in Chapter 3.

Size and Effort estimation can be carried out using IFPUG FPA method or Program Complexity Method (PCM). FPA is the preferred method for projects, new modules of products and PCM for the products. These estimates for the project can be committed to the customer. Note: This step needs to be done if the estimates need to be revisited. Phase 5: Revalidation of Estimates This phase covers counting the actual size & effort and comparing it with the estimated size and effort data for the entire project. Revalidation of Estimates should be done by the Project Manager after the System testing of the system is completed. IFPUG should be used to count the actual total Size of the system in FPs. The same method should be used at this point as was used at the initial stage. At the end of the project, the estimated Size and Effort should be compared against the actual Size and Effort. The SQA function should ensure a project completion review to review the estimates. The SEPG collects the actual and estimated size in FP's, system size, effort and schedule data from the project manager. This data is used for updating the organization's Baseline Metrics and refining the Estimation procedure.

Estimation During Project Initiation

At the time of Project Initiation, rough estimates of the entire project and detailed estimates of the first SDLC phase to be undertaken have to be done. The SDLC phase at which the project starts determines the first phase of the PELC applicable for estimation. The process to be used during this estimation is the same as that described in the section -- The PELC Concept.

Estimation for Requirement Study

The estimates for a project are continually refined, at each phase of the PELC. The procedures in the PELC phases comprise a set of activities, namely, estimating the size, effort and schedule. These procedures are applicable to all the phases of SDLC following the Requirement Study. The RS estimates are based on the scope of the study and the characteristics of the customer's Organization. The requirements gathered during the RS form the basis for the estimation to be made during the rest of the SDLC. This estimate is done as the first step in the Pre-RS Estimation phase. It involves estimating the Effort and the Schedule for the RS. The RS phase consists of two broad activities

Initial Study
This covers a study of the organization structure and protocol requirements with an objective of scooping the RS and fixing the agenda with the customer.

Estimation for the Initial Study: The Initial Study is always estimated to take - One Elapsed Week. During this period the Analyst(s) ascertain the number of Functional Departments that have to be covered in the RS Phase and the number of people that have to be contacted in each department of the customer.

Detailed Study
This covers the meetings for requirements gathering, preparation of minutes, holding reviews, obtaining concurrence with customer, cross-departmental validation, documentation, problem resolution and requirement prioritization. The estimation for the RS hence constitutes estimating for the Initial Study and the Detailed Study. Estimation for the Detailed Study To arrive at the Effort and Schedule estimates for the Detailed Study, do the following: 1. Judge the complexity of each department and classify it as simple-average, complex and very complex. 2. Obtain the effort in personweeks per department from the guidelines given in Table 3.1. Complexity Simple-Avg Complex Very Complex Study 1 wk 2-3 wk 4-6 wk Documentation 0.5 wk 1 wk 2-3 wk Review 1 wk 1 wk 2 wk

Table 3.1: Department Complexity-Wise Elapsed Time Note : All estimates are per department. 3. Adjust the Functional Complexity of each department up or down, based on the factors listed in Exhibit 3.1 at the end of this chapter. 4. Estimate the number of persons required for this study. It is recommended that this should not exceed 3, unless the project circumstances so demand. 5. Calculate elapsed weeks by dividing the Effort estimate by the number of people.

Estimation for the rest of the SDLC

The estimation procedure for the remaining phases of the SDLC covers the following 1. Size Estimation 2. Effort Estimation

3. Schedule Estimation 4. Adjustment of the Estimates. Each of the above activities should be performed iteratively until the Project Manager is satisfied with the estimates. A typical flow of an estimation procedure is 1. Estimate Size 2. Convert to effort 3. Adjust effort against factors 4. Re-estimate the effort 5. Convert the effort into schedule 6. Adjust schedule against factors 7. Reschedule after adjustment 8. Refine effort estimate 9. Refine schedule estimate. The above is only a representative sequence, the Project Manager can sequence his/her activities in any other manner.

Size Estimation
The Size can be measured in terms of Function Points. It can be derived using either one of the two methods 1. Program complexity (PCM), and 2. Function Point Analysis (FPA). FPA is the preferred method for projects, new products, new module development of products, any addition of functionality in a module. But in case, FPA cannot be used in products, PCM should be used. The following are the few cases in which FPA cannot be used in products Any change in the existing code of a module which does not change the functionality. Any cosmetic, screen layout, report layout changes to be made to the existing code. Any concurrency checks, error handling changes to be done in the code.

1. Program Complexity Method Program - A unit performing a defined task/job.

This method is used to obtain the Coding and Unit Testing Effort of the project based on set of criteria. The list of items covered in the Coding and Unit testing are Prepare Draft Program Specifications Prepare Draft Unit Test Plan Walkthrough Program Specifications and Unit Test Plan Code Programs Enhance Unit Test Plan Conduct Code Review Setup Unit Test Environment Conduct Unit Test Conduct Independent Unit Test Handover Program

The Program Complexity method is described in detail in Annexure A. The basic steps in this method are Identify the possible programs. Judge the complexity of each program, by assessing its processing complexity. Document the reason for assigning the complexity, which can be refined to become a set of criteria - which could be served as a added data for determining complexity of the programs for other projects. Classify the programs under three categories: Simple, Complex and Very Complex using the factors affecting the complexity of a program (Annexure A) Count the number of programs for each classification category. Derive the effort in persondays for the Coding and Unit Testing, for the implementation language and platform.

2. Function Point Analysis Method This method is used to count the functions in a system as seen by the user. This method gives the Size estimate of the system in terms of Function Points. There are 2 methods of Function Point counting. They are IFPUG FP Counting Method and the SPR Shortcut Method. Of these IFPUG FP method is the preferred one. These are described in detail in Annexure B. The basic steps in each of the methods are outlined below. The IFPUG FP Counting Method The IFPUG method for counting function points involves identifying the functions, classifying them based on their type and then evaluating the complexity of each function. To count the Function Points using the IFPUG method, do the following Identify the Functions as seen by the user. Classify each Function under: External Input(EI), External Output (EO), External Inquiry (EQ), External Interface File (EIF) and Internal Logical File (ILF). Identify the data elements and file type references/Record types for each Function. Evaluate the Complexity of the Functions using the tables provided in Annexure B for each Function type. Total all the Functions based on types and complexity.

Tabulate the functions as below Simple Average Complex

External Inputs External Outputs External Inquiry External Logical File Internal Logical File Calculate the total Unadjusted Function Points, based on the weights for each function type and complexity. Identify the degree of influence on the system, for each of the 14 adjustment factors specified in the IFPUG method. Calculate the Processing Complexity Adjustment factor (PCA) which is a sum of the numbers of all the influencing factors. Compute the Adjusted Function Points AFP = UFP * {(PCA *.01) + .65} Where AFP = Adjusted Function Points UFP = Unadjusted Function Points PCA = Processing Complexity Factor. Note: The Adjusted Function Points represent the Size of the system in Function Points. The SPR Shortcut Method

The SPR method is very similar to the IFPUG method except in the complexity classification. In this method, the complexity for all the functions is always assumed to be average. The adjustment factors are just 2 as against 14 of the IFPUG method, and the multiplication factor is based on the norms given for the PCA in the SPR method in Annexure B. The basic steps to be done in the SPR Shortcut method are Identify the Functions as seen by the user. Classify the Functions into EI, EO, EQ, ELF, ILF. Total all the Function based on types. Tabulate the Functions as below Average External Inputs External Outputs External Inquiry External Logical File Internal Logical File Calculate the total Unadjusted Function Points, based on the weights for each function type. Calculate the Processing Complexity Adjustment factor (PCA )based on two factors: Problem Complexity and Data Complexity. Total the weight attached. Use the following table to arrive at the Adjustment Factor. The Adjusted Function point is calculated as follows : AFP = UFP * Adjustment Factor Where AFP = Adjusted Function Points UFP = Unadjusted Function Points

Note: The Adjusted Function Points represent the Size of the system in Function Points.

Effort Estimation
The derivation of the Effort estimate comprises a set of steps. Step 1 A: Convert Size to Effort This step is applicable if the Size was estimated using the Function Point Analysis Method. It is not applicable if the program complexity method is used. To convert the total system size into total system Effort in persondays, do the following 1. Convert the FP count into Total Efforts in person-days. 2. Use the productivity figures given in the Baseline Report (See Section 3: Productivity Analysis). 3. Choose an appropriate combination based on the size of the project, development environment, and the development methodology. For Example : If the development is taking place in Client server GUI RDBMS type environment, choose the productivity for that environment from the tables in the baseline report. In Baseline Report 1997, the productivity for CUT phase for this environment is 7.37 FP/PersonDay. If the project size is 737 FP then the effort would work out to Effort in Person Days = Size in FP / Productivity in FP Per Person Day Effort in Person Days = 737/7.37 = 100 Person Days If organizational productivity data is not applicable, one can derive the total system effort by applying Table 3.1 and by following the steps as shown below Language *C default ANSI Cobol Basic 3rd Gen default Object-oriented default 4th Gen default Query language default Total Effort in hours /FP 13hrs 16hrs 11hrs 16hrs 5hrs 4hrs 2hrs

TABLE 3.1: Industry Standard Figures for Conversion of FP into Effort Note: The above table is extracted from Applied Software Measurement - by Capers Jones * except C default. Also the last column has been derived by taking 'Total Effort' for ANSI Cobol as the basis of calculation. The range of statements per function point is quite broad : several hundred percent in some cases because of variations in individual programming styles and unknown causes. The data is presented to illustrate general trends, and it has a very large margin of error.

All the figures stated in the table are only indicative numbers and need to be further verified by collecting relevant productivity data in Oracle Financial Services Software Limited (hereafter referred to as the Company) environment. The term "default" is used to show the generic value that should be considered when there are a number of languages approximately the same in level. e.g. "third generation" or "fourth generation" has been an umbrella term for many languages. Step 1 B: Obtain the Total Effort for the Project In case of lack of the Company productivity data one can estimate efforts in person-months by using the above Table 3.1 Step 2: Obtain Phase-wise Effort In this step, the effort for each of the SDLC phases is obtained. For the purposes of estimation, the SDLC phases have been grouped as follows Analysis : Includes both Requirements and FS Design : Includes Tech Specs, System Spec Construction : Includes Prog Specs, Coding and Unit Testing Testing : Includes Module Test Plan preparation and execution, System Test Plan preparation and execution, and Acceptance test. Documentation : Includes User manual, Handover, Op. manual The percentage break-up of the Total Effort required for a system can be based on the data obtained from various projects in the organization: Refer to the Baseline Report (See Section 5 : Effort and Schedule Analysis). The effort distribution available in the baseline report should be used as a guideline only. The characteristics of each project should dictate the distribution of effort. Effort expended on project planning is evenly distributed throughout the life cycle of the project and is inbuilt in the percentages shown in the baseline report. The criticality of the project often dictates the amount of effort for testing, reviews and project management. The percentages given may vary depending on a number of factors like Tool Usage, Language used and Team capabilities. Any variation should be documented with the reason. To arrive at the phase wise breakup of effort, use the effort converted from the FPA size, or the effort obtained from the Program-Complexity method and the above percentages. It should be noted, that if the Program-Complexity method was used, then the Effort figure used for calculation, is the Effort estimate for Coding and Testing only. Based on Coding and Testing Effort, Efforts for the other phases of the project could be derived. However, if the FP method was used, then the Effort figure used, would be the Total Effort for the system. Step 3: Obtain the Total Effort for the Project The summation of all the individual phase efforts gives the total effort for the project in personhours or persondays.

Step 4: Adjust this Estimate This estimate should be adjusted using the factors given in the Section - Adjustment of Effort and Schedule Estimates. Schedule Estimation Schedules are done for the phase of development immediately following the current phase. Such estimates are accurate as they are based on relevant data which is available at that point of time. This is a process of continuous iteration, keeping in view various factors like 1. Manpower availability 2. Customer acceptability 3. Extent of knowledge of the system. The Schedule Estimate for a project, consists of a set of steps. Step 1: Calculate the Total Expected Elapsed Days The table below gives the approximate Minimum and Maximum Expected Elapsed Time for projects depending on their size. These are only indicative numbers and should be used only for guidance. Based on the table below and the resource availability, the Total Effort In Man Months can be converted to Total Expected Elapsed Months (EM).

Effort to Schedule Conversion Table Total Effort in Person Months Total Effort in Person Year Minimum Maximum Peak Load Peak Load Elapsed Time Elapsed Time (persons) for (persons) for for The for The Minimum Maximum Project In Project In Elapsed Time Elapsed Time calendar calendar Months Months 2 4 9 5 3 5 6 7 7 7 8 11 5 7 7 8 9 11 12 13 11 11 12 15 21 31 36 39 7 8 10 14 16 20 24 33

0 - 12 13 - 24 25 - 36 37 - 48 49 - 72 73 - 96 97 - 144 145 - 192 193 - 288

1 2 3 4 5-6 7-8 9 - 12 13 - 16 17 - 24

Table 3.4: Effort to Schedule Conversion Table Convert this figure into Elapsed Days(ED) using the Formula ED = EM * 30 The figure obtained is the Unadjusted ED for the project. Step 2: Breakdown Total ED as Phase-wise ED

Breakdown the Total ED into the ED for each phase, based on the following suggested percentages Analysis : 20% Design : 20% Construction : 35% Testing : 20% Documentation : 5% Note: The percentages given here may vary depending on a number of factors like Tool Usage, Language and Team capabilities. Step 3: Identify Manpower Required for Each Phase Using the effort estimates, derive the manpower needed for each Phase. Derive the Expected manpower loading pattern. Step 4: Adjust Schedule Estimates against Available Manpower Compare the Manpower figures derived in the previous step, with the available manpower. Adjust the schedule according to available manpower. Step 5: Adjust this estimate for Other Factors Adjust this estimate using the factors given in the Section - Adjustment of Effort and Schedule Estimates. Adjustment of Effort and Schedule Estimates The Effort and Schedule estimate are based on a set of assumed factors. They are also based on the individual's own experience on certain environments, business application and level of skill. The estimated figures have to be adjusted so as to address project-specific factors. The following steps outline how the estimates in areas specific to the project can be adjusted. The Adjustment Percentages given below are just suggestive and Individual judgment will be needed in arriving at the correct adjustment percentage. The ensuing steps should be followed to arrive at the adjustments for a project. Step 1: Adjust the Result Obtained for Various Productivity Influencing Factors The productivity influencing factors can be divided into 3 headings 1. Size 2. Technical novelty 3. Miscellaneous. 1. Size Consider whether the system is significantly larger than that ever previously undertaken by the company. If so, Either consider adding upto 25% to the overall personhours and upto 20% of the overall elapsed time to compensate for project management difficulties.

or Consider breaking down the project into a number of separate sub-systems to be handled by separate project teams. 2. Technical Novelty If the project uses new methods like OOT and CASE TOOLS like Analyst's workbench, or program generator which require learning effort during the project, consider increasing PersonHours(PH) and Elapsed Weeks(EW) of the Phases affected as follows : Technical Innovation > PH by > EW by 1st use of new method 33% 20% 2nd use of new method 10% 5% 1st use of new method / tool 50% 30% 2nd use of new method / tool 10% 5% 1st use of new Tool 20% 10% ( method established ) Note: Increases in effort time for the particular phases, in which the tool or paradigm is introduced, may be offset by savings in later phases. 3. Miscellaneous Positive Factors These are some positive factors that can influence the estimate made for a project The system is a re-implementation of an existing well documented system with little functional change. The project team has worked together before in this business area on a related system and has well- established relationships with the users. If the project has any of these, then consider reducing the person hours by upto 33% and elapsed weeks by upto 20%. Negative Factors There are some Negative factors that can influence the estimate made for a project e.g: Existing or proposed procedures to be automated are ill-defined. The user is not committed to the project or cannot lead it. The new system entails significant reorganization for the user. The users to agree on the requirement are in different locations or in different functions with conflicting interests. Users are not easily available for interviews. There is difficulty in obtaining data and user- involvement in testing. The project has begun, and the rate of change of requirement is high and seemingly endless.

If the project has any of these negatives, then the Effort and Elapsed time required for the analysis and design may be as much as double. In such case, the steps to be taken to reduce the risks and thereby minimize the extra effort, should be considered and documented. Step 2: Consider the Impact of Externally Imposed Deadlines or Other Constraints. Determine whether the deadlines could be met by asking the following questions. 1. Can any of the productivity influencing factors mentioned in step 1 be avoided. e.g introducing new methods, tools? If so, eliminate and recompute.

2. Can the project be broken down into not more than 3 parallel sub-projects after the analysis phase? If so, redesign the project. 3. Can the amount of functionality to be delivered by the deadline be reduced? If so, re-estimate. 4. Can Re-useable Components in an already developed project be used in this project? 5. Can the required deadline be negotiated? 6. Can the System be delivered in Phases? 7. If the deadline considerations are still not met, then the overall elapsed time can be reduced by overlapping phases. This would decrease the overall elapsed time so as to meet the deadline but would need an increase in the elapsed time for each of the phases. This can be achieved by choosing one or more of the following Design can start before the FS signoff from the customer is obtained. Programming (only the aspect of which the design review is completed) can start before the complete design is complete. Testing can start before all the programming is complete.

Skills and Training Requirements

The person doing the Estimation should have the required skills to perform this task. The recommended skills include 1. 2. Knowledge of the estimation technique used Functional area knowledge

If not, then the person responsible should undergo training on the above aspects. EXHIBIT 3.1 DETAILED STUDY ESTIMATE: COMPLEXITY ADJUSTMENT FACTORS The following is a set of factors which could affect the assessed complexity of each department. 1. Person's Application Familiarity. Is an expert. Is not an expert, but has been involved in the Analysis/Design phase of more than one similar application. Has worked in at least one project in a similar application area.

2. Number of existing systems, their automation level and the Number of existing systems to be replaced by the system under study. Replace a manual or a single application system. Replace multiple systems on the same platform. Replace multiple systems on different platforms.

3. Existence of an Interface department (One-point contact). A one-point contact is available at all times. A one-point contact is available on a part-time basis. There is no one point contact available at all.

4. The need for the system and the level at which it is felt; i.e, Hostile vs Friendly environment. The need for the system is felt at all levels. The need for the system is felt at operational levels. The need for the system is felt only at the top level.

5. The mission criticality of the system. The system needed is a full-fledged system, and could be phased in. The system needed is a full-fledged system, but should be available in a given time-frame. The system is needed desperately, and critical functions should be up in as fast a time as possible.

6. Familiarity with the Communication Language. Both the client and the analyst communicate with each other well. The client can understand, but has difficulty communicating with the analyst. The client and the analyst have difficulty communicating with each other.

Concepts in Product Release

Every product constantly changes and improves over a period of time. What goes into every change in the product is controlled by the Product Management team, customer needs and changing market trends. Changes to a product are usually batched, and each batch can be called the New Release of the product. A Product has multiple releases over its lifetime, and the number of releases is directly proportional to the maturity of the product vis--vis the market needs. Estimation for a product-release is thus entirely different from that of projects, both in terms of the philosophy and the process. A product-release is basically an enhancement over an existing base version. A release thus is an incremental development arising out of 1. Customer incremental needs 2. Internal need for product upgrade 3. Necessity for certain standardization 4. Necessity for performance improvements 5. Field problem reports 6. Need to keep up with current trends for the product.

Any or a combination of the above can be included in a release. For a product there are essentially two kinds of releases: Main release and Interim release. Main Release: This happens as a planned event in the product evolution. It consists of product upgrades, specific customer needs which are to be included in the product, and serves as a baseline for the next main release. Interim Release: This differs from the main release mainly because these are unplanned releases. There can be a number of intermediate releases between main releases. This is done to cater to problem-fixing arising out of site reported problems, so that these fixes can be propagated across all sites using the product. No major upgrades or customer specific needs are addressed in these releases.

Estimating Procedures for a Product Release

Estimating for a product-release means estimating for a main release or an interim release. Estimating for an interim release is excluded from this process-definition. The procedure described below is hence applicable to the main release only. Prerequisite for the Estimate Availability of Manpower A certain minimum manpower is always available for a product-release. This manpower available distributed across 1. Main release activities 2. Interim release activities 3. Product Support activities The prerequisite for estimation is to judiciously use the manpower available so as to ensure that all the tasks are performed for the activities. It is assumed that a product development team ideally has a combination of manpower to handle all of these tasks. Establishing the Product Release Cycle A product-release is usually a planned event. The Management decides on the release cycle for the product. A release cycle is usually for a main release, and is an indicator of the period during which the next main release of the product will be made available to the Customer. Establishing a release cycle is the prerogative of the senior management. This cycle could be typically a period ranging from 3 months to a year. For e.g. the MicroBanker Product is currently on a 6-month release period. Establishing the Development Capacity

Once the release cycle period is established, the next step is to establish the development capacity. This is the maximum personday of effort possible during the period identified. The development capacity is based on the following parameters 1. Working days available during the period. 2. Maximum Hours of work possible in a day. 3. Expected manpower loading pattern. The result gives a figure in persondays of effort possible during this period. This is called the development capacity of this release cycle. For e.g., MicroBanker, on a 6 month release cycle, has a development capacity of 2640 persondays. The process of establishing the development capacity for MicroBanker is described in Exhibit 4.1 at the end of the chapter. The Estimation Method The main release for a product has the following stages in its lifecycle 1. Functional specification review 2. Design 3. Development/Unit Testing 4. Testing 5. Release. The Process of estimation for the main release is based on 1. The release cycle for the particular release 2. The Content of that release 3. The manpower available for that release 4. The projected number of interim releases The estimation process for a main release comprises four main steps, namely 1. Determining the release contents 2. Making broad-level Schedule estimates 3. Making Effort estimates 4. Making lower-level Schedule estimates

Determining the Release Contents One of the first steps in the release estimation process is to determine what goes into the release. The following is an indicative list 1. Customers Needs arising out of CS/PWT 2. Internal Needs for upgrading 3. Major Bug Fixes. For every release 10-12% of the total development capacity is kept aside for internal needs , standardizations etc. As and when an order is received, the estimated persondays are calculated by the product team and included for the release. This process continues until the development capacity is filled. In certain exceptional cases, the order has to be included within a release, even if the development capacity is filled. In such a case, this is included by minimizing the internal needs. This process begins much before the start date of the release cycle. Inputs from the marketing team, Customer feedback, market analysis form vital parts to this process. Making Broad-level Schedule Estimates A product release always has a certain Elapsed time allotted for purposes of testing. This is decided based on the number of logical days of testing, the number of rounds of testing to be completed and also the number of changes projected for the product. Once this is decided the remaining time is slotted for development, design and Unit testing purposes. This is the initial estimate for a product release. At the end of this the following could be known. Time period for testing : X Elapsed Weeks Release Cycle : R Elapsed Weeks Time available for Development/Design/UT : Y Elapsed Weeks Where, Y = R - X. Making Effort Estimates The estimation for a main release is more a process of proper utilization of these resources optimally, rather than trying to find a end date for completion of activities. To estimate the effort the following activities are to be carried out. 1. Consolidate changes/enhancements/additions that have to go into the release across product modules. 2. Obtain the effort needed for development / unit testing for each of these changes / enhancements / additions based on Task Complexity Method described in Annexure

C. Explicit and implicit requirements with regard to security of the product should also be considered during estimation. Focused security related testing should also be performed to verify that the product and the third party software used (if any) to build the product are secure. These efforts for testing should also be accounted during estimation. Please refer security compliance process for more details.Convert this to Design, testing, project management, Quality management efforts based on a standard percentage conversion. 3. The effort required during SDLC phases such as design, coding, testing for product accessibility related activities should be accounted for during estimation. Accessibility related testing should also be performed to verify that the product meets the Oracle Accessibility Guidelines and standards. Please refer Product Accessibility guidelines for more details. Please refer to the Baseline Report available in QuBase -> Organization Baseline for the suggested timeframes for the different phases in the software development life cycle The Effort should be within the development capacity for that release. Making Lower-level Schedule Estimates The timeperiod available for the schedule estimate is the time available for FS review, Design, Coding and Unit Testing. The step of estimation involves the following sequence of activities 1. After consolidation of needs in a release, a top level manpower availability is planned for each module affected in that release, so that all available manpower is distributed across modules. This serves as an indicator to the availability of manpower for each module under consideration. 2. For each module see whether the design and development can be overlapped, by having multiple phases within the module. This has to be done after impact analysis. Check whether certain parts of development can go on simultaneously with design of other components. This has to be validated and reviewed with the project manager. 3. Divide the effort by manpower available, to arrive at total elapsed days. Note: Keep in mind the interdependencies before arriving at a schedule. Also to be considered is the skill level of the developer. Build in sufficient buffers to allow for skill variations. 4. After arriving at the schedule estimate, see whether it fits within the overall release schedule. If not, check whether the schedule could be further compressed through additional manpower. 5. If additional manpower is not available or not possible, look into whether the development could overlap with the module Testing/Product testing period. The following are some actions that can be considered for adjusting the schedule Estimate

1. Can some enhancements / changes / additions be postponed to an interim release later on. 2. Can the internal needs be minimized. 3. Could functionalities of some modules be delayed for a later release. 4. Can the release date be postponed. EXHIBIT 4.1 RELEASE 5.0 DEVELOPMENT CAPACITY ESTIMATES This summarizes the capacity estimated at the initial planning stage of release 5.0. The period of release for the purpose of calculations has been taken as Nov 1, 1992 to April 30, 1993. The capacity available to Bangalore product development was arrived at after taking into account 1. People released for implementations 2. Impact of transition & release of people to COSL 3. Spill-over of 4.0 O/S to Nov'92 4. Provisions for training, leave (year-end actual+provision for 1Q), demos, customer visits etc 5. Actual deployment of manpower to AMC Support, Non-CitiI Implementation Support, ESG activities The manpower was further divided into two categories - skill level 1 and 0.5, depending on whether a person has worked in a prior release or not. The month-wise projection and total available persondays for the release is as follows Nov Dec Jan Feb Mar Apr Total Working days 20 22 18 19 22 20 Nr. skill level 1 26 26 24 24 25 25 *exp people Nr. skill level .5 19 19 19 19 19 19 **freshers Nr. * w.days * skill 710 781 603 637 759 690 Therefore, total persondays available = 4180. (A) [ manpower allocated to Support, ESG = 18 excluded from above ] Provisions for : Leave = 300 Training = 330 Demos/Cust visits, Mktg support etc = 200 4.0 O/S, Freezing of 5.0, EMEA Rel 4.1 plus transition (entire Nov) = 710 ----Total provisions = 1540 (B) -----

Therefore total capacity for release 5.0 = (A)-(B) = 2640 Pdays. Note : Leave includes actual mandatory year-end applied (190 d) plus provision for 1Q93 Training includes: GD 90 Straps 80 Bourse game 30 OOT 30 FIP 70 Customer specific 30 Outputs Project Size, Resources, Effort and Schedule Estimates Measurements No of review comments Effort spent on review of the Estimates

Exit Criteria Review and Approval of the Estimates by Senior Management and SQA Definitions and Abbreviations

Sr No. 1 2 3 4 5 6 7 8 9 10 11 12 13 14

Code SDLC RS FS FP SQA FPA PCM GDSN IFPUG SPR RFP CPP Elapsed Time Baseline Metric

Description Software development Life Cycle Requirements Study Functional Specifications Function point Software Quality Assurance Function Point Analysis Program Complexity Method General Design Strategy Note International Function point user group Software Productivity Research Inc Request for Proposals Combined Project Plan Time in chronological days or months or years. Metrics for an Organization collected over a period of time and which serve as the basis of comparison.