If you want to buy the project management book mail [email protected]  for more details or call any of our book shops MUMBAI-22078296/97/022-22070989, KOLKATA-22826518/19 HYDERABAD-24756967,24756400,BANGALORE-25587923, 25584641,AHMEDABAD-26421611,BHATINA(PUNJAB)-2237387,CHENNAI-28410796,28550491,DELHI/NEWDELHI-23254990/91,23325760,26415092,24691288.If you want to write to the author directly email at [email protected]
 

Home

(B) How do we estimate using Use Case Points?

 

Steps for UCP (Use Case Points) Estimation

 

 

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

Table: - Actor classification

 

 

 

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

Table: - Use case value factor

 

 

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.

Table: - Technical Factor

 

 

 

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.

Table: - Environmental factor

 

 

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

 

 

Sample project scope (Sample Data Entry Project):

 

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:

 

 

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.

 

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

 

 

 

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 .

 

 

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.

 

Note :- Check for the use case points estimation sheet in the CD.

If you want to buy the project management book mail [email protected]  for more details or call any of our book shops MUMBAI-22078296/97/022-22070989, KOLKATA-22826518/19 HYDERABAD-24756967,24756400,BANGALORE-25587923, 25584641,AHMEDABAD-26421611,BHATINA(PUNJAB)-2237387,CHENNAI-28410796,28550491,DELHI/NEWDELHI-23254990/91,23325760,26415092,24691288.If you want to write to the author directly email at [email protected]
 

Home

Hosted by www.Geocities.ws

1