"You can not plan if you can not measure, and if you fail to plan, you have planned to fail."
"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 send from supplier to customer regarding service to be provided. It's 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 here.
Quotation is one of the important aspects of software cycle. Any prediction less or more 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 on experience basis. 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:
So basically, Harry had 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 in to 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 there own advantages and disadvantages. Here are some of the measurement methodologies used:
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, its 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.
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.
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 Use Cases. There are lots of tutorials on the Internet. And also in the References section of this article, a list is provided.
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.
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.
Karner 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.
Let's start with a sample fiction project. Here's 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 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:
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%.
If credit card payment gateway API changes, the interaction of the data entry customer module will have to be changed accordingly.
Let's start applying Use Case Points to the above given document.
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.
So here is the final quotation to the scope defined and the Use Case document.
XYZ SOFTWARE COMPANY
To:TNC Limited, Western road 17, California.Quotation number: 90Date: 1/1/2004Customer ID: - 20090DATAENTRY
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.
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:
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:
The below points are not related to Use Case as such, but general while making estimation:
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 firstname.lastname@example.org. I will see to my best that I preserve the copyright.
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 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. Mail me at email@example.com.
This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.
A list of licenses authors might use can be found here
I am a Microsoft MVP for ASP/ASP.NET and currently a CEO of a small
E-learning company in India. We are very much active in making training videos ,
writing books and corporate trainings. Do visit my site for
.NET, C# , design pattern , WCF , Silverlight
, LINQ , ASP.NET , ADO.NET , Sharepoint , UML , SQL Server training
and Interview questions and answers
General News Suggestion Question Bug Answer Joke Rant Admin
Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.