Estimation Practices Understanding Software Size

Transcription

1 Estimation Practices Understanding Software Size Parthasarathy M. A Abstract Accurate software project estimations have always been a tricky process. Software being Soft, it becomes quite complex to nail down the effort & costs of its key components like business functions, technology parameters and other performance and scalability related attributes. This paper attempts to re-define the major components of software project estimation, i.e. Scope, Tools and Environment and identify Size as a single yardstick that can be effectively used to measure and compare functional outputs of variety of software applications. January 2006

2 Scope, Tools & Environment Scope is the core and the base of all estimation methods. If you are constructing a building, probably the scope would be the square feet of area being built. If you are building a software application, the scope could be the size of the software in terms of functionality that it delivers or even maybe in terms of lines of code delivered. ESTIMATION INGREDIENTS SCOPE TOOLS ENVIRONMENT Fig: 1 - Estimation Ingredients Tools are utilized to produce the product and play a significant role in defining the effort and hence the time taken to complete the activity. Tools can be in different forms, shape and size depending upon the type of activity being executed. It could be the construction equipment used for constructing a building. It could be the IDE utility or other software tools used by the software developer team. Fig. 1 Estimation Ingredients shows the various critical components of estimation. Environment comprises techniques, processes and the skills of the product development team. The environment, under which the activity is being executed, makes a huge impact on the overall estimation. I could be constructing a building of certain size in a crowded locality of a city or I could be constructing the same building in a jungle area. In the first case, there would be severe restrictions on movement of material etc. and in the second case good lot of effort would go first in clearing the jungle and then making long trips (for the material and myself too) to the site on regular basis. Professional software development teams impart well established best practices and renowned processes like CMM Level 5 recommendations. They all play a crucial role in the final estimation. This paper limits the discussions to Scope being further defined as the software Size and focus on highlighting the importance of identifying Size as a single yardstick that can be effectively used as a powerful tool to measure disparate software applications on equal terms based on functionalities delivered by these applications. The other two aspects of software estimation, i.e. Tools & Environment are out of the discussion scope of this paper. Pg 2

3 Scope Defines Product Size In software estimation parlance, scope of work is better explained as the Size of the final product being delivered. It is quite possible that software estimators sometimes tend to get confused between the understanding of software Size and Effort. Size, as defined in software development context, is the complete set of business functionalities that the end user gets when the product is deployed and in use. And the person-hours consumed to produce the software application of a given Size is the Effort. In an Invoicing application, the user gets the facility to prepare invoices of products being sold to customers. The features provided in the Invoicing application is equivalent to the functions available and hence the Size of the application. The secret to making progress in sizing these new environments is to identify the unit of human thought in the abstraction being used. Next, the organization must go through a calibration process, starting with projects for which the actual size can be determined in terms of that unit of human thought [1]. Differentiate Functions from Production Effort/Costs While negotiating the price of a product, the normal assumption that both the buyer and the seller make is that the final price includes all aspects of the product, i.e. features (functions), look and feel, quality and reliability etc. And when two products of the same type (family) are being compared, very rarely do we come across products which are 100% identical in all respects. Mobile phones like Nokia vs. Samsung, Laptops like IBM vs. Toshiba, Software Products like Oracle vs. MS SQL Server in all these comparisons we will not be able to find two of the same kind in all respects. Estimating the cost of an application development project will not be very different if we adopt the same process of combining features, quality, scalability and reliability. # Activity Description Typical Product/Service Software Development 1 Functions/Features Clarity Very clear, defined and definite Somewhat vague, can and will change during development phase 2 Quality attributes Accurately measurable Measurable but cost of quality varies based on team skills 3 Tools availability Well established tools available in the market Tools with somewhat ambiguous claims on productivity gains 4 Skills/Competency of workers Defined Defined 5 Production effort Can be estimated very well Quite loosely estimated 6 Effort/Cost Estimation Definite Gut feel + Buffer + Contingency, Typically overruled by managers 7 Changes during production Negligible Very frequent 8 Specification & Design Well defined, reviewed and signed-off before start of production Loosely defined, keeps changing throughout the lifecycle of product development 9 Rework/Improvements Almost impossible to modify once the product is delivered Always possible to modify even after it goes into production Fig. 2 Activity comparison for Products and Software Development Pg 3

4 Estimating effort & costs of software development projects is perhaps much more complex than estimating the production costs of most consumer products as well as other areas of project execution, may it be construction, manufacturing, services and many more. The following table provides some insight into key differences between a typical product development and software development activities. Over and above the ambiguity and ever changing scope in software development projects as shown in the Fig. 2 Activity comparison for Products & Software Development above, if we add issues due to the target technology platform on which the software is being developed, our cup of woes would be full to the brim. It is no wonder that the question that bothers a software development project team is: Can there be an alternative and better defined method of estimating effort & costs? On second thoughts, wouldn t it be wonderful to have a standard yardstick that can measure different products with different sets of functions with the same measuring scale. This yardstick will provide the user with a true comparison facility on equal footing! Function Point Analysis Method The Function Point Analysis (FPA) methodology based estimation model designed by Alan Albretcht of IBM in 1979 and now being owned continuously upgraded by IFPUG [2] (International Function Point Users Group), is perhaps the nearest to separating the functions delivered by a product from the technology platform on which the product is developed and hence the total effort and cost to deliver the application. The uniqueness of this FPA method enables the estimator to clearly Size the software application (product) based purely on the functions that is expected to be delivered by the application. Perhaps it is due to this unique feature in the FPA method that its popularity and usage, as compared to other estimation methods, is the highest among software development community. To understand this uniqueness of the FPA method, let s look at the example of a Mobile Phone as shown in Fig. 3 Defining Size. From a mobile phone user s perspective the various functions that the user can expect to experience are: To be able to communicate with his contacts, friends & family at will, irrespective of physical location and environment Instant, on-line access to the directory of contact numbers of above category Provision to send SMS (Text) messages to anyone, any time Internet Browsing facility..and more Pg 4

5 The business functions delivered by the product constitutes SIZE Interface Outputs, Queries Product Size End-User Functions Mobile Communication Send-Receive Phone Calls Internet Browse Store Personal Phone Directory SMS Features Ring Tones Configuration Settings...and more Inputs Mic Data Store The effort & costs estimated by the vendor is a derivative of SIZE Fig. 3 Defining Size Effort & Cost Vendor Capabilities Manufacturing Techniques/Processes Skilled Workers (Competency) Tools Usage Raw Material (Quality & Quantity) Quality Processes Aggressive Pricing After Sales Service...and more The FPA method is built on the very basic premise that the Function Point count that is finally arrived at, shall be based totally on the user s perspective of the functions that the user expects to be delivered with the final product. The text box titled Product Size in the Fig. 3 Defining Size maps clearly to the end user functions that are expected to be delivered from the product (Mobile Phone). The FPA counting method maps to this aspect of Product Size. Now let s look at the other half of the effort and cost calculation activities (other than Product Sizing) which contribute towards arriving at the overall product pricing. As shown in Fig. 3 Defining Size, the activities involved are: Manufacturing Techniques/Processes Skills/Competency of the workers Effective usage of right Tools Raw Material Quality Process Pricing After Sales Service..and more A careful review of the above parameters will expose the fact that most of these activities and processes are vendor specific. The text box titled Effort & Cost in Fig. 3 contains all activities which point to vendor capabilities. Understanding the two different attributes of a production Pg 5

6 activity in terms of Product Size and Effort & Cost paves the way for further discussions and focus on Size as the single, critical measurement attribute in software development projects. Size The differentiator The FPA method of estimating software development project is based on arriving purely at the Size of the end product measure as Function Points Count (FP). We do not intend to discuss the FPA estimation model in detail here (this is out of scope of this paper) but a very brief, high level explanation would suffice. Order Management System Appln. Boundary EIF ILF EQ EI PROGRAM-1 PROGRAM-2 ILF ILF ILF EO EQ PROGRAM-3 ILF Figure 4 : FP Counting Attributes Fig.4 FP Counting Attributes provides a comprehensive picture of the five key attributes of a typical software application that can be identified to arrive at the Size of the application as Function Points. The five attributes are defined by the FPA method [2] as: 1. ILF Internal Logical File: This refers to the files (data store) that happen within the application being counted. These files are owned and maintained by the application. 2. EIF External Interface File: This refers to the files (interface) that are referred by the application being counted and are external to the application. 3. EI External Input: Are the source of information (data) input to the application being counted. EI are normally either data entry screens or batch data updates and are usually accessible to the end user. 4. EO External Output: Are the result of processed data sent out from the application being counted to any media form. 5. EQ External Query: Are the result of extracts from the application data based on query raised by the user. Pg 6

7 With these five attributes known and measurable, it is possible to fix the Size of the application fairly well. In a typical software development project scenario, the end user (or business user) is the owner (customer) of the application (being developed) and the IT development team or an external (outsourced) vendor will be the supplier. Knowing the Size of the application would come in very handy for the customer in situations where an evaluation of multiple vendors, including the internal IT development team, is being done. Here are the key pointers to successful negotiation of software development contracts: With the application Size being pre-determined, the user can avoid being misled by different vendors on various functional complexities of the application. Instead, the vendors could be asked to provide their quotes for the defined Size of the application on a given platform. The user may not have a deep knowledge of the internals of application development process or even the technology involved (it s a Black Box). Despite this situation the user can still manage all project contract execution activities based on the final Size of the product that needs to be delivered and accepted. An experienced estimator can produce reasonably good Size estimates by analogy if accurate Size values are available for the previous project and if the new project is sufficiently similar to the previous one [3]. Basically, function points are the quantified representation or Size - of the functions (or transactions) and data that go together to operate as a computer application. They provide a rough unit of Size that is based upon the software component of the requirement [4]. Functional features being separated through the Size model, this opens out a wide option for the customer to choose the technology platform on which the application needs to be developed. Development costs on different technology vary based on skills available. And hence better cost and budget control. Function Points are perhaps one of the best methods to estimate the Size of an application. The method is quite ambiguous and hence flexible enough to be able to get moulded into variety of estimation needs like software development, maintenance, reengineering, enhancement etc. Source Lines of Code (SLOC) or LOC is a poor alternative. Size refers in a very general way to the total scope of a program. It includes the breadth and depth of the feature set as well as the program s difficulty and complexity [5]. Pg 7

8 The Yardstick The business value delivered by software systems, in the form of functions provided, is nothing but the Size of the system. This Size can be used as an effective yardstick to facilitate many needs of an IT organization. This could be likened to measuring the height of persons with a background of varying cast, creed, color, weight and so on, using a standard measuring tape. In Conclusion To be able to Size an application using a well established estimation method like FPA can become a very powerful yardstick which can be effectively utilized for a number of software project execution processes. IT groups within organizations can derive a variety of benefits that include software contracts, project management, cost of ownership, IT budgets, outsourcing and more. Here are key areas of direct benefits: Software being Soft has always been a difficult product to measure in real terms. FPA based sizing can become a hard yardstick to measure software. Size is the key and the core input to all software estimations. All the subsequent information about software project projects like effort & schedule based on skills of team, and cost based on resource rates can now be better estimated. For a CIO, the comfort of being able to compare and equate two different applications (systems) in their IT organization for purposes of TCO, budgets or other strategizing purposes has always been another area of serious concern. For example; equating an Order Management System with a Payment Processing System on TCO or number of resources deployed etc. would be quite difficult. Even if the two systems belong to the same organization and have been developed on the same technology platform, equating them on any terms would be an uphill task. Sizing the two applications through a common yardstick (like FP count) would perhaps be the nearest to understanding their relation. Skills, competency of the software development team (productivity) can be better measured through a common yardstick like FP count even if they are measured across different technology platforms. Measuring and monitoring the quality metrics like effort & schedule variance and also code defect density etc. can be done through the Sizing technique For a CIO, there are a number of cost saving, better budgeting and project monitoring facilities that can be fine tuned through application Sizing methods Pg 8

9 References 1. Ross, Mike. Size Does Matter: Continuous Size Estimating and Tracking. Quantitative Software Management, Inc. 2. International Function Point Users Group (IFPUG). Function Point Counting Practices Manual (CPM) Release 4.2. ISBN Peters, Kathleen. Software Project Estimation. Software Productivity Centre Inc., 4. Robyn Lawrie and Paul Radford. Using Function Points in Early Life Cycle Estimation. CHARISMATEK Software Metrics 5. McConnell, Steve. Rapid Development. Microsoft Press, About the Author Parthasarathy M. A. heads the competency group at SGS Infosys, mentoring and developing competency for large outsourcing project delivery. He is also the mentor for the estimation related initiatives at ESTEEM Infosys and has been instrumental in defining a number of processes and methods based on Function Point Analysis method. He can be reached at partha@infosys.com. Phone: Pg 9

10 2006 Infosys Technologies Limited. ALL RIGHTS RESERVED Copyright in whole and in part of this document Estimation Practices Understanding Software Size belongs to Infosys Technologies Limited. This work may not be used, sold, transferred, adapted, abridged, copied or reproduced in whole or in part in any manner or form or in any media without the prior written consent of Infosys Technologies Limited. Pg 10