How would you term the word Quotation?
A financial document from a supplier to his customer regarding the services to be provided, or a temporary financial document for negotiations, or a bid! Basically a quotation is an offer to sell to an inquiry from the customer.
Why is Quotation very important? Is it really important?
Quotation is an important aspect of the software cycle as any prediction less or more, directly affects the project.
Lets look at an example:
I got a contract of delivering 10 tons of steel from Colorado to New York. I place 2 Trucks each carrying 5 tons of steel. Colorado is 1000 km(assumption) apart from New York. Now based on my experiences 1 km would cost me $5 so my calculations would be 1000 * 5 * 2 = $10,000(WOW).
Just wondering can we do this with a software? There are 100 modules and I have 5 programmers and each programmer is capable of doing 20 modules in 3 months. Every programmer salary is $1000 so
5 * 1000 * 3 $15000.
Well I would be more confident with the calculations I did for my truck rather than what I did for my software. Why? The simple reason is because I knew the measurement of work: 10 tons to be delivered and 1000 km to be traveled. I also know the effort required: 5 tons per truck and therefore my quotation was perfect according to me.
So basically I had a measurement of my work, I knew the volume I had to deliver, and that’s the biggest problem with the software industry. Software industry’s output is more into logical output, its difficult to measure the effort required to complete a project and hence a quotation. This problem has been there for years now and there are many methods to come to a standard of measurement and that’s where all the mess is. Many ideas and measure methodology have been proposed and all of them have their advantages and disadvantages.
Lets look at Use Case Points methodology and look into its advantages and disadvantages and than take up a practical example of Use Case and prepare quotation according to it.
Acronyms and Abbreviations
| 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 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 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.
Steps of UCP (Use Case Points) estimation
1. Determine the UAW (Unadjusted Actor Weight):
The first step is to classify all the actors.
Table 2 will give you a clear idea of how to classify the actors.
| Classification |
Litmus Test to recognize classifications (helps making decision for which actor falls in which category) |
Value/Factor (factor of complexity) |
| Simple Actors |
Those which communicate through system API |
1 |
| Average Actors |
Recognized by the following category Actors who are interfacing through some protocol (HTTP, FTP, or some user defined protocol) Actors which are data stores (Files, RDBMS) |
2 |
| Complex |
Interacting through GUI |
3 |
2. Determine the number of UUCW (Unadjusted Use Case Point)
The next step is to determine the number of use cases and assign weights /complexity depending on the number of scenarios and transactions.
| Use Case Type |
Litmus Test to decide classifications |
Value/Factor |
| Simple |
>= 3 transactions |
5 |
| Average |
>= 4 and <= 7 |
10 |
| Complex |
> 7 |
15 |
3. Determine Total UUCP (Unadjusted Use Case Point)
Total UUCP = Total UAW + Total UUCW
4. Computing Technical and Environmental factors:
This is the final step where we take into account the technical complexities. All the technical factors can be assigned a value between 0 – 5.
| |
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):
These are other factors like trained staff, motivation of programmers, etc. which has a significant impact on the cost estimate.
| |
Environmental Factor |
Weight |
Description |
| E1 |
Familiarity with project |
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. It's 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 Enviornmental Factor EF = 1.4 + (-0.03 * EFactor)
10. ACUP (Adjusted Use Case Point):
ACUP = UUCP * TCF * EF
11. Multiply by Man/Hours Factor:
ACUP * Person/Hours/AUCP
Note: 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
|
