How to Prepare Quotations (Project Estimates) Using Use Case Points

Introduction

"You can not plan if you can not measure, and if you fail to plan, you have planned to fail."

Quotation: It's a financial document sent from a supplier to a customer regarding service to be provided. It's also called a 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 here.

Quotation (Project Estimation) is one of the important aspects of software cycles. Any prediction more or less will affect the project a lot. Let's look at how basically day to day businesses manage their ways 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 based on experience. One truck if delivering 5 tons for 1 KM is $500. So for two trucks, it is $1000. So the quotation is $1000. Just wondering, can we do that with software industry. There are 100 modules, and the company has 5 programmers. Every programmer can complete 20 modules in 3 months. A programmer's 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:

• Harry had measurement of his work: 10 tons to be delivered. 1 KM to be traveled.

• Harry knew what effort will be required: 5 tons/per truck/per KM.

• So the quotation: $1000.

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

• McCabe's Measurement of complexity.

• Henry and Kafura's Information Flow.

• Halstead measurement of complexity.

• Lines of Code (LOC).

• Function Points. (My old tutorial on function points.)

• Use Case Points.

Do not be tensed by some unheard technology described above, it's 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 wants to explore them, see my References section. This tutorial will look into Use Case Points methodology; it's advantages and disadvantages. So in this article, we will basically go through Use Case Point theory, and then take up a practical example of a Use Case, and prepare a quotation according to it.

Acronyms and Abbreviation:

Note: have these acronyms in hand always as they are used throughout 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 a more clear picture of 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 Programming 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		It's an atomic set of activities that are either performed entirely or not at all.
Tfactor	Technical Factor	Total of all technical factors. 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 is the value obtained after multiplying with Efactor and Tfactor.
LOC	Lines of Code	Lines of code is a counting metrics to measure the volume of a software product.
OOP	Object Oriented Programming	A programming technology in which program components are put together from reusable building blocks known as objects. [Glossary]
UML	Unified Modeling Language	Stands for Unified Modeling Language. UML is a standard notation and modeling technique for analyzing real-world objects, developing systems, and designing software modules in an 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 here]
UUCFP	Unadjusted Use Case Flow Points	Details are provided in this article.
FP	Function Points	A sizing methodology for software projects based on functions of the software.

Assumptions:

1. Readers have a basic knowledge of how to write Use 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 a clear concept of Actor, Role, Scenarios, it's 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 for 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 Use Cases. There are lots of tutorials on the Internet. And also in the References section of this article, a 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 a 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 to how to structure and write Use Cases. It's the document which can stand not only for programmer or architect, but also for the stake holders. It's a document which stands between the Customer and Programmers/Architects/Business analysts/etc. It also serves as handover when any new programmer comes in the project. Use Case Document also serves as a 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 Karner's work and give one simple 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 the University of Linkoping. This work is a 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 the following classification. Table 2.0 will give you a clear idea of how to classify the actors. Second column is the litmus test for making a decision of 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 have the following properties: Actors who are interacting with the system through some protocol (HTTP, FTP, or probably some user defined protocol). Actors which are data stores (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 into account the technical complexity. All technical factors 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 end user's 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 packages. But the client might be looking for some custom installation, probably depending on modules. One of our client has a requirement that when the client wants to install, he can choose which modules he can install. Is the requirement 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 friendliness a top priority?
   t8	Portable	2	Is the customer also looking for cross platform implementation?
   t9	Easy to change	1	Is the customer looking for high customization in the future? That also increases the architecture design complexity and hence this factor.
   t10	Concurrent	1	Is the customer looking at large number 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 do we have to write custom code logic for encryption?
   t12	Direct access to third parties	1	Does the project depend in using third party controls? 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 have 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? Probably you will spend most of your time in explaining them all know-how's.
   e2	Application experience	0.5	How much is the application experience?
   e3	Object-oriented programming experience	1	As use-case documents are inputs to object oriented design, it's important that people on the project should have basic knowledge of OOP concepts.
   e4	Lead analyst capability	0.5	How is 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? Instability in the project will always lead to people leaving half way through their 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. More 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 the 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 staff in projects, like consultants etc.?
   e8	Difficult programming language	-1	How much is the language complexity, Assembly, VB 6.0, 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 points.

Sample project scope (Sample Data Entry Project):

Let's start with a sample fiction project. Here's the scope of the project. TNC company until now was manually maintaining its customer database and their credit card information. Data entry operators manually validated 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 checks 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:

• 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. TNC 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 TNC 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, TNC 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, are not valid business transaction steps. But the customer code validated for credit card information is a valid business transaction. Use Case points are heavily affected by the way the Actors and their transactions are identified. So a Use Case Document should be written by predefined guidelines, uniformly in a project. Just take a meeting with the whole project team before starting writing Use Cases. 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):	Data entry operator receives customer information. Data entry operator enters following information: Customer code Customer name Customer address Customer phone 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. 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. Credit card information is send to the external payment gateway. Appropriate APIs of the external payment gateway will be used for validity. External payment gateway returns "OK" if credit card is validated or else will return "NOT VALID" flag. Data entry operator then adds the customer in database.
Alternate scenario (Extensions):	Update Existing Customer Data entry operator enters customer code to retrieve the customer who has to be updated. Data entry operator makes appropriate changes to the customer information. All steps and business validation from 1 to 6 of Add new Customer is repeated. Data Entry operator updates the customer information.
Alternate scenario (Extensions):	Delete Existing Customer Data entry operator enters customer code to retrieve the customer who has to be deleted. 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 clicks "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 be changed accordingly.
Frequency of occurrence:
Notes and Open Issues:

Applying Use Case Points:

Let's start applying Use Case Points to the above 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: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
   

  Table 7.0
  	Technical factor	Weight	Value	Weighted Value	Explanation
  t1	Distributed System	2	1	2	Simple two tier architecture is decided.
  t2	Response time	1	4	4	Speed is of importance as the data entry operator has to enter data quiet fast.
  t3	End user efficiency	1	3	3	Data entry operator has high user efficiency.
  t4	Complex Internal Processing	1	2	2	Its simple entry screen and no business process has been scoped by the client. Only credit card check and duplicate customer code is the business check.
  t5	Reusable Code	1	1	1	No reusability as project is small and customer is not looking for any further changes for at least two years.
  t6	Installation Ease	0.5	0	0	TNC has good in house development team, and installation problems will be handled by them. Technology thought is C#, and .NET setup wizard will be enough to make the installation process easy.
  t7	Easy use	0.5	4	2	Yes, data entry operator has to have user friendly menus and shortcut keys for fast entry of data.
  t8	Portable	2	1	2	TNC has Windows 2000 client as specified in the scope document.
  t9	Easy to change	1	0	0	None specified by client.
  t10	Concurrent	1	0	0	Client has not clarified about this issue as such in the scope document. So assumed least concurrent.
  t11	Security objectives	1	0	0	None specified by client. Even credit card information will be passed with out encryption.
  t12	Direct access to third parties	1	3	3	Using the credit card check API.
  t13	User training facilities	1	0	0	The screen is simple, and data entry operator can operate without any training.
  	Total			19

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

• Calculating environmental factor
   

  Table 8.0
  	Environmental Factor	Value	Weight	Weighted Columns	Explanation for the value assigned
  e1	Familiarity with project	5	1.5	7.5	It's a simple project, so familiarity with project is not so much needed.
  e2	Application experience	5	0.5	2.5	It's a simple application.
  e3	Object-oriented programming experience	5	1	5	Every one has good OOP knowledge.
  e4	Lead analyst capability	5	0.5	2.5	It's a simple project; no lead analyst needed till now.
  e5	Motivation	1	1	1	Motivation is little down as programmers are reluctant to work on the project because of its simplicity.
  e6	Stable requirements	4	2	8	Client is very clear with what he wants?
  e7	Part-time Staff	0	-1	0	No part time staff.
  e8	Difficult programming language.	3	-1	-3	C# will be used. And most of the programming guys are new to C# and .NET technology.

• According to [Kirsten Ribu Master of Science Thesis], Environmental factor plays a very important role in the estimation. A slight variation will increase the Use Case point by a 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 of 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 formulae 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 done 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 340/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 whose value is above 3. So the total is 3. 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 two or three projects, whatever is coming accurate from history, take that approach. Best approach is to use Excel and incorporate formulas properly.

Final Quotation:

So here is 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 within 25 days of half payment Quotation prepared by: XYZ estimation department Approved by : SPEG department XYZ

In this quotation, I have taken Karner's 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 its quotation format accordingly. So no hard and fast rule for quotation templates. But still if interested, Microsoft has a 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 have 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 accuracy of the estimate. 
  

• The use of included and extending Use Case: Karner recommends that included and extending Use Case should not be counted. But Bente Anda, Hege Dreiem, Dag I.K Sjoberg and Magne Jorgensen have a different opinion in their 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 Use-Case above, I have 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 an estimate better:
  

• Use-Case Splitting and Merging: Simple Use-Case masters matter a lot. Writing Use-Cases, for example "Adding Country Master". User can write three 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

• Cannot be used during initial phase: Estimations are normally done at earlier stage of projects. When we say earlier, it means during the first and second meetings 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 meeting with the 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. 
  

• 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 the structure of Use Case documents. Even the writing matters to a large extent. And also, how one identifies Use-Case and the transaction associated with it. Free textual descriptions may lead to ambiguous specifications [AP98]. 
  

• Maintenance estimation problems: Function point [article] 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 [article].

Other General Practical Factors

The below points are not related to Use Case as such, but general while making estimation:

• Change of psychology: Estimator should not be biased. If you are an employee of the company, do not add extra charge or subtract extra charges. These things will be handled at the negotiation table between the software company director and the customer. An estimator's job is to show the real cost of the software to the company. In short, an estimator should not be bothered about negotiation phase and whether the company gets this project or not? Leave that work to the company's director. And if you are the director of the company, think about that thing after the 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 at the figure, try to give sixth sense based on your past experience. Some times, estimation will be fair if going the ad hoc way. 
  

• Modular Estimation: In huge projects with 100s of modules, it's better to estimate module 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 is normally done at the initial phase itself. Probably with one or two meetings with the client, we have to give the estimation. But naturally, in many of the areas there can be creep. The best way for such situations is to think about the maximum possibility and estimate. Example, if a customer says that he needs a chat module and no clarification is made about what the depth of it is, estimate to maximum possibility of how can a chat application be made. Later in the negotiation table, show the client the estimation basis. So according to the client's financial budget, changes will be made. 
  

• Other Costing: None of the software estimation methodologies give cost for non-software factors. |

  • If the software is using any third-party component, example Crystal Reports etc., estimate them in a ad hoc way.

  • Example, if in the project, company is also providing web hosting, domain name, hardware etc., put them separately.

  • If any training is involved, estimate them separately.
    

• Assumptions: As estimation is done at the initial stage, there can be lot of creep and gray areas. 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 a third person who is not involved in the project. 
  

• Iterations: Iterate it as many as times possible and at various phases. Example, use function points 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 the costing is 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.

References

It would be selfish on my 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 [email protected]. I will see to my best that I preserve the copyright.

• I work presently in Ag-technologies. Thanks to http://www.ag-technologies.com/ for providing me a role in the estimation phase. 
  

• Estimating, Software development effort based on Use Case experiences from industry (Bente Anda, Hege Dreiem, Dag I.K Sjoberg and Magne Jorgensen) 
  

• Use Case Points. 
  

• Use Case Points. 
  

• Writing Effective Use Cases (**PRE-PUB. DRAFT#3**): Alistair Cockburn Humans and technology. 
  

• For dictionary meaning of quotation. 
  

• If your are looking at test effort using Use Case Points, have a look at the paper by Cognizant Technology Solutions in the Quality Week 2001, San Francisco, California, USA, June 2001 by Suresh Nageswaran. 
  

• In this paper, they experimented using UUCFP (Unadjusted Use Case Flow Points) for accuracy. By Gautam Banerjee (Annual IPML Conference 2004) 
  

• Excellent quotation templates at Microsoft. 
  

• Templates. Not necessary to follow exactly as it is but just for reference.
  

• Estimation using Use Case points 
  

• http://heim.ifi.uio.no/~kribu/oppgave.pdf 
  

• Basics of UML. 
  

• My old function point tutorial. 
  

• International Function Point user group. 
  

• An Introduction to Function Point Analysis. 
  

• A good PDF tutorial. 
  

• Master thesis by Sofia Nystedt. 
  

• Good thesis which has details about McCabe's complexity, Henry and Kafura's Information Flow, and Halstead measurement of complexity. 
  

• Definition of UML. 
  

• Definition of Object Oriented Programming.

Last Words

Software wars 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 have 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 automated.

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