Software Effort Estimation based on Use Case Points Chandrika Seenappa 30 th March 2015 Professor:...

30
Software Effort Estimation based on Use Case Points Chandrika Seenappa 30 th March 2015 Professor: Hossein Saiedian

Transcript of Software Effort Estimation based on Use Case Points Chandrika Seenappa 30 th March 2015 Professor:...

Software Effort Estimation based on Use Case Points

Chandrika Seenappa

30th March 2015

Professor: Hossein Saiedian

2

Agenda

• Introduction• Background• Use Case Point Estimation Method• Case Study• Conclusions

3

Introduction

• Estimation of cost and schedule in software projects is based on the prediction of size of the future system

• Reliable early estimates difficult to obtain– Lack of detailed information about future system at early stage

• Bidding for a contract or determining whether a project is feasible in the terms of a cost-benefit analysis

• Traditional cost model – software size as input parameter, and then apply a set of adjustment

factors to compute an estimate of total effort

• Object-oriented software production– Object points measure the size of object-oriented software and are

derived from class, structure, messages and use cases

4

Background-COCOMO

• Software cost estimation models developed in the 60’s and 70’s

• Used the Line of Code (LOC) or Delivered Source Instruction (DSI) metrics

• COCOMO model used the DSI metric• Problem with DSI metric

– Lack of precise definition of LOC or DSI– No reasonable methodology to estimate upfront the number of source

code lines or instructions

5

Background-COCOMO (Cont.)

• Metrics defined for procedural, possibly line-oriented languages such as FORTRAN and COBOL

• Notion of LOC or DSI difficult to define precisely for block structured languages such as Pascal, C etc.

6

Background-Function Points

• Albrecht came up with the Function Point (FP) metrics in 1979

• FP uses five parameters– number of inputs– number of outputs– number of inquiries– number of internal logical files– number of external logical files

• FP is based on the number of interactions and the size of data to be used in the end product

• Eliminated the need for lines of code or delivered source instructions

7

Background-Function Points (Cont.)

• Widely used because of its independence on development platform and environment

• Not applicable to software products developed using the object-oriented methodology

• Notion of internal and external logical files harder to identify in the object-oriented paradigm.

• Not applicable for software development using shorter development cycles– Difficult to apply and count function points to such software

8

Background-Use Case Point

• Gustav Karner came up with the notion of Use Case Point (UCP) in 1993

• Estimates software development effort during early phase of software

• Major challenge- no standard format for describing use cases• UCP method adjust the use case points based on a number of

technical and environmental factors– Technical factors are related to non-functional requirements on the

system– Environmental factors characterize the development team and its

environment

9

Use Case Point Estimation Method

• UCP is measured by counting the number of actors and transactions included in use case model that defines the functional scope of the project to be developed– A transaction is an event that occurs between an actor and the target

system– The event being performed entirely or not at all

• Use case model mainly consists of two documents, system or subsystem documents and use case documents– System name, risk factors, system-level use case diagram, architecture

diagram, subsystem descriptions, use case name, brief description, context diagram, preconditions, flow of events, post conditions, subordinate use case diagrams etc.

10

Use Case Point Estimation Method (Cont.)• Main elements to calculate UCP

– System level use case diagram• One or more use case diagrams showing all the use cases and

actors in the system– Flow of events

• Section for the normal path and each alternative path in each use case

11

Use Case Diagram and Flow of Events

Use Case Diagram

Flow of Events

12

Counting Use Case Points

13

Counting Use Case Points (Cont.)

14

Technical Factors

15

Environmental Factors

16

Example – The Online Shopping System

17

UUCW and UAW Calculation

• UAW = (Total No. of Simple Actors x 1) + • (Total No. Average Actors x 2) + (Total No. Complex Actors x

3)– UAW = (1 x 1) + (0 x 2) + (4 x 3) = 13

• UUCW = (Total No. of Simple Use Cases x 5) + (Total No. Average Use Cases x 10) + (Total No. Complex Use Cases x 15)– UUCW = (2 x 5) + (3 x 10) + (4 x 15) = 100

18

TCF Calculation• TCF = 0.6 + (TF*0.01)

TCF = 0.6 + (42*0.01) = 1.02

19

ECF Calculation

• ECF = 1.4 + (-0.03 * EF)

ECF = 1.4 + (-0.03 * 10.5) = 1.085

20

Use Case Points

• UCP = (UUCW + UAW) x TCF x ECF– UCP = (100 + 13) x 1.02 x 1.085 = 125.06

• The total estimated size to develop the software is 125.06 Use Case Points

• For the Online Shopping System example, 28 man hours per use case point will be used

• Estimated Effort = UCP x Hours/UCP– Estimated Effort = 125.06 x 28= 3501 Hours

21

Characteristics of Projects Evaluating the Use Case Point Method

22

Case Study

• Web based system for handling information about studies conducted by Software Engineering Department at Simula Research Laboratory

• Software Engineering Department was both client and researcher

• 35 Norwegian development companies volunteered• Requirement specification tender included 3 actors and 9 use

cases• Bid price range from 21,000 NOK to 559,500 NOK• Effort estimation from 78-654 hours with a mean of 275 hours

23

Example of Use Case

24

Company Selection

• Four companies A,B,C,D developed the project• Companies chosen based on business and research criteria

– Business criteria: price, experience with similar solutions, experience with programming environment(Java), size of company, understanding of requirements

– Development teams similar in size with 1 project manager and 2 developers

– Java was the development language , but with different tools– Communication between client and development team with issue

tracking system Bugzero

• System developed in parallel with time frame between 9 to 13 weeks

25

Characteristics of Development Projects

26

Use Case Transaction and effort for Companies

27

Effort Estimation

28

Results

• Minimum development time for 9 use cases is 413 hours• Actual effort of four companies

– A-587 hours– B-943 hours– C-431 hours– D-829 hours

• Use case point estimation closer to actual effort than expert estimate based on bids

29

Conclusions

• Brief overview of effort estimation using use case points• Example of estimating effort using use case points• Case study based on use case points

30

References

• Anda,B., Benestad H.C., & Hove, S.E. (2005). A multiple-case study of software effort estimation based on use case points. 2005 International Symposium on Empirical Software engineering. IEEE.

• Kusumoto,S., Matukawa,F., Inoue,K., Hanabusa,S., & Maegawa,Y. (2004).Estimating effort by use case points: methods, tools and case study. Proceeding of the 10th International Symposium on Software Metrics, pp. 292-299. IEEE.

• http://en.wikipedia.org/wiki/Use_Case_Points