Estimating Work with Use Cases. Estimating Work with Use Cases. We need to forecast. Use Case Point Estimator. We need to quantify

Transcription

1 Desarrollo de Software con UML Estimating Work with Use Cases Estimating Work with Use Cases We need to forecast How long it will take to develop the and How many people will be needed to do it How long it will take a software engineer to accomplish a given task is primarily a function of the complexity of the problem and the engineer s s ability Estimating Work with Use Cases We need to quantify The complexity of the Functionality Technical complexity The experience level of the people on the project The time needed to produce a unit of complexity The goal is to arrive at a single number that completely characterizes the and correlates with observed engineer productivity Estimating Work with Use Cases Use Case Point Estimator An estimating method by Gustav Karner of Rational Software Corporation It characterizes the complexity of a by Use Case Points It is preliminary and should be used to get an idea of the number of man-hours for your project It was derived empirically, and the limited amount of experimentation to date shows that it applies well in business applications, e.g., information s Use Case Point Estimator This method involves the following steps Calculating the Unadjusted Use Case Points ing Actors (UAW) & ing Use Cases (UUCW) UUCP = ƒ (UAW;; UUCW) ) = UAW + UUCW Calculating Use Case Points ing Technical s (TCF) ing Environmental s (EF) UCP = ƒ (UUCP; TCF; EF) ) = UUCP * TCF * EF Estimating the Number of Man-hours Man-hours = ƒ (UCP) Customer Customer Rep Use Case Diagram An Example Register Complaint Get Catalog Cancel Order Place Order Return Product Run Sales Report Login Get Status on Order Update Account Update Product Quantities Get Product Information Receive Back- ordered items Fill and Ship Order Customer Support Manager Accounting System Inventory System Clerk Shipping Company

2 ing Actors Start by considering the actors for the determining whether each is simple, average, or complex based on its interface Actor Description Another with a defined Application Programming Interface Another interacting through a protocol (e.g., TCP/IP) or A person interacting through a text-based interface (e.g., ASCII Terminal) A person interacting through a Graphical User Interface (stand-alone alone or web application) ing Actors (Cont.) Count how many of each actor type you have Then multiply each type by a weighting factor Actor ing Actors essing Determining whether each actor is simple, average, or complex based on its interface Actor Customer Inventory System Accounting System Customer Service Manager Customer Rep Clerk Shipping Company ing Actors essing Count how many of each actor type you have 2, 2 and 3 Then multiply each type by a weighting factor 2 * 1 = 2 2 * 2 = 4 3 * 3 = 9 Total Actor = 15 UAW ing Use Cases For each Use Case determine whether it is simple, average or complex Alternatives: Transaction-based or Analysis Class-based Count how many of each type of use case type you have Then, multiply each type by a weighting factor ing Use Cases Transaction-based Determining the number of transactions in a use case, including alternative paths A transaction is an atomic set of activities, which is either performed entirely or not at all Use Case Description It has 3 or fewer transactions 5 4 to 7 transactions 10 More than 7 transactions 15

3 Name: Place Order Use Case Documentation Brief Description This Use Case describes the process by which orders are entered into the orderprocessing. Flow of Events Basic Path 1. The use case begins when the customer selects Place Order in the main screen. 2. The displays the Place Order screen. 3. The customer enters his or her name and address. 4. The customer enters product codes for products to be ordered. 5. For each product code entered a) Include Get Product Information. b) The adds the price of the item to the total. end loop 6. The customer enters credit card payment information. 7. The customer selects Submit. 8. The verifies the information. 9. The saves the order as pending Include Save Order. 10. Include Update Account. 11. The marks the order as confirmed Include Update Order. 12. The returns an order ID to the customer, and the use case ends. Name: Place Order Brief Description Flow of Events Alternative Paths Cancel Placing an Order. Payment not there or bad. Shipping address incomplete. Product code does not match actual products. Product no longer carried. Customer pays by check. Alternative Path: Cancel Placing an Order Precondition: The user did not select Submit. 1. The alternative begins when the user selects Cancel. 2. The discards any entered information. 3. The returns to the previous display. 4. The use case ends. Use Case Documentation Activity Diagram (Place Order) Use Case Context (Place Order) [ place order selected ] Submit Order From Displayed Enter Name and Address Cancelable Actions [ Product code entered ] [ info complete ] Order Marked Pending Charge Account [ Payment good ] Save Order >> >> Update Account Give Product Informatio n [ no more product codes ] [ Product code entered ] Order Market Confirmed Customer Place Order >> New Total Calculated Order ID Displayed >> Get Product Information Enter Credit Card Informatio n submit Update Order cancel ing Use Cases Analysis Class-based Watching which analysis classes are used to realize a particular use case Use Case Description It can be realized with Fewer than 5 analysis classes 5 5 to 10 analysis classes 10 More than 10 analysis classes 15 ing Use Cases Determining whether each use case is simple, average, or complex Place Order Return Product Cancel Order Get Status on Order Send Catalog Run Sales Report Register Complaint Fill and Ship Order Use Case Back-Ordered Items Received

4 ing Use Cases Count how many of each use case type you have 5, 4 and 0 Then multiply each type by a weighting factor 5 * 5 = 25 4 * 10 = 40 0 * 15 = 0 Total Use Case = 65 UUCW Calculating the Unadjusted Use Case Points UUCP = UAW + UUCW UUCP = = 80 UUCP provides an idea of the complexity of the use cases and interfaces, but What about the technical and environmental factors? Technical s Technical s (Cont.) Technical T1 T2 T3 T4 T5 T6 T7 Description Distributed System 2 Response or throughput performance objectives 1 End-user efficiency (on line) 1 internal processing 1 Code must be reusable 1 Easy to install 0,5 Easy to use 0,5 Technical T8 T9 T10 T11 T12 T13 Description Portable 2 Easy to change 1 Concurrent 1 Includes special security features 1 Provides direct access for third parties 1 Special user training facilities required 1 ing Technical s Go through Table and rate each factor from 0 to 5 A rating of 0 means that the factor is irrelevant A rating of 5 means that the factor is essential A rating of 3 means that the factor is average Then multiply each factor s s rating (TLevel( TLevel) ) by its weight (T) ing Technical s Technical TLevel TLevel * Reason T Just Client-Server T Speed is likely limited by input human T Needs to be efficient T Easy processing T Nice, but later T6 0,5 5 2,5 Needs to be easy for non-technical people T7 0,5 5 2,5 Needs to be easy for non-technical people T Not at this time T Sure T Not exactly, but it is multi-user user T security T Customers T So easy we don t t need training T = TLevel * 32

5 ing Technical s Environmental s Environmental E1 Description Familiar with Rational Unified Process 1,5 T = (TLevel * ) = 32 TCF = 0,6 + (0,01 * T) TCF = 0,6 + (0,01 * 32) = 0,92 E2 E3 E4 E5 E6 E7 E8 Application experience 0,5 Object-oriented experience 1 Lead analyst capability 0,5 Motivation 1 Stable requirements 2 Part-time time workers -1 Difficult programming language -1 ing Environmental s Go through Table and rate each factor from 0 to 5 For factors E1 through E4 A rating of 0 means no experience in the subject 5 means expert; 3 means average For E5 (Motivation) 0 means no motivation for the project; 5 means high motivation For E6 (Stable Requirements) 0 means extremely unstable requirements; 5 means unchanging requirements For E7 (Part-time time Workers) 0 means no part-time time technical staff; 5 means all part-time time technical staff For E8 (Programming Language) 0 means easy-to to-use programming language; 5 means very difficult programming language ing Environmental s Then multiply each factor s s rating (ELevel( ELevel) ) by its weight (E) ing Environm. s Environm. ELevel ELevel * Reason ing Environm. s E1 1,5 1 1,5 Most of team unfamiliar E2 0,5 3 1,5 Most of team are programmers E OO programmers E4 0,5 5 2,5 The leader is really good E Team is really eager E We don t t expect changes E = (ELevel * ) = 20,5 EF = 1,4 + (- 0,03 * E) EF = 1,4 + (- 0,03 * 20,5) = 0,785 E Not part-timers timers E We re looking at Java E = ELevel * 20,5

6 Calculating the Use Case Points UCP = UUCP * TCF * EF UCP = 80 * 0,92 * 0,785 = 57,77 UCP provides an idea of the complexity of the adjusted to the technical and environmental factors Estimating the Project Estimating Man-hours In general, Karner suggests using 20 man-hours per UCP Man-hours = 57,77 * 20 = 1155,52 ~ 29 weeks at 40 hours a week, for one person Taking a small team of 6 persons working full-time ~ 5 weeks of effort Add some weeks for working out any team issues Too many problems of communication or synchronization Estimating the Project Estimating Man-hours Schneider & Winters suggest a refinement based on Environmental s EF factors measure the experience level of your staff and the stability of your project. Any negatives in this area mean that you will have to spend time training people or fixing problems due to instability. Estimating the Project Estimating Man-hours Schneider & Winters suggest a refinement based on EF Start by Calculating TNEF: Count how many of E1 through E6 are below 3 (average level value) and how many in E7 and E8 are above 3. Then, you have to use: 20 man-hours per UCP when TNEF 2 28 man-hours per UCP when 3 TNEF 4 36 man-hours per UCP when TNEF 4 => In this case, try very hard to change your project ing Environm. s Environm. ELevel It is below 3 ELevel * Reason E1 1,5 1 1,5 Most of team unfamiliar E2 0,5 3 1,5 Most of team are programmers E OO programmers E4 0,5 5 2,5 The leader is really good E Team is really eager E We don t t expect changes E Not part-timers timers E We re looking at Java Book References Applying Use Cases: A Practical Guide Authors: G.Schneider & J. P. Winters Edition: Second - Editorial: Addison Wesley ISBN: Papers Resource Estimation for Objectory Projects G. Karner - Objectory Systems The Estimation of Effort Based on Use Cases J. Smith - Rational Software We have one EF below the average => 20 man-hours per UCP