Producing Use Cases

http://www.codeproject.com/gen/design/pusecase.asp

IntroductionThe foundation of a good application begins with a good design and the foundation of a good design begins with good use cases. Of all the artifacts produced from a software design, use cases are the most important. Use cases capture the business process and, collectively, describe the software application’s functionality from the user’s perspective.

This article overviews use cases and the challenges associated with them, offers tips in their creation and suggests a structured approach to produce them.

What are Use cases?Use cases are a necessary artifact of object-oriented application system design and development. Actually, more than that, they provide the foundation for the design of the entire application since application classes and their relationships emerge from the use cases.

At its simplest, a use case is simply a structured narrative of a domain process that describes the requirements of a software system. Dr. Alistair Cockburn, one of the industry's use case Gurus describes use cases as “sequences of interactions between the system and its external actors, related to a particular goal.” The idea is that users (and systems) have domain goals that need the help of computer systems to achieve them. Examples of goals are registering students, recording sales, and determining baselines. The point is to express the requirement in a way that is simple and understandable to anyone within the problem domain.

The vocabulary of the use case must be expressed in the terminology of the business domain.

Strictly speaking, use cases are not object-oriented artifacts and can be used with any software development paradigm. However, they are typically associated with UML Use Case Diagrams that depict associations (or relationships) between the actors of a system, their responsibilities (or goals) and their boundaries. The use case diagrams provide a visual table of contents, an overview, of the system's actors and use cases.

While UML Use Case diagrams graphically depict use cases, they do not define them.

The real value of a use case lies in its textual description, or its scenario. A scenario is a sequence of action steps the use case takes in order to achieve its goal including any pre and post conditions. A goal can either be successful or it can fail. The use case contains scenarios that describe the goal’s successes and failures. A success scenario is one in which the goal is achieved, a failure scenario is one in which the goal fails but still protects the interests of the stakeholders.

The main success scenario is the typical or normal success path.

Think of the scenario as the execution model (the object instance) of the use case. Use case scenarios, then, provide the foundation for test cases. Additionally, scenarios provide the basis for system documentation and User Manuals.

Use cases, are strategic goals that consist of scenarios that provide value to a business domain.

StakeholdersA stakeholder is someone of some "thing" with a vested interest in the behavior of the system. Not all of the stakeholders are present while the system is executing but the system must protect and satisfy the stakeholders interests at all times. Examples of the stakeholders include company shareholders, customers, vendors, and government regulatory and reporting agencies.

A use case describes the behavior that protects and satisfies the stakeholder’s interests.

ActorsAn actor is anyone or any "thing" that interacts with the system to achieve the system’s goals: individuals, organizations, and other computer systems. Actors are stakeholders who interact with the system. Typically, Actors have behavior and are represented by the roles they play in the use cases; ex: Student, Instructor, Software Developer, etc.. However, Actors are not job descriptions - ex: Programmer I, Manager II - unless the business domain requires it.

Actors have goals that are achieved by use cases.

An Actor stimulates the system by providing input or receiving something from it. The primary actor is the stakeholder that initiates or triggers an interaction with the system to achieve a goal. The primary actor will be the user sitting at a computer or another computer system.

The primary actor is the one that initiates the use case's main success scenario.

Supporting actors are actors that assist the primary actor to achieve the goal. They interact with the use case but do not trigger it. They are often external systems or third party components.

An actor can be the primary actor for one use case and the secondary actor for another.

Use case identificationIdentifying use cases is not as simple as it might initially seem. Several issues need to be considered that can be tricky and crucial to the successful modeling of the business domain. In no particular order, some of them are:

Finding the boundaries of the system. Searching for actors and their responsibilities, or goals. Establishing the scope and level of the use case. Searching for exceptional and failure situations Linking use cases (one use case's post-condition is another's pre-condition).

Moreover, different types of use cases exist and are described by different people in different ways. However, most begin with high level use cases - call them System or Essential use cases - and proceed from there to define more detailed types of use cases.

Use cases can be identified using several methods:

Identify all the actors in the system and define their roles and responsibilities. Identify and partition the system into major areas of functionality. Identify and relate all the events in which the system needs to respond.

Regardless of the method used (or combination), the process usually starts with a brainstorming session, at the high level, and, iteratively, drills down to the details - in other words, breadth-first. Iterations encourage focus. Each iteration focuses on one aspect of the use case. Working too quickly and attempting to capture too much can quickly lead to unrealistic use cases with too much complexity that don't reflect the actual needs of the domain users.

Breadth-First approachUsing the breadth-first approach insures the entire system is covered, if only at a high level. At a minimum, the breadth-first approach identifies all the features of the system from the requirements.

Some of the benefits are:

Complexity is gradually developed and better understood. Initial use cases are developed quickly. Tight schedules can produce as much as needed. Works well with all development methodologies; eXtreme Programming, Agile, etc.. Design is reusable and extensible; later releases will increase depth; each level is a new iteration

(or series of iterations). So, for example, a typical iteration might look like the following:

Iteration 1: Identify the stakeholders, the primary actors and their goals. Iteration 2: For each goal identified in iteration 1, define the main success scenario. Iteration 3: For each success scenario identified in iteration 2, define the alternate scenarios. Iteration 4: For each scenario identified in iteration 3, define the exception conditions.

In Figure 1, the iterations proceed from the right and move down. As they do, problems will surface that provide the motivation to forming new use cases, linking existing use cases, and discarding and combining use cases. In this sense, use cases are refactored during each iteration.

Problems in the early iterations are good and to be expected, but, as the iterations continue, beware of the becoming too focused on the implementation. Use case names that begin with, "Perform..." or "Process..." indicate the use case was written from an implementation perspective rather than from a domain user Perspective.

Use cases are not function calls.

Domain chartsAs the use cases are identified, related use cases will emerge. In the Model Driven Architecture approach, related use cases are grouped together into application domains from which a Domain Chart is developed. Domains are autonomous entities logically grouped by their function. Domain charts depict the system as distinct, independent domains that work together to provide the application’s functionality.

In Figure 2, related use cases for a Book store have been grouped together that shows, at a glance, the major domains in the application. Each domain contains subsystems that implement the domains functionality.

Domain Charts encourage parallel design and development.

ValidationValidation determines the credibility of the use cases and it critical to capture the business process. As the use cases are refactored, ask the following questions:

Does the use case capture the business process? Are there any details that need to be added? Will the actor's goal be met? Can the use case be simplified? Are there any additional goals that are not addressed? Are there any additional actors that are not represented (directly or indirectly)?

Use Case formatsMany use case formats exist and some provide more content than others. There is no single use case format that exists for all projects. Some projects follow a lightweight development methodology that requires less documentation, perhaps because of a tight schedule, other projects are heavyweight and require more documentation, perhaps for mission critical projects.

In Writing Effective Use Cases, Dr. Cockburn describes the following formats:

Fully Dressed: The most elaborate. This template describes the actors, stakeholders, protection of stakeholder’s interests, performance issues, pre- and post conditions, exceptions, notes and annotations. Used when formal and complete documentation is required.

Casual: Written in paragraph style, a few paragraphs at most. Less formal and contains less content than the fully dressed format.

Brief: One paragraph that summarizes the business process. It mentions only the significant steps in the main success and failure scenarios.

Additionally, two other formats can be considered:

Normal: This would be the normal methodology that specifies and defines the design model in more detail than the casual format, but still less than the fully dressed format. Design reviews would be tighter and less forgiving than the Agile approach (below) and more precision and rigor would be applied.

Agile: Projects using this format would practice an Agile Modeling and Development methodology to produce the software very quickly but still contain an acceptable design. The UML artifacts, while complete, would contain less detail than for the normal development methodology and would be oriented more towards the higher level perspective. Smaller projects or projects with tight deadlines might fall within this scenario.

Choose the format that best fits the project.

Modeling Create, Read, Update, Delete (CRUD)Ideally, CRUD functionality is expressed in terms of a business process - the action the user performs. The semantics in use cases are extremely important and should be expressed in the language of the user – not in the language of the developer, the functionality of the system or in database modeling terms. Good design perceives the system from the user perspective.

The problem with CRUD use cases is that they describe the technical implementation without explaining how this is valuable to the user. At best, it is a low level goal that is fulfilled within the context of the use case scenario.

Consider the use cases for a Word Processor. Which states the business case best: Create Style, Update Style, Import Style, Delete Style, or Insure Consistent Formatting within a Document? The latter expresses the goal of the user best. While Create Style, Update Style, Import Style, and Delete Style reflect the functions that occur within the business domain, they don’t express the user’s goal to format her document. Instead the goal has been decomposed into discrete functionality.

Resist the tendency to decompose use cases into functions.

Or, consider another example. For security purposes, its typical for users to login to an application. However, logging in is not a business goal of the user. In other words, the user of say, an inventory system, doesn’t say to herself, “Today, my goal is to login and logout of the inventory system in the most efficient manner possible.” Moreover, the user isn’t evaluated by how well she logs into the system. She won’t get a raise for logging in 45 times in a single day.

Rather than including CRUD and ancillary functionality (like Login) with the business use cases, separate them into system use cases that separately exist at a level of detail lower than the business use cases.

State the system process in technical terms.

Its natural for developers to think in terms of implementation. Yet, this tendency needs to be resisted and continually guarded against for the business use cases. Moreover, developers should not force users to adopt implementation language. Its the developers who need to adopt the user’s language, not the other way around.

State the business process in terms of the user.

Producing Use CasesThe following steps suggest a structured outline to produce use cases. They are meant to be followed in a group session and attended by the members of the development team - and customer representatives, if possible. The design session atmosphere is open and relaxed and discussion, even vigorous, is encouraged. Ideally, the session facilitator is experienced in summarizing and clarifying the ideas presented by the group into coherent statements.

Materials needed: Markers, whiteboard (for brainstorming), flipcharts

Note: The steps assume the requirements have already been collected.

1. Produce an initial Actor-Goal list from the requirements.

The Actor-Goal list describes the behavior of the application at the highest level. Still, each primary actor has been identified and associated with its goals. The goals will eventually result in use cases.

o Identify the stakeholders and their interests. o From the stakeholders, identify and list primary actors. If necessary, begin with brief

narrative to identity initial actors and goals. o For each actor, identify goals, refactoring as necessary.

2. Verify Actor-Goal list and produce project narrative.

o In group discussion, slowly step through a narrative, capturing the essential steps in written form on a whiteboard.

o Referring to the narrative, insure that the Actor-Goal list captures the narrative’s. All of the actors and their goals should be evident in the narrative. If not, refactor the Actor-Goal list as necessary.

o When finished, each team member should understand and be able to repeat the narrative

This step will produce two artifacts:

o A verified Actor-Goal list that captures the behavior of the system and protects the interests of the stakeholders.

o A detailed project narrative that identifies all the project stakeholders and their interests. The narrative serves as great project documentation and helps to insure the use cases will protect the interests of the stakeholders. It also insures that all developers share a common understanding of the project since all developers participated in the narrative.

Note: If the narrative has already been produced prior to step 2, revisit it with the entire group. Undoubtedly, it will change and improve as questions and critiques arise.

3. Iteratively, produce the initial Use case briefs.

Focus on the primary actors and their main success scenarios in the first iteration. In later iterations, add the detail necessary for the desired use case format.

o Select the Actor-Goal from the verified Actor-Goal list that significantly influences the core architecture.

o Express the goal in terms of the business process; address the user's need, not the implementation of it.

o Avoid CRUD terminology. The use case must be expressed in the business vocabulary - it should make sense to the business user. For example, instead of "Create Student", perhaps, "Register Student to a Class" is more appropriate. CRUD Use case are more appropriate as "system" Use Cases...not "user" use cases.

o Avoid determining Use cases by functionality. 4. Produce Domain chart

o Partition Use cases into related, autonomous domains. o Consider that each domain can be designed and even implemented independently.

ConclusionUse cases are the first step towards designing and ultimately delivering quality software that works the way the user desires. Since use cases capture the business requirements from the user perspective, no other design activity has a larger return on investment. Similar to the specifications for a house, use cases provide the specifications for software applications. From these specifications, design artifacts are produced that are used in the construction of the system. Ultimately, application design, construction and user acceptance of the software rests on solid use cases. Don’t neglect this essential step in the lifecycle of the software application.

Project Estimation with Use Case Pointshttp://www.codeproject.com/gen/design/usecasep.asp

IntroductionObject-oriented applications frequently rely on Use Cases to describe the business processes of a software application. Since use cases consist of the strategic goals and scenarios that provide value to a business domain, they can also provide insight into an application’s complexity. Deriving a reliable estimate of the size and effort an application needs, is possible by examining the actors and scenarios of a use case. Use Case Points is a project estimation method that employs a project’s use cases to produce an accurate estimate of a project’s size and effort.

Use Case PointsUse case modeling is an accepted and widespread technique to capture the business processes and requirements of a software application. Since they provide the functional scope of the application, analyzing their contents provides valuable insight into the effort and size needed to design and implement the application. In general, applications with large, complicated use cases take more effort to design and implement than small applications with less complicated use cases. Moreover, the time to complete the application is affected by:

The number of steps to complete the use case. The number and complexity of the actors. The technical requirements of the use case such as concurrency, security and performance. Various environmental factors such as the development teams’ experience and knowledge.

Use Case Points (UCP) is an estimation method that provides the ability to estimate an application’s size and effort from its use cases. Based on work by Gustav Karner in 1993, UCP analyzes the use case actors, scenarios and various technical and environmental factors and abstracts them into an equation.

The equation is composed of four variables:

1. Technical Complexity Factor (TCF). 2. Environment Complexity Factor (ECF). 3. Unadjusted Use Case Points (UUCP). 4. Productivity Factor (PF).

Each variable is defined and computed separately, using perceived values and various constants. The complete equation is:

UCP = TCP * ECF * UUCP * PFThe necessary steps to generate the estimate based on the UCP method are:

1. Determine and compute the Technical Factors. 2. Determine and compute the Environmental Factors. 3. Compute the Unadjusted Use Case Points. 4. Determine the Productivity Factor. 5. Compute the product of the variables.

Technical Complexity Factors Thirteen standard technical factors exist to estimate the impact on productivity that various technical issues have on an application. Each factor is weighted according to its relative impact. A weight of 0 indicates the factor is irrelevant and the value 5 means that the factor has the most impact.

Technical Factor Description Weight

T1 Distributed system 2

T2 Performance 1

T3 End User Efficiency 1

T4 Complex internal Processing

1

T5 Reusability 1

T6 Easy to install 0.5

T7 Easy to use 0.5

T8 Portable 2

T9 Easy to change 1

T10 Concurrent 1

T11 Special security features 1

T12 Provides direct access for third parties

1

T13 Special user training facilities are required

1

Figure 1: Technical Factors.

For each project, the technical factors are evaluated by the development team and assigned a value from 0 to 5 according to their perceived complexity – multithreaded apps. require more skill and time than single threaded applications, for example, as do reusable apps. A perceived complexity of 0 means the technical factor is irrelevant for this project; 3 is average; 5 means it has strong influence.

Each factor’s weight is multiplied by its perceived complexity to produce its calculated factor. The calculated factors are summed to produce the Total Factor.

So, using sample perceived complexity values, the Technical Total Factor might be computed as follows:

Technical Factor

Description Weight Perceived Complexity

Calculated Factor (weight*perceived complexity)>

T1 Distributed System 2 5 10

T2 Performance 1 4 4

T3 End User Efficiency 1 2 2

T4 Complex internal Processing 1 4 4

T5 Reusability 1 2 2

T6 Easy to install 0.5 5 2

T7 Easy to use 0.5 3 2

T8 Portable 2 3 6

T9 Easy to change 1 3 3

T10 Concurrent 1 2 2

T11 Special security features 1 2 2

T12 Provides direct access for third parties

1 5 5

T13 Special user training facilities are required

1 3 3

Total Factor 47

Figure 2: Calculating the Technical Total Factor.

In Figure 2, the Total Factor is 47 derived by summing all the calculated factors. To produce the final TCF, two constants are computed with the Total Factor. The complete formula to compute the TCF is as follows:

TCF = 0.6 + (.01*Total Factor). For Figure 1, the TCF = 1.07

Environmental Complexity FactorsEnvironmental Complexity estimates the impact on productivity that various environmental factors have on an application. Each environmental factor is evaluated and weighted according to its perceived impact and assigned a value between 0 and 5. A rating of 0 means the environmental factor is irrelevant for this project; 3 is average; 5 means it has strong influence.

Environmental Factor

Description Weight

E1 Familiarity with UML 1.5

E2 Application Experience 0.5

E3 Object Oriented Experience 1

E4 Lead analyst capability 0.5

E5 Motivation 1

E6 Stable Requirements 2

E7 Part-time workers -1

E8 Difficult Programming language 2

Figure 3: Example Environmental Factors.

Each factor’s weight is multiplied by its perceived complexity to produce its calculated factor. The calculated factors are summed to produce the Total Factor.

Using sample values for perceived impact, the Environmental Total Factor might be computed as:

Environmental Factor

Description Weight Perceived Impact

Calculated Factor

(weight*perceived complexity)

E1 Familiarity with UML 1.5 4 6

E2 Application Experience 0.5 2 1

E3 Object Oriented Experience 1 5 5

E4 Lead analyst capability 0.5 2 1

E5 Motivation 1 1 1

E6 Stable Requirements 2 5 10

E7 Part-time workers -1 0 0

E8 Difficult Programming language 2 1 2

Total Factor 26

Figure 4: Calculating the Environmental Total Factor.

In Figure 4, the Total Factor is 26 derived by summing all the calculated factors. To produce the final ECF, two constants are computed with the Total Factor. The complete formula to compute the ECF is as follows:

ECF = 1.4 + (-0.03*Total Factor). For Figure 4, the ECF = 0.62

Unadjusted Use Case Points (UUCP)Unadjusted Use Case Points are computed based on two computations:

1. The Unadjusted Use Case Weight (UUCW) based on the total number of activities (or steps) contained in all the use case Scenarios.

2. The Unadjusted Actor Weight (UAW) based on the combined complexity of all the use cases Actors.

UUCW

Individual use cases are categorized as Simple, Average or Complex, and weighted depending on the number of steps they contain - including alternative flows.

Use Case Type Description Weight

Simple A simple user interface and touches only a single database entity; its success scenario has 3 steps or less; its implementation involves less than 5 classes.

5

Average More interface design and touches 2 or more database entities; between 4 to 7 steps; its implementation involves between 5 to 10 classes.

10

Complex Involves a complex user interface or processing and touches 3 or more database entities; over seven steps; its implementation involves more than 10 classes.

15

Figure 5: Use Case Categories.

The UUCW is computed by counting the number of use cases in each category, multiplying each category of use case with its weight and adding the products.

Use Case Type Description Weight Number of Use Cases

Result

Simple A simple user interface and touches only a single database entity; its success scenario has 3 steps or less; its implementation involves less than 5 classes.

5 8 40

Average More interface design and touches 2 or more database entities; between 4 to 7 steps; its implementation involves between 5 to 10 classes.

10 12 120

Complex Involves a complex user interface or processing and touches 3 or more database entities; over seven steps; its implementation involves more than 10 classes.

15 4 60

Total UUCW 220

Figure 6: Computing UUCW.

UAW

In a similar manner, the Actors are classified as Simple, Average or Complex based on their interactions.

Actor Type Description Weight

Simple The Actor represents another system with a defined API.

1

Average The Actor represents another system interacting through a

2

protocol, like TCP/IP.

Complex The Actor is a person interacting via an interface.

3

Figure 7: Actor Classifications.

The UAW is calculated by counting the number of actors in each category, multiplying each total by its specified weighting factor, and then adding the products.

Actor Type Description Weight Number of Actors Result

Simple The Actor represents another system with a defined API

1 8 8

Average The Actor represents another system interacting through a protocol, like TCP/IP

2 12 24

Complex The Actor is a person interacting via an interface.

3 4 12

Total UAW 44

Figure 8: Computing UAW.

Finally, the UUCP is computed by adding the UUCW and the UAW. For the sample data used in the figures, the UUCP = 220 + 44 = 264.

Productivity FactorThe Productivity Factor (PF) is a ratio of the number of man hours per use case point based on past projects. If no historical data has been collected, a figure between 15 and 30 is suggested by industry experts. A typical value is 20.

Final CalculationThe Use Case Points is determined by multiplying all the variables:

UCP = TCP * ECF * UUCP * PFFor the sample values used in this article:

UCP = 1.07 * 0.62 * 264 * 20 = 3502.752 or 3503 hours.

Dividing the UCP by 40 hours (for one man work week) = 88 man-weeks. Therefore, for the sample values in this article, it would take one developer 88 weeks (or about 22 months) to complete the application.

CaveatsThe Use Case Points estimate tends to be high when compared to human experts. This might be a good thing since many software projects are late, but, the estimate may still be too high. In order to produce accurate results, the variables in the equation need to be adjusted and tweaked – especially in the beginning.

The number of steps in a scenario affects the estimate. A large number of steps in a use case scenario will bias the result towards complexity and increase the Use Case Points. A small

number of steps will bias it towards simplicity. Sometimes, groups of steps can be reduced to a fewer number without sacrificing the business process. Strive for a uniform level of detail but don’t force a use case to conform to the estimation method.

Including and extending use cases increases the complexity. Count these as a single use case. The number of actors in a use case also affects the estimate. If possible, generalize the actors

into a single superactor. This reduces the complexity without affecting the use case. On the other hand, don’t force a generalization where none exists.

The values for the Technical and Environmental Factors need to be adjusted over time as actual data is obtained. The more projects that employ Use Case Points for their estimations will yield more accurate values for the perceived values.

Compare the Use Case Point estimate with a human expert’s estimate. Where there is disagreement, err on the side of the human expert and adjust the Use Case Point factors accordingly.

The Productivity Factor can only be obtained over time. Track the time spent designing and implementing the use cases and adjust the Productivity Factor accordingly.

ConclusionUse Case Points have the potential to produce reliable results because its estimates are produced from the actual business processes – the use cases - of a software application. Additionally, in many traditional estimation methods, influential technical and environmental factors are often not adequately given enough consideration. Use Case Points includes and abstracts these subjective factors into an equation. When tweaked, over time, Use Case Points can provide estimates that are very reliable.

How to Prepare Quotation Using Use Case Pointshttp://www.codeproject.com/gen/design/usecasepoints.asp

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 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:

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 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:

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

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 PointUse Case Points method is a software sizing and estimation based on Use Case document.

UAWUnadjusted 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.)

UUCWUnadjusted 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.)

UUCPUnadjusted Use Case Points

Sum of UAW and UUCW

APIApplication Programming Interface

Application programs used for accessing services provided by some lower-level module (such as operating system).

GUIGraphical 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 FactorTotal of all technical factors. See for more details in Steps in estimation. See table 4.0 for more details.

TCFTechnical Complexity Factor

Factor which defines the complexity of the project. For more details, see steps for UCP estimation. TCF is calculated from Tfactor.

EFEnvironment Factor

This is multiplying factor.

AUCPAdjusted Use Case Points

This is the value obtained after multiplying with Efactor and Tfactor.

LOC Lines of CodeLines of code is a counting metrics to measure the volume of a software product.

OOPObject Oriented Programming

A programming technology in which program components are put together from reusable building blocks known as objects. [Glossary]

UMLUnified 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]

UUCFPUnadjusted Use Case Flow Points

Details are provided in this article.

FP Function PointsA sizing methodology for software projects based on functions of the software.

Assumptions:1. Readers have 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.

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

History and Definition of Use Case PointsWorking 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:

o Actors who are interacting with the system through some protocol (HTTP, FTP, or probably some user defined protocol).

o 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 1Does the client need the system to fast? Is time response one of the important criteria?

t3End user efficiency

1 How's the end user's efficiency?

t4Complex internal processing

1Is the business process very complex? Like complicated accounts closing, inventory tracking, heavy tax calculation etc.

t5 Reusable code 1Do 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 2Is the customer also looking for cross platform implementation?

t9 Easy to change 1Is the customer looking for high customization in the future? That also increases the architecture design complexity and hence this factor.

t10 Concurrent 1Is the customer looking at large number of users working with locking support? This will increase the architecture complexity and hence this value.

t11Security objectives

1Is the customer looking at having heavy security like SSL? Or do we have to write custom code logic for encryption?

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

t13User training facilities

1Will 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 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:

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):

1. Data entry operator receives customer information. 2. Data entry operator enters following information:

o Customer code o Customer name o Customer address o Customer phone

3. Customer code is checked if it exists in Customer table.

o If the customer code is existing then "Duplicate Customer Code" error is raised.

o If the customer code is more than 8 length, then "Customer code length limit crossed" error is raised.

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

5. Credit card information is send to the external payment gateway. Appropriate APIs of the external payment gateway will be used for validity.

6. External payment gateway returns "OK" if credit card is validated or else will return "NOT VALID" flag.

7. Data entry operator then adds the customer in database.

Alternate scenario (Extensions):

Update Existing Customer 1. Data entry operator enters customer code to retrieve the

customer who has to be updated. 2. 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.

3. Data Entry operator updates the customer information.

Alternate scenario (Extensions):

Delete Existing Customer 1. Data entry operator enters customer code to retrieve the

customer who has to be deleted. 2. Data entry operator deletes the customer. Data entry operator is

alerted "Are you sure you want to delete the Customer?” o If the data entry operator clicks "Yes", then the customer

is deleted from the database.

o 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 ValueWeighted 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 WeightWeighted 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: 90Date: 1/1/2004Customer ID: - 20090DATAENTRY

Quantity Description Discount Taxable Total

1 Data Entry Module 0% 0% $840

Quotation valid for 100 daysGoods delivery date within 25 days of half paymentQuotation prepared by: XYZ estimation departmentApproved 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 FactorsThe 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. o If the software is using any third-party component, example Crystal Reports etc., estimate

them in a ad hoc way. o Example, if in the project, company is also providing web hosting, domain name,

hardware etc., put them separately. o 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 shiv_koirala@yahoo.com. I will see to my best that I preserve the copyright.

I work presently in Ag-technologies. Thanks to 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 WordsSoftware 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."