True Cost of Developing Software - slidex.tips

Jun 3, 2001 - development over the lifetime of the custom software cycle. ..... work needs to be done to successfully complete the project, what ... life cycle.
380KB taille 19 téléchargements 195 vues
A CresSoft, Inc. White Paper

True Cost of Developing Software

CresSoft, Inc. 6025 S. Quebec Street, Suite 310 Englewood, CO 80111-4551 Ph: 303-488-2126 www.cressoft.com

copyright 2001,CresSoft, Inc.

True Cost of Developing Software

Executive Summary This document describes the significant factors affecting the cost of software development over the lifetime of the custom software cycle. Using a case history depicting the performance of CresSoft against industry standards, it shows that cost assessment is multi-dimensional and factors like productivity, quality, timely delivery and flexibility become much more important than the obvious metric of price. Lost revenue from delayed or buggy software is one aspect that is not addressed as it varies widely from product to product and company to company. However this aspect only serves to accentuate the importance of other factors discussed above versus price. The function point method is used to estimate software size, as this is the best generic software estimation technique available today. International Function Point Users Group (IFPUG) guidelines are employed. Analysis contained in this paper applies equally to inhouse, outsourced and offshore-outsourced software development.

Version History Version 1.0

Date 6/3/2001

Authors Yusuf Hussain & Aymen Toor

i

Notes

copyright 2001,CresSoft, Inc.

True Cost of Developing Software

Table of Contents Executive Summary ............................................................................................................. i Version History.................................................................................................................... i Table of Contents................................................................................................................ ii 1. Introduction................................................................................................................. 1 1.1 Software Estimation.................................................................................................. 1 1.2 Project Sizing Standards ........................................................................................... 2 1.2.1. COCOMO Model........................................................................................ 2 1.2.2. Function Point Analysis.............................................................................. 2 2. Cost Management: Governing Factors ....................................................................... 3 2.1 Rate per Hour............................................................................................................ 3 2.2 Productivity............................................................................................................... 4 2.2.1. Well Defined Business Requirements ........................................................ 4 2.2.2. Domain Expertise........................................................................................ 4 2.2.3. Manageable Sub Projects............................................................................ 4 2.2.4. Change Management .................................................................................. 4 2.2.5. Turn Over Rate ........................................................................................... 4 2.3 Quality....................................................................................................................... 4 2.3.1. Technical Guidelines .................................................................................. 5 2.3.2. User Interface.............................................................................................. 5 2.4 On-Time Delivery..................................................................................................... 5 2.4.1. Loss of Revenue.......................................................................................... 5 2.4.2. Overhead Costs ........................................................................................... 5 2.4.3. Slippage....................................................................................................... 5 2.5 Flexibility.................................................................................................................. 6 2.5.1. Domain........................................................................................................ 6 2.5.2. Technology ................................................................................................. 6 2.5.3. People.......................................................................................................... 6 2.5.4. Methodology ............................................................................................... 6 2.6 Conclusion ................................................................................................................ 7 3. Case History................................................................................................................ 8 3.1 Rate per Hour & Productivity ................................................................................... 8 3.2 On-Time Delivery & Overhead Costs ...................................................................... 9 3.3 Quality....................................................................................................................... 9 3.4 Flexibility................................................................................................................ 10 4. Reference Reading .................................................................................................... 11

ii

copyright 2001,CresSoft, Inc.

True Cost of Developing Software

1. Introduction Managing the cost of software development and its maintenance are major concerns of companies today. The process of calculating the cost of software development starts with estimating how much work needs to be done to successfully complete the project, what resources are required and how long will it take. Quality of the software has a significant impact on the cost of the software as finding and fixing bugs is a major cost element in the development process. Once the application is delivered, ease of maintenance and enhancement of the application considerably affects the overall cost of the software to the organization. Software development organizations are regularly challenged to provide early and precise estimates for the work they are setting out to do. However statistics given by the United States government show that these organizations have not adequately handled this area as • • •

60% of projects are behind schedule 50% are over cost 45% of delivered projects are unusable

Given the above statistics it is fair to conclude that 50% of the work undertaken by software organizations fails to meet the expectations of their customers in terms of productivity, quality and cost. 1.1 Software Estimation Software estimation has been an issue ever since the first project was scheduled and budgeted. In order to address this task adequately the first challenge is to define and understand the problem domain of the project, also referred to as the scope of the project. Scope determines the boundaries of the software. Without well-defined boundaries, accurate estimates are unattainable. The complexity in defining the scope of a project arises from lack of information or domain expertise. In order to provide a viable estimate, the software organization needs to capture the business requirements that are normally in the heads of the customer rather than on paper. To add to the complexity a reasonable size project involves multiple stakeholders having pieces of information that affect the project. Capturing and providing a unified vision to all involved, i.e. project stakeholders and the development team, is a key pre-requisite in accurately determining the size and complexity of a project. Hence a software development team that has a keen grasp on the customers’ business issues and is inherently familiar with the environment the software needs to integrate in reduces the risk of inaccurate estimates significantly. Estimating software is also dependant upon the skill set available and development processes within the software organization. It is imperative for a software organization to understand the capability of its resources and follow processes that ensure successful 1

copyright 2001,CresSoft, Inc.

True Cost of Developing Software

delivery. Thus enabling the software organization to determine effort needed for delivering a quality solution in a given timeframe. Opting for a development team whose delivery model has been put to the fire and can be trusted greatly reduces the risk of undue heartburn in the future. 1.2 Project Sizing Standards There are numerous standards available in the industry for estimating project size and complexity. Out of these the most widely practiced are the Constructive Cost Model (COCOMO) introduced by Barry Boehm and Function Point Analysis supported by the International Function Point Users Group (IFPUG). 1.2.1. COCOMO Model The basic input of the COCOMO model is number of source lines of code. Using this input effort months are calculated. Weights are assigned to the tools and technology used and other factors such as application complexity and reliability to determine overall cost. However using this approach has uncovered numerous issues such as • • • •

The basic premise in this approach, i.e. number of lines of code just covers one aspect of software development i.e. writing code. The SDLC has many other phases to it that are ignored thus leading to flawed estimates. There is considerable variation in the number of lines of code written by two developers using the same tools & technology solving the same problem. The weights assigned to other factors are not accurate enough to determine the overall cost / size of the project as different components of a project vary immensely in complexity and there reliability constraints may also differ. This approach cannot be used in the initial estimation of the project, as it is dependant upon information not available until the later stages of the development life cycle.

1.2.2. Function Point Analysis International Function Point Users Group (IFPUG) is a membership governed non-profit organization dedicated to introducing standards to increase the accuracy in software estimation and sizing. The function point analysis technique, introduced by IFPUG, is the most widely recognized, flexible and accurate project sizing technique in the industry today. Function point analysis is dependant upon five basic elements • • • • •

Inputs Outputs Inquiries Internal Stores of Data External Interfaces

Accuracy of the function point size is dependant upon the thoroughness of the requirements defined. However it has proven to provide a reasonable ballpark estimate 2

copyright 2001,CresSoft, Inc.

True Cost of Developing Software

even if the requirements have not been defined extensively. This is possible because the basic five elements can be identified during the early stages of the project at a functional level. In addition to project size, this approach also accounts for project complexity, which is dependant upon the following factors • • • • • • • • • • • • • •

Distributed Data Processing On-Line Data Entry Configuration Requirement Transaction Rate On-Line Update User Efficiency Complex Processing Performance Data Communications Reusability Installation Ease Operational Ease Multiple Sites Facilitate Change

By combining project size and complexity this approach allows us to derive relatively accurate estimates upfront thus managing the overall development cost and customer expectations.

2. Cost Management: Governing Factors Successful completion of a software project is dependant upon managing several risk factors that determine a development organizations’ ability to deliver superior quality software in a timely and economical fashion. In essence the true value of software can be deducted using the following formula Return on Investment (ROI) = Benefit delivered by Software / Cost of Software From the above formula, the lower the cost the higher the ROI. Given below are five basic factors that determine the overall cost of the software 2.1 Rate per Hour This is the most commonly used element in determining the cost of software. Organizations normally calculate the cost of software by multiplying the time taken to deliver the application with the rate charged per hour. Despite its obvious relation to the cost of development effort, relying on it alone can produce a flawed image. Customers normally do not give much emphasis to other underlying factors that enhance the overall

3

copyright 2001,CresSoft, Inc.

True Cost of Developing Software

quality and efficiency of the delivered product thus affecting the cost. These factors are explained below. 2.2 Productivity Productivity basically means getting the most out of your development team in the least amount of time. It is dependant upon many factors and may change considerably by tampering with the circumstances and environment. Some of the well-tested guiding principles are as follows 2.2.1. Well Defined Business Requirements Clearly defined business requirements enable the development team to understand the purpose and applicability of the software for the customer. This vision allows them to make better design decisions upfront, resulting in a productive application. Hence clearly defined business requirements are essential to enhance productivity. 2.2.2. Domain Expertise According to industry surveys, a development team gets more productive as they get more familiar with the domain. Due to this fact, software organizations develop domain expertise in particular niche industries and target customers only related to these verticals. Hence a team who has done similar work earlier is more productive than the team doing it for the first time. 2.2.3. Manageable Sub Projects In large projects, well defined quarterly releases, that target particular components of the end product are more feasible than rapid spurts of development effort or delivering the entire project in one release. 2.2.4. Change Management Extensive small changes in the software, affect the overall design of the system eventually hampering productivity. There is a possibility of evaluating the overall architecture before executing the change, however, grouping these small changes together reduces the overall cost by avoiding redundancy in effort. 2.2.5. Turn Over Rate A key detrimental factor in increasing productivity is higher turn over rate. One of the concerns being that the project timelines get affected as there is ramp up time required for a new resource to become productive. Other hidden but more basic concerns are that the development team is dissatisfied either due to excessive overwork or unfriendly work environment. Either one of these factors have a much higher impact on productivity in the long term. 2.3 Quality Quality of software can be described as the behavior of an application with respect to the requirements that application is supposed to fulfill. Besides business requirements, software application expectations normally span the following different facets, the fulfillment of which deems the software as successful and of high quality

4

copyright 2001,CresSoft, Inc.

True Cost of Developing Software

2.3.1. Technical Guidelines Technical expectations in terms of architecture & design principles, coding guidelines and performance standards are defined as part of the requirements. How well the end product measures to these expectations is an important factor in determining the quality of the product. 2.3.2. User Interface Every application has an end user. This end user may be a human or a machine. In any case, a well-defined and/or easy to use interface is an important constituent in determining the success and quality of the end product. Cost of software is highly dependant upon the quality of the end product. A study by Forrester Research shows that the cost of fixing a discrepancy identified when the application is in production is ten times higher than if this discrepancy was identified at the requirements level. 2.4 On-Time Delivery 2.4.1. Loss of Revenue In the Internet world, time to market is key. Having the right product available at the right time determines the success of the organization. In such an environment, it is imperative to manage timelines as they are directly associated to customer expectations. The inability to manage customer expectations results in loss of revenue, thus in effect increasing the cost of software. 2.4.2. Overhead Costs Besides an indirect increase, due to a decrease in ROI, a delay in the delivery of software also has a direct increase in the cost of software. In order to manage the overall delivery and success of the end product, there are certain overheads associated to the development effort. These overheads are visible in terms of marketing costs, project management costs and the labor costs associated with manual processes that the software is intended to automate. Overhead costs at least run up to 30% of the development cost. However for the unplanned extra development time (slippage), the overhead costs shoot up to at least 60% of the additional development cost. This increase is mainly attributed towards the delay in other tasks these resources have been planned to take over and the extra hours they have to put in to complete the project. 2.4.3. Slippage Not having the product delivered on time results in utilizing development resources beyond the initial work estimate. This slippage increases the cost of the end product significantly. The above-mentioned three factors that enhance the cost of software significantly due to failure in meeting timelines can be represented by the following formula

5

copyright 2001,CresSoft, Inc.

True Cost of Developing Software

Increment in Cost of Software = Slippage + Overhead costs + Loss of Revenue (where Overhead costs = (60% of Slippage)) 2.5 Flexibility The final delivery of the software alone does not determine the ultimate cost of software. The application delivered is normally a piece in the puzzle, the puzzle being a set of defined business objectives. Business objectives are influenced by market conditions and customer demands, that are constantly changing. The dynamics in these objectives results in changing requirements. Hence an application needs to have the flexibility to accommodate future requirements / enhancements relatively easily. Building a flexible application is a daunting task as it involves visualizing future requirements upfront and making design decisions accordingly to ease the support of these future requirements. Given below are the four basic factors for a software organization that if present ensure the delivery of a flexible product 2.5.1. Domain Having in depth knowledge of the business problems allows the development team to architect and design the application appropriately to meet not only the demands of today but also the requirements of tomorrow. Thus higher levels of configurability and scalability can be achieved. 2.5.2. Technology Using the right set of tools and technology today pave the way for lower cost of ownership tomorrow. In any given time a software problem can be resolved via multiple tools. Choosing the right ones determine the success of the application in the future. 2.5.3. People People are the true essence in software development. Having experienced resources familiar with various design and architecture techniques provides the platform for a mature design of the end application. 2.5.4. Methodology Methodology acts as the glue of the development process and keeps it all together. It ensures that due consideration is given to all aspects of the SDLC hence guaranteeing the success of the end product. The above significant qualities of a software organization greatly impact the overall flexibility in the end product. In a flexible application the following cost saving architectural attributes are very prominent. 2.5.5. Configurability The more configurable a product is the more adept it will be towards accommodating the needs of different users. Hence building a product, with the mind set that it needs to support various users with unique needs allows the designers to provide appropriate hooks in the application that lower the future customization costs significantly.

6

copyright 2001,CresSoft, Inc.

True Cost of Developing Software

2.5.6. Scalability Appropriate architectural considerations to the performance of the application as the number of users and data increase ensure longevity of the application. The longer the application remains in production the more cost benefits it reaps and hence increases the ROI. 2.5.7. Reusable Components & Portability An application with generic components that can be re-utilized else where increases the ROI by lowering the development costs of other applications. Similarly an application that can be deployed on multiple platforms easily integrates in the client environment and also increases the sales / revenue opportunities manifold. 2.5.8. Standards Compliance to standards allows different applications to talk with each other in a common language. In today’s environment where multitudes of disparate applications provide point-to-point solutions, adherence to industry standards make collaboration a reality. Collaboration in turn increases efficiency and thus positively impacts ROI. Defining an architecture that addresses factors such as scalability, configurability, reusability and following industry standards is relatively easier than its real time implementation. The execution of the defined architecture is largely dependant upon the organization building the end product. Flexibility can be represented by the following function Flexibility = ƒ((Domain), (Technology), (People), (Methodology))

Flexibility has a huge impact on the true cost of the application. Once the product is delivered, further enhancements to the existing application cost on the average 50% more than they do on a flexible platform. Flexibility is equally dependant upon each of the defined factors i.e. domain, technology, people and methodology. 2.6 Conclusion The Cost of Software is a complex function not only associated with the rate per hour charged for the development team but also includes numerous other variables that equally impact the end result. Similarly it does not end with the delivery of the software as a flexible architecture has a major impact on the cost of maintaining the end product and customizing it to meet future requirements. True cost of software can be represented as True Cost of Software (USD)

=

Rate / Hr (USD)

+

Productivity (USD)

+

7

Quality (USD)

+

On-Time Delivery (USD)

+

Flexibility (USD)

copyright 2001,CresSoft, Inc.

True Cost of Developing Software

The next section details a comparison of CresSoft Inc. with another software development organization to further illustrate how these factors affect the overall cost of software.

3. Case History CresSoft performed a study of itself compared to another vendor, the purpose of which being to provide greater value to our customers. As an organization we have consistently focused on the cost factors and tailored our methodology to accommodate for all of the different variables governing the end cost of software. 3.1 Rate per Hour & Productivity The interesting aspect in this study was that our per hour rate compared to the other vendor was actually higher. However after working out the numbers it was evident that working with us revealed higher benefits to the customer. The rates per hour given in this study are fabricated. Once the requirements were defined, both organizations were asked to provide their estimates. Our estimate concluded that the end-application is going to require 7200 man hours to complete where as our competitor estimated the job to be completed in 6000 man hours. Thus we were stuck in a situation where our effort estimates were higher than our competitions and so were our rates. Not an ideal sales situation to be in to say the least. After completion of the job, we discovered that we were 15% more productive than our competitors. Although they gave an initial estimate much lower than ours however they could not deliver on the promised dates. We had estimated the project to constitute 566 function points based upon IFPUG standards. The hours spent by us per function point turned out to be 12.72, where as our competitors ended up spending 14.63 hours per function point. Lets stop here and do an initial estimate by just considering the rate / hr and productivity levels. CresSoft Competitor

Initial Estimate 7200 hrs 6000 hrs

Rate / hr USD 50 USD 40

Actual Hours 7200 8280

Total Cost USD 360,000 USD 331,200

An overall study of all development work done by CresSoft, following the standards set out by IFPUG, has revealed that we are 11% more productive than the average US software development organizations. This can mainly be attributed towards our well defined estimation and development methodologies, our focus on particular industries where we have immense domain expertise, the experience of our people and our amazingly low attrition rate.

8

copyright 2001,CresSoft, Inc.

True Cost of Developing Software

3.2 On-Time Delivery & Overhead Costs There were no slippages in our given estimates thus saving the customer any unplanned overhead costs. The customer was able to meet the expectations of its clients resulting in higher yields of ROI for them. Our competitor had a slippage of 38% from their original estimates. This meant that the overhead costs calculated to be 30% of the estimated development amount also went up to 60% for the extra development time needed to complete the project. The numbers are represented below Original Overhead Costs CresSoft Competitor

USD 108,000 USD 72,000

Slippage

Additional Overhead costs (60% of Slippage) USD 0 USD 54,720

0% 38%

Total Cost Software

of

USD 468,000 USD 457,920

The above-mentioned overhead costs are for the slippage from the initial estimates. 3.3 Quality Moving on we discovered that the quality of our system was 98% higher than our competitors. We encountered one bug in the production system constituting 2 function points where as our competitors had 9 software discrepancy reports (SDRs) generated each constituting 16 function points. As defined earlier the total number of function points identified was 566. Given it took our competitor 8280 hours to deliver these the average time spent per function point was 14.63 hrs. Similarly for CresSoft the average time spent per function point was 12.72 hrs. As mentioned earlier the cost to fix a function point postproduction is 10 times higher thus the figures now amounted to the following

CresSoft Competitor

Current Cost USD 468,000 USD 457,920

Bugs in FPs 2 144

Hours req. for bug fixing (FP*10* Avg time per FP) 253 21067

Bug Fixing Cost USD 12,650 USD 842,680

Total Cost of Software USD 480,650 USD 1,300,600

The overhead cost for post-production bugs is also approximately 60% of the development cost for fixing the bugs. These overhead costs are mainly attributed towards live customers accessing the functionality. In business applications, every new patch applied to the product translates to an acceptance-testing phase with the customer to ensure that there are no ripple effects. The below mentioned table factors in these costs to portray the overall picture.

9

copyright 2001,CresSoft, Inc.

True Cost of Developing Software

Bug Fixing Cost CresSoft Competitor

USD 12,650 USD 842,680

Increase in Overhead costs (Due to Bug Fixing) (60% of Bug Fixing cost) USD 7,590 USD 505,608

Total Cost Software

of

USD 488,240 USD 1,806,208

A study of all applications developed by CresSoft concluded that our quality is 99% higher than the industry average given by IFPUG. Due to the high quality of our deliverables, our competitors’ cost had already shot up at least 3 times our cost. 3.4 Flexibility Due to lesser changes in the system developed by CresSoft, as compared to our competitors we ended up having a more stable architecture and design. Secondly having expertise in domain and technology allowed us to effectively provide hooks in the design to handle future requirements effectively. Our experienced resources ensured that our productivity level remains high and our methodology allowed us to meet our customer expectations in terms of time and budget without compromising the flexibility in architecture. Our competitor though, lacked the level of domain expertise we had for this particular project and were not able to manage their attrition rate as an organization. Thus inexperienced resources ended up working on the project and hence hampered not only their overall productivity but also the quality of the delivered product. Considering the fore-mentioned concepts of flexibility, the four factors account for 50% increase in the total cost of software. As they all carry equal weight towards this increase in cost, not managing two leads to a 25% increase in the total cost of software. The end numbers are represented in the following table

CresSoft Competitor

Total Accumulated Cost for Software Delivery USD 488,240 USD 1,806,208

Lack of Domain (12.5% of Accumulated cost)

People (12.5% of Accumulated cost)

USD 0 USD 225,776

USD 0 USD 225,776

Total Cost Software

of

USD 488,240 USD 2,257,760

This study concluded that the cost of our competitor ended up being 4.6 times higher than our cost. Our competitor rated higher or equivalent to the US industry average given by IFPUG. This study revealed that by implementing the right processes and development methodologies, focusing on particular industry niches, maintaining high standards of quality and retaining experienced and motivated staff, we have managed to reduce the overall cost by 5 times as compared to US industry standards.

10

copyright 2001,CresSoft, Inc.

True Cost of Developing Software

4. Reference Reading Applied Software Measurement (Capers Jones) Why Does Software Cost So Much? (Tom Demarco) Software Engineering Economics (Barry W. Boehm) Object Oriented Software Metrics (Mark Lorenz, Jeff Kidd) Decline & Fall of the American Programmer (Edward Yourdon) Mythical Man-Month (Frederick P. Brooks, Jr) International Function Point Users Group (IFPUG) Guidelines for Function Point Estimation CIO Magazine, Oct 1999 Forrester Research, 1999

11