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

Slides:



Advertisements
Similar presentations
Estimating with Use Cases Extracts from the Lamri Use Case Survival Guide™ Mark Aked Managing Consultant For more information visit or .
Advertisements

Early Effort Estimation of Business Data-processing Enhancements CS 689 November 30, 2000 By Kurt Detamore.
Metrics for Process and Projects
Chapter 26 Estimation for Software Projects
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
CSC 395 – Software Engineering
University of Toronto Department of Computer Science © 2001, Steve Easterbrook CSC444 Lec22 1 Lecture 22: Software Measurement Basics of software measurement.
Use Case Diagrams – Functional Models Chapter 5. Objectives Understand the rules and style guidelines for activity diagrams. Understand the rules and.
Cmpe 589 Spring Software Quality Metrics Product  product attributes –Size, complexity, design features, performance, quality level Process  Used.
COCOMO Models Ognian Kabranov SEG3300 A&B W2004 R.L. Probert.
Software Estimation and Function Point Analysis Presented by Craig Myers MBA 731 November 12, 2007.
Chapter 6 : Software Metrics
Function Point Analysis What is Function Point Analysis (FPA)? It is designed to estimate and measure the time, and thereby the cost, of developing new.
1 UseCase-based effort estimation of software projects TDT 4290 Customer-driven project IDI, NTNU, 14. Sept Bente Anda, Simula Research Lab., Oslo,
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
1 Lecture 17: Chapter 26 Estimation for Software Projects Slide Set to accompany Software Engineering: A Practitioner’s Approach, 7/e by Roger S. Pressman.
Software cost estimation Predicting the resources required for a software development process 1.
Version control – Project repository, version management capability, make facility, issue/bug tracking Change control Configuration audit – compliments.
PowerPoint Presentation for Dennis, Wixom, & Tegarden Systems Analysis and Design with UML, 3rd Edition Copyright © 2009 John Wiley & Sons, Inc. All rights.
CEE-SECR 2009 October Moscow, Russia Proposal Feasibility Study using Stochastic Risk Model Anton Khritankov.
1 Chapter 23 Estimation for Software Projects. 2 Software Project Planning The overall goal of project planning is to establish a pragmatic strategy for.
Software Engineering SM ? 1. Outline of this presentation What is SM The Need for SM Type of SM Size Oriented Metric Function Oriented Metric 218/10/2015.
Lecture 4 Software Metrics
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 3 1 Software Size Estimation I Material adapted from: Disciplined.
Cost Estimation What is estimated? –resources (humans, components, tools) –cost (person-months) –schedule (months) Why? –Personnel allocation –Contract.
Quality Software Project Management Software Size and Reuse Estimating.
REAL TIME GPS TRACKING SYSTEM MSE PROJECT PHASE I PRESENTATION Bakor Kamal CIS 895.
Disciplined Software Engineering Lecture #3 Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Sponsored by the U.S. Department.
SEG3300 A&B W2004R.L. Probert1 COCOMO Models Ognian Kabranov.
Introduction to Software Project Estimation I (Condensed) Barry Schrag Software Engineering Consultant MCSD, MCAD, MCDBA Bellevue.
Computing and SE II Chapter 15: Software Process Management Er-Yu Ding Software Institute, NJU.
©Ian Sommerville 2000Software Engineering, 7th edition. Chapter 26Slide 1 Software cost estimation l Predicting the resources required for a software development.
SOFTWARE PROCESS AND PROJECT METRICS. Topic Covered  Metrics in the process and project domains  Process, project and measurement  Process Metrics.
Project Management Cross lifecycle Activity
Systems Development Life Cycle
Estimation for Software Projects 1. Software Project Planning 2 The overall goal of project planning is to establish a pragmatic strategy for controlling,
Function Points Synthetic measure of program size used to estimate size early in the project Easier (than lines of code) to calculate from requirements.
CSC 480 Software Engineering Lecture 6 September 11, 2002.
Estimating “Size” of Software There are many ways to estimate the volume or size of software. ( understanding requirements is key to this activity ) –We.
Effort Estimation In WBS,one can estimate effort (micro-level) but needed to know: –Size of the deliverable –Productivity of resource in producing that.
Project, People, Processes and Products Project management skills – schedule, monitoring, risk management, … People management skills – delegation, mentoring,
Software Engineering (CSI 321) Project Planning & Estimation 1.
Advanced Software Engineering Lecture 4: Process & Project Metrics.
Unit – I Presentation. Unit – 1 (Introduction to Software Project management) Definition:-  Software project management is the art and science of planning.
FUNCTION POINT ANALYSIS & ESTIMATION
Slide 1 Use Case Points. Slide 2 Use Case Points* Use Case Points (UCP) is a current technique for measuring functionality of a software system. It can.
SYSTEM ANALYSIS AND DESIGN LAB NARZU TARANNUM(NAT)
Systems Analysis Lecture 5 Requirements Investigation and Analysis 1 BTEC HNC Systems Support Castle College 2007/8.
Estimation Questions How do you estimate? What are you going to estimate? Where do you start?
THE FAMU-CIS ALUMNI SYSTEM
Chapter 33 Estimation for Software Projects
Chapter 1 The Systems Development Environment
Sizing With Function Points
Software Engineering (CSI 321)
Chapter 1 The Systems Development Environment
Application of SysML to LLRF system design M.Grecki
Software Engineering: A Practitioner’s Approach, 6/e Chapter 23 Estimation for Software Projects copyright © 1996, 2001, 2005 R.S. Pressman & Associates,
Function Point Analysis
Software Development & Project Management
Chapter 5: Software effort estimation- part 2
Software Metrics “How do we measure the software?”
More on Estimation In general, effort estimation is based on several parameters and the model ( E= a + b*S**c ): Personnel Environment Quality Size or.
COCOMO Models.
Chapter 33 Estimation for Software Projects
Software Engineering: A Practitioner’s Approach, 6/e Chapter 23 Estimation for Software Projects copyright © 1996, 2001, 2005 R.S. Pressman & Associates,
Software Sizing and Costing
Software Effort Estimation
Chapter 1 The Systems Development Environment
Chapter 26 Estimation for Software Projects.
COCOMO MODEL.
Presentation transcript:

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

Agenda Introduction Background Use Case Point Estimation Method Case Study Conclusions 2

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 3

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 4

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

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 6

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 7

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 8

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

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 10

Use Case Diagram and Flow of Events 11 Use Case Diagram Flow of Events

Counting Use Case Points 12

Counting Use Case Points (Cont.) 13

Technical Factors 14

Environmental Factors 15

Example – The Online Shopping System 16

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

TCF Calculation TCF = (TF*0.01) TCF = (42*0.01) =

ECF Calculation ECF = (-0.03 * EF) ECF = (-0.03 * 10.5) =

Use Case Points UCP = (UUCW + UAW) x TCF x ECF – UCP = ( ) x 1.02 x = The total estimated size to develop the software is 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 = x 28= 3501 Hours 20

Characteristics of Projects Evaluating the Use Case Point Method 21

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 hours with a mean of 275 hours 22

Example of Use Case 23

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 24

Characteristics of Development Projects 25

Use Case Transaction and effort for Companies 26

Effort Estimation 27

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 28

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 29

References Anda,B., Benestad H.C., & Hove, S.E. (2005). A multiple-case study of software effort estimation based on use case points 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 IEEE. 30