Search This Blog

2009-05-27

Cost Estimation using use case points

Quotation is one of the important aspect of software cycle. Any prediction less or more will affect the project a lot. Lets look at how basically day to day business manage there way of handling quotations.
Acronyms and Abbreviation:
Note: Have these acronyms in hand always as they are used through out the tutorial. Do not be tensed by the acronyms below they are for reference sake and as you proceed ahead with the tutorial you will have more clear picture what exactly they are.


Assumptions:
Readers have basic knowledge of how to write uses cases. This tutorial does not cover use cases and is only limited to estimation by "Use Cases".So if you are reading this article with out the cleared concept of Actor,Role,Scenarios.Its better not to read.
Use case structure varies from organization to organization which can seriously impact the Estimation. This tutorial has used Alistair Cockburn's template from Writing Effective Use Cases (**PRE-PUB. DRAFT#3**): Alistair Cockburn Humans and technology.

  • Scope:
    This tutorial is only till understanding Use Case points and does not get in to details of how to write use cases. This article will not concentrate on how to write uses cases.
  • Steps for UCP(Use Case Points) estimation
  • Step 1. Determine the UAW (Unadjusted Actor weight) : The first step is to classify all the actors in to following classification. Table 2.0 will give you clear idea of how to classify the actors. Second column is the litmus test for making decision which type of actor falls in which category. The last column provides the factor of complexity .



Step 2.Determine number of UUCW (Unadjusted Use case Weight): The second step is to count Use Cases and assign weights depending on number of scenarios and number of transactions.


Step 3.Determine Total UUCP (Unadjusted Use Case Point) : Total UUCP = Total UAW + Total UUCW

Step 4.Computing technical and environmental factor: Final step is to take in to account the technical complexity. All technical factor will be assigned a value from 0 to 5 depending on complexity.



Step 5.Equation for Tfactor = sum(T1....T13)

Step 6.TCF(Technical Complexity Factor) : TCF = 0.6 + (0.01 * Tfactor).

Step 7.EF(Environmental Factor): There are other factors like trained staff, motivation of programmers etc which has quiet a decent impact on the cost estimate.



Step 8. Efactor = SUM(e1...e8).

Step 9.Calculating Environmental Factor = EF = 1.4 + (-0.03 * Efactor)

Step 10.AUCP (Adjusted Use Case Points) : Finally calculating the Adjusted Use case points.
AUCP = UUCP * TCF * EF

Step 11.Multiplying by Man/Hours Factor : AUCP * Person/Hours.

Karner[13] proposed a factor of 20 staff hours per use case point for a project estimate.

While sharks states that field experience has shown that effort can range from 15 to 30 hours per use case point.

Schneider and winters proposed number of staff hours per use case point depends on the environmental factors. The number of factors in E1 through E6 that are below 3 are counted and added to the number of factors in E7 through E8 that are above 3. If the total is 2 or less, the general idea is to use twenty staff hours per UCP; if the total is 3 or 4, use twenty-eight staff hours per UCP.If the number exceeds 5, it is usually recommended that changes should be made to the project so the number can be adjusted because, in this case, the risk is unacceptably high. Another possibility is to increase the number of staff hours to thirty-six per use case point.

Sample project scope (Sample Data entry project):

  • Lets start with a sample fiction project.Heres the scope of the project. MRB company till now was using manual way of maintaining its customer database and there credit card information. Data entry operator manually validates credit card information from external payment gateway. They maintain Customer Code, Customer Name, Customer Address, Customer phone and validated Customer Credit card information in Customer registry. Customer Code is unique for a customer So MRB manually check for the validations and enters in the customer registry.MRB wants the data entry project to be automated.MRB is looking for the following automation:
  • Customer Code assigned should be checked for uniqueness automatically.
  • Customer Code should not exceed 8 length.
  • Credit card validation should be automatic for the current System.MRB has already given the API documentation of how to interact with the third party payment system.
  • Credit card length should not exceed more than 10 length.
  • Data entry operator should be able to add/update/Delete customer information.
  • The database will be in the MRB head office and only data entry operators will be allowed to use the Data entry Software.
  • Software should work on Windows platform. At this moment MRB has Windows 2000 client installed in all computers.
  • Writing use case for Sample Data Entry Project:
    I have used Alistair Cockburn's template for the "Use Case point" example. Use Case Template varies from person to person, project to project and organization to organization. I found Alistair's template to be complete so just took it. But there's no hard and fast rule that you have to follow this template. What will matter is what steps you write in the Use Case.
  • Use Case Transactions: It’s an atomic set of activities that are either performed entirely or not all. What is a use case transaction and what’s not just see if the transaction is adding any business value or else do not include it as a transaction. Example the user switches on the computer, user clicks on add button or any GUI is not valid business transaction step. But example the Customer Code is validated for credit card information is a valid business transaction. Use Case points are heavily affected by the way the Actors and its transactions are identified. So Use Case Document should be written by predefined guidelines, uniformly in a project. Just take a meeting with whole project team before starting writing Use Case. As the depth of the Use Case Document will affect estimation by 40%.



Applying Use Case Points:

Let Start Applying Use Case Points to the upper given document.

Determining Unadjusted Use Actor Weights (UAW): In this project we have identified only one actor “Data Entry Operator”. The upper Actor (Data entry operator) is complex as data entry operator will be interacting through GUI.So UAW=3 as per table Table:2.0.
Determine number of UUCW (Unadjusted Use case Weight): There are 12 transactions [Adding also the alternative flows] in Table 6.0 Use Case. So the above Use Case is complex according to Table:3.0.So referring Table:3.0 UUCW=15.
Now calculating the total UUCP = 15 + 3 = 18.
Determining the technical Factor



Depending on the table calculating the Technical Factor: TCF = 0.6 + (0.01 * Tfactor) = 0.6 + (0.01 * 19) = 0.79

Calculating environmental factor

According to [Kirsten Ribu Master of Science Thesis] Environmental factor play very important role in the estimation. A slight variation will increase the use case point by very very drastic amount. Even small adjustments of an environmental factor, for instance by half a point, can make a great difference to the estimate. Difference 3 to 2.5 increased the estimate by 4580 hours, from 10831 to 15411 hours, or 42.3 percent. This means that if the values for the environmental factors are not set correctly, there may be disastrous results -- Sources [Kirsten Ribu Master of Science Thesis] Do see links below.
  • Using formula for calculating EF = 1.4 + (-0.03 * Efactor) = 1.4 + (-0.03 * 23.5) = 0.695
  • Calculating AUCP = UUCP * TCF * EF = 18 X 0.79 X 0.695 = 9.88 approx = 10 Use Case Points.I have out the approximation as its only creates 3 to 4 hours of difference.
  • Calculating According to Karner i.e 20 staff hours per use case points = 10 X 20 = 200 hours for the total project.
  • If programmer works for 8 hours for a day then 200/8 = 25 days.
  • Calculating according to Schneider and winters from e1 to e6 there are only 3 properties that are below 3.and from e7 to e8 there are none value above 3.So the total is 3 so we use 28 staff hours.10 X 28 = 280 hours. If programmer works for 8 hours then 35 days. If this step is not understood look at the steps defined in theory of use case points.
  • If we apply sixth sense we will find karner approach is coming to round about figure. It really depends what you want to follow karner or Schneider approach. Best is that after 2 or 3 projects what’s ever is coming accurate from history take that approach. Best approach is to use excel and incorporate formulae's properly.

    Final quotation:

    So here the final quotation to the scope defined and the use case document.




    In this quotation I have taken karners value that’s 25 days. One programmer will sit on the project with around 1000 $ salary. So his 25 days salary comes to 840 dollars approx. The upper quotation format is in its simplest format. Every company has his quotation format accordingly. So no hard and fast rule of quotation template.But still if interested http://www.microsoft.com/mac/resources/templates.aspx?pid=templates has good collection of decent templates.

    Use-Case structure Matters :
    The structure of use-case matters a lot. According to (Bente Anda,Hege Dreiem,Dag I.K Sjoberg and Magne jorgensen) the following aspects of structure has an impact :
    The use of generalization between actors : If two actors have 80 percent in common put them in generalization relationship and count them only once. This will increase the accurate of the estimate.
    The use of included and extending use case :Karner recommends that included and extending use case should not be counted. But according to (Bente Anda,Hege Dreiem,Dag I.K Sjoberg and Magne Jorgensen) have a different opinion in there practical experience. In some use cases they found include and extended use cases as essential functionalities and reducing them will reduce steps and hence the estimation.
    The level of detail in the use case description. ( This is dependent on the guy who writes the use case )The level of detail and transaction in use case impact the use-case estimation a lot. If you see the upper use-case if I had written steps like user switches on the PC etc.The transaction would have increased and hence estimation. So if that transaction step is not adding business value do not add it as transaction step. This will also increase the estimation to a good level.Including the above recommendation by Karner and (Bente Anda,Hege Dreiem,Dag I.K Sjoberg and Magne jorgensen) here are also my inputs which can be followed to make a estimate better :-
    Use-Case Splitting and MergingSimple Use-Case masters matter a lot. Writing use-cases for example “Adding Country Master". User can write 3 different use cases for Add, Update, Delete or he can write one use-case and put the Update and delete in alternate scenarios. If the Update and delete do not have different business validations put them in one use-case. During my counting I had seen that accuracy increases if for simple master we put them in one use-case.
    Advantages of Using Use-Case Points
    Automation : Use Case document if structured properly for a company (Uniformly) we can use automation tools. In case of FP this is difficult.
    Disadvantages of Using Use-Case Points
    Can not be used during initial phase: Estimations are normally done at earlier stage of projects. When we say earlier means during the first and second meet with the client. Use case documents are mostly prepared after the project sign off. So during earlier stage this document will not be available. Preparing Use Case document during first and second meet with client means wasting your resources in case you do not get the project. For initial phase of project you can use “Function points”. For function points no formal document is needed. My old tutorial on function points http://www.geocities.com/shiv_koirala/fp/fp.html.
    No Standard Use Case Document:The document structure of use is not standard still. It varies not only from company to company but also from project to project. So the estimation has significant variance according to structure of Use Case documents. Even the writing matter to a large extent. And also how one does identifies use-case and the transaction associated with it. Free textual descriptions may lead ambiguous specification [AP98].
    Maintenance estimation problems:Function point [ http://www.geocities.com/shiv_koirala/fp/fp.html ] failed for maintenance projects. It will be difficult from Use Case Points to do maintenance estimation.
    Actor identification need technical details:In order that the actor be classified we need to know technical details like which protocol the actor will use. So estimation can be done by technical guys.FP is not technical dependent [http://www.geocities.com/shiv_koirala/fp/fp.html].
    Other General Practical Factors
    The below points are not related to Use as such but general while making estimation.
    Change of psychology :Estimator should not be biased. If you are employee of the company do not add extra charge or subtract extra charges. These all things will be handled at the negotiation tables between the software company director and the customer. A estimator job is to show the real cost of the software to the company. In short estimator should not be bothered about negotiation phase and will we get this project or not?. Leave that work to the companies director. And if you are the director of the company think that thing after estimation is over.
    Sixth Sense Approach:Any of the software measurement ways ( Use case, Function points, LOC etc) are evolving and under practice. After looking the figure try to give Sixth sense based on your past experience. Some time estimation will be fair if went the ADHOC way.
    Modular Estimation:In huge projects with 100 of modules its better to estimate modular wise. Example if a client is asking for a customer module, Supplier module and Accounts module. Estimate them differently so that on negotiation table with client you can show him the complete break up. Second this approach is very useful for phase wise estimation. Client can decide either to not take the module (Due to financial concerns) or move it to phases.
    Information Creep and Grey Areas:Estimation are normally done at the initial phase itself probably with one or two meets with client we have to give estimation. So but natural many of the areas there can be creep. The best way for such situation is to think the maximum possibility and estimate. Example if any customer says that he needs chat module and no clarification is made till what the depth it is, estimate to maximum possibility of how can chat application are made. Later during negotiation table show client the estimation basis. So according to the client financial budget changes will be made.
    Other Costing :Any of the Software estimation methodology do not give cost for non-software factors.
    If the software is using any third-party components example crystal reports etc estimate them in a ADHOC way.
    Example if in the project company is also providing web hosting, domain name, hard ware etc put them separately.
    Any training involved estimate them separately.
    Assumptions: As estimation is done at the initial stage there can be lot of creep and gray areas. Due to gray areas estimation has to be supported by proper assumptions.
    Review from Third Party: Before sending the costing to the client review it internally from third person who is not involved in the project.
    Iterations:Iterate it as many as times possible and at various phases. Example use function point to iterate during scoping phase that's initial phase. And Use case Point during the System requirement phase. This gives a good idea before implementing that is the costing proper
    Two teams Estimation:During estimation have two teams which will do the estimation. So that cross verification can be done on the error percent of the estimation.

    Resource:USE CASE Estimation Document written by Shivprasad Koirala

    1 comment:

    Unknown said...


    Heya¡­my very first comment on your site. ,I have been reading your blog for a while and thought I would completely pop in and drop a friendly note.
    Function Point Estimation Training