| Preparing A Quotation using Case Points |
| 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. |
|
| Let's 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 Environmental 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 |
|
|
