Title:  How to Prepare Quotation Using Use Case Points
Author:      Shivprasad Koirala 
Email:       shiv_koirala@yahoo.com
Environment: Design phase and estimation
Keywords:    Estimation, Use Case Points, Function points,quotations,Software measurements
Level:       Intermediate

Index

The whole article is extract from my book "How to prepare software quotation". Its complete free e-book which you can download in  PDF format from (Do not click directly right click and save as ) http://k.1asphost.com/UseCasePoints/UseCasePoints.pdf  .

Introduction

"You can not plan if you can not measure AND IF YOU FAIL PLAN YOU HAVE PLANED TO FAIL."

Quotation :- Its a financial document send from supplier to customer regarding service to be provided. Its also called as temporary financial document for negotiations." A statement of price, terms of sale, and description of goods or services offered by a supplier to a prospective purchaser, a bid. When given in response to an inquiry, a quotation often is considered an offer to sell."
Definition Reference from [http://elmo.shore.ctc.edu/jbaker/glossery.htm].

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.

“Mr. Harry gets a contract of delivering 10 tons of steel from place “X” to place “Y”.He has 2 trucks each can carry 5 tons each. Place “X” and place “Y” are 1 KM(Kilometer) apart.”

So here’s Harry’s calculations on experience basis ,one truck if delivers 5 tons for 1 KM is 500$.So on 2 truck it is 1000$.So the quotation is 1000$.Just wondering can we do that with software industry. There are 100 modules company has 5 programmers every programmer can complete 20 modules in 3 months. Every programmer salary is 1000$ so 5 X 1000 X 3 = 15000$.The truck quotation calculation is more confident than software quotation why? .
    In trucks quotation harry had followed the following process :

So basically Harry had measurement of his work. He knew the volume of what he has to deliver, that’s the problem with software industry. As software industry output is more in to logical output its difficult to measure linearly the effort required to complete a project and hence the quotation. Software industry is struggling for past 40 years to come to standard of measurement and that’s where all the mess is. Many ideas and measurement methodology has been proposed by researchers. Each have there own advantages and disadvantages.Heres some of the measurement methodology

Do not be tensed by some unheard technology described above, its only provided for knowledge base. Links are provided for McCabe's complexity, Henry and kafura's information flow, Halstead measurement complexity and LOC. I have just mentioned them as they are old measurement technologies. If any one want to explore it see my references section. This tutorial will look in to Use Case Points methodology and looks in to its advantages and disadvantages. So in this article we will basically go through use case point theory and then take up practical example of a Use Case and prepare quotation according to it.

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.

Table 1.0
Acronym Full form Definition
UCP Use case point Use Case points method is a software sizing and estimation based on Use case document.
UAW Unadjusted actor weights A numeric sum of value of actors after giving the classification and before multiplying the technical complexity factor of the system. (When you go through steps of how to calculate UAW this will be more clear)
UUCW Unadjusted Use case Weight A numeric sum of value of Use cases after classifying and before multiplying the technical complexity factor of the system. (When you go through steps of how to calculate UUCW this will be more clear)
UUCP Unadjusted Use Case Points Sum of UAW and UUCW
API Application program interface Application programs used for accessing services provided by some lower-level module (such as operating system)
GUI Graphical user interface A computer terminal interface, such as Windows, that is based on graphics instead of text.
Use Case Transactions Its an atomic set of activities that are either performed entirely or not all.
Tfactor Technical factor Total of all technical factor. See for more details in steps in estimation. See table 4.0 for more details.
TCF Technical Complexity Factor Factor which defines the complexity of the project. For more details see steps for UCP estimation.TCF is calculated from Tfactor.
EF Environment Factor This is multiplying factor.
AUCP Adjusted Use Case Points This the value obtained after multiplying with Efactor and Tfactor.
LOC Lines of Code Lines of code is counting metrics to measure volume of software product.
OOP Object oriented programming A programming technology in which program components are put together from reusable building blocks known as objects.[http://www.lcmug.com/glossary_O.htm]
UML Unified Modeling Language Stands for Unified Modeling Language. UML is a standard notation and modeling technique for analyzing real-world objects, developing systems, designing software modules in object-oriented approach. UML has been fostered and now is accepted as a standard by the group for creating standard architecture for object technology, OMG (Object Management Group).[Definition taken from http://software.fujitsu.com/en/Jasmine/yougoe.html]
UUCFP  Unadjusted Use Case Flow Points Details are provided in this article. http://www.qaiindia.com/Conferences/presentations/gautam_birlasoft.pdf
FP Function Points A sizing methodology for software projects based on functions of the software.

Assumptions:

  1. 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.
  2. 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. There are lots of tutorials on internet and also in reference section of this article the list is provided.

History and Definition of Use Case Points

Working in Ericsson in the late 1960s Ivar Jacobson devised Use-Case Documents. Thanks to Ivar Jacobson to come out with such a wonderful way of communication by using Use Case Documents. Later Use Case Documents became subset of UML. In 1994, Alistair Cockburn constructed the 'Actors and Goals conceptual model' while writing use case guides for the IBM Consulting Group. It provided guidance as how to structure and write use cases. It’s the document which can stand not only for programmer, architecture but also for the stake holders. Its document which stands between the Customer and Programmers/Architecture/Business analyst/Etc.It also serves as handover when any new programmer comes in the project. Use Case document also serve as valuable input to the design of software. In short it serves in the whole life cycle of software development.Karner identified that this document can also be used to measure and estimate effort. This tutorial will make a walk through of karners work and give one sample example.So let’s start with the definition.
Use Case Point is software sizing and measurement based on Use Case Document." Use Case Point" is based on work by gustav karner in 1993.It was written as a diploma thesis at university of linkoping This work is modification of work by Allen Albrecht on function points.

Steps for UCP(Use Case Points) estimation

  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

    Table 2.0
    Classification Litmus test to recognize classifications Value/Factor
    Simple actors Simple actors are those which communicate to System through API. 1
    Average actors Average actors are recognized if they following properties
    • Actors who are interacting the system through some protocol(HTTP,FTP, or probably some user defined protocol) 
    • Actor which are data store(Files, RDBMS)
    		 2
    Complex Complex actor is interacting normally through GUI. 3
  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.

    Table 3.0
    Use case Type Litmus test to decide the Classification Value/Factor
    Simple  Greater than or equal to 3 transactions  5
    Average  Between 4 to 7 transactions 10
    Complex Greater than 7 transactions 15
  3. Determine Total UUCP (Unadjusted Use Case Point) : Total UUCP = Total UAW + Total UUCW
  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.

    Table 4.0
      Technical factor Weight Description
    t1 Distributed System 2 Is the system having distributed architecture or centralized architecture? 
    t2 Response time  1 Does the client need the system to fast? Is time response one of the important criteria? 
    t3 End user efficiency 1 How's the ends users efficiency? 
    t4 Complex Internal Processing 1 Is the Business process very complex ?. Like complicated accounts closing,Inventory tracking,heavy tax calculation etc.
    t5 Reusable Code 1 Do we intend to keep the reusability high. So will increase the design complexity.
    t6 Installation Ease 0.5 Is client looking for installation ease?.By default we get many installers which create package. But if the client is looking for some custom installation probably depending on module wise .One of our client has requirement that when the client wants to install he can choose which modules he can install. If the requirement is such that when there is a new version there should be auto installation. These factors will count when assigning value to this factor.
    t7 Easy use 0.5 Is user friendly at the top priority?
    t8 Portable 2 Is the customer looking for also cross platform implementation?.
    t9 Easy to change 1 Is the customer looking for high customization in the future?.So that also increases the Architecture design complexity and hence this factor. 
    t10 Concurrent 1 Is the customer looking at large numbers of users working with locking support. This will increase the architecture complexity and hence this value.
    t11 Security objectives 1 Is the Customer looking at having heavy security like SSL or have to write custom code logic for encryption.
    t12 Direct access to third parties 1 Does the project depend in using third party controls. So for understanding the third-party controls and studying its pros and cons considerable effort will be required. So this factor should be rated accordingly.
    t13 User training facilities 1 Will the software from user perspective be so complex that separate training has to be provided. So this factor will vary accordingly.
  5. Equation for Tfactor = sum(T1....T13)
  6. TCF(Technical Complexity Factor) : TCF = 0.6 + (0.01 * Tfactor).
  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.

    Table 5.0
      Environmental Factor Weight Description
    e1 Familiarity with project 1.5 1.5
    Are all the people working in the project familiar with domain and technical details of the project?. So probably you will spend your most time in explaining them all know-how's.
    e2 Application experience 0.5 How much is the application experience? 
    e3 Objects-oriented Experience 1 As use-case documents are inputs to Object oriented design. Its important that people on the project should have basic knowledge of OOP's concept.
    e4 Lead analyst capability 0.5 How the analyst who is leading the project?. Does he have enough knowledge of the domain?.
    e5 Motivation 1 Are the programmers motivated for working on the project. As instability in project will always lead to people leaving half way there source code. And the hand over becomes really tough. This Factor you can put according to how software industry is going on? Example if the software market is very good put this at maximum value. As good the market more the jobs and more the programmers will jump.
    e6 Stable requirements 2 Is the client clear of what he wants?. I have seen clients expectations are the most important factor in stability of requirements. If the client is of highly changing nature put this value to maximum.
    e7 Part-Time Staff -1 Are there part-time staffs in project like consultants etc?
    e8 Difficult programming language -1 How the language complexity Assembly,Vb6,c++,c etc
  8. Efactor = SUM(e1...e8).
  9. Calculating Environmental Factor = EF = 1.4 + (-0.03 * Efactor)
  10. AUCP (Adjusted Use Case Points) : Finally calculating the Adjusted Use case points.
    AUCP = UUCP * TCF * EF
  11. Multiplying by Man/Hours Factor : AUCP * Person/Hours/AUCP.

    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. 
TNC 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 TNC manually check for the validations and enters in the customer registry.TNC wants the data entry project to be automated.
TNC is looking for the following automation:

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%.

Table 6.0
Use Case # DATAENTRYPROJECTCUST-1009
Use Case Name
 Maintain Customer
Description
 This use case depicts full maintenance of customer from project "Data Entry".
Scope and Level
  • Data Entry System (Internal) 
  • Credit Card System (External)
Level User Goal Level (If this property is not understood look at the reference for the book Writing Effective Use Cases (**PRE-PUB. DRAFT#3**) :Alistair Cockburn Humans and technology)
Primary and secondary actors Data Entry operator.
Stakeholders and Interests
Trigger Data entry operator clicks on Menu "Add New Customer"
Preconditions
  • Data entry operator should be logged in.
  • Data entry operator should have access to internet.
Assumptions Customer information received is entered manually. No Automated Import routine is in the Scope.
Failed End Condition
  • Customer is not added to Database and appropriate error message is displayed. 
  • Customer Code already existing in the Customer Database. 
  • Customer Code length limit is exceeded. 
  • Customer Credit Card limit is exceeded. 
  • Customer Credit Card validation failed with the payment gateway. 
Action Add New Customer
Main success scenario (or basic Flow):
  1. Data entry operator receives customer information. 
  2. Data entry operator enters following information
    • Customer Code
    • Customer Name
    • Customer Address
    • Customer Phone
  3. Customer Code is checked if it exists in Customer Table. 
    • If the Customer Code is existing then "Duplicate Customer Code" error is raised. 
    • If the Customer Code is more than 8 length then "Customer code length limit crossed" error is raised.
  4. After step 3 is passed ok.Data entry operator enters Credit Card information.
    If the credit card length is more than 10 length then "Credit card length limit crossed" error is raised.
  5. Credit card information is send to the external payment gateway. Appropriate APIs of the external payment gateway will be used for validity.
  6. External Payment Gateway returns "OK" if credit card is validated or else will return "NOT VALID" flag.
  7. Data entry operator then Adds the customer in database. 
Alternate scenario (Extensions): Update Existing Customer
  1. Data Entry operator enter Customer Code to retrieve the customer which has to be updated.
  2. Data Entry operator make appropriate changes to the customer information. All steps and business validation from to 6 of Add new Customer is repeated. 
  3. Data Entry operator update the customer information. 
Alternate scenario (Extensions): Delete Existing Customer
  1. Data Entry Operator enters Customer Code to retrieve the Customer which has to be Deleted.
  2. Data Entry Operator Deletes the Customer. Data Entry Operator is alerted "Are you sure you want to delete the Customer?”
  • If the Data entry operator clicks "Yes". Then the customer is deleted from the database.
  • If the Data entry operator click "NO" no action is taken.
Success Guarantee (Post conditions)
  • Customer is added to Customer Database.
  • Customer is updated to Customer Database.
  • Customer is deleted from Customer Database.
Special Requirements (including Business rules):
Technology and Data Variations List: If Credit Card Payment Gateway API changes the interaction of the data entry customer module will have to changed accordingly.
Frequency of occurrence:
Notes and Open Issues:

Applying Use Case Points:

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

 

Final quotation:

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

Table 9.0

XYZ SOFTWARE COMPANY 

To: 
TNC Limited, Western road 17, California.
Quotation number: 90
Date: 1/1/2004 
Customer ID: - 20090DATAENTRY
Quantity  Description  Discount  Taxable  Total 
1 Data Entry Module 0% 0% 840 $
Quotation Valid for 100 days
Goods delivery date with in 25 days of half payment
Quotation Prepared by: - XYZ estimation department
Approved by :- SPEG department XYZ

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 :

Advantages of Using Use-Case Points

Disadvantages of Using Use-Case Points

Other General Practical Factors

The below points are not related to Use as such but general while making estimation.

References

It would be selfish on part to say that the whole article is my own wisdom. So I have provided all the links i have referred to prepare this article. If any of the link is copyright and not to be produced please email me at shiv_koirala@yahoo.com I will see to my best that i preserve the copyright.

Last Words

Software war for the best estimation has been going on for years. I am not pointing in this article that Use Case Point is the best way to do estimation. So you will find i have introduced the advantages and disadvantages section .But definitely we have to measure , one day we have to unify on a common measurement principle. If we can say in real life city "xyz" is 100 kilometers far why can not we say this project is of 1000 complexity,200 function points or 650 use case points. Different languages, Different compliers, Different processes companies follow has made it difficult to come to common grounds and common measurement.But the largest hurdle we see is the software companies attitude to come to common conclusion of how to measure. If software can automate human complexity then software measurement also can be automised.

"We should no longer ask if we should measure, the question today is how ?" - Dieter Rombach Eurometrics 1991"
"Do not quote too less that programmers work for over night, you lose the project or end doing social service, or loss. Do not quote too high that you lose the project. Be fair to yourself and your customer."

Shivprasad Koirala. Mail me at shiv_koirala@yahoo.com.