1 COSC 4406 Software Engineering COSC 4406 Software Engineering Haibin Zhu, Ph.D. Dept. of Computer Science and mathematics, Nipissing University, 100 College Dr., North Bay, ON P1B 8L7, Canada,

2 Lecture 14 Project Estimation and Scheduling Ref. Chap 26 & 27 (7 th Edition)

3 Software Project Planning The overall goal of project planning is to establish a pragmatic strategy for controlling, tracking, and monitoring a complex technical project. Why? So the end result gets done on time, with quality!

4 Project Planning Task Set-I Establish project scope Establish project scope Determine feasibility Determine feasibility Analyze risks Analyze risks Risk analysis is considered in detail in Chapter 25. Risk analysis is considered in detail in Chapter 25. Define required resources Define required resources Determine require human resources Determine require human resources Define reusable software resources Define reusable software resources Identify environmental resources Identify environmental resources

5 Project Planning Task Set-II Estimate cost and effort Estimate cost and effort Decompose the problem Decompose the problem Develop two or more estimates using size, function points, process tasks or use-cases Develop two or more estimates using size, function points, process tasks or use-cases Reconcile the estimates Reconcile the estimates Develop a project schedule Develop a project schedule Establish a meaningful task set Establish a meaningful task set Define a task network Define a task network Use scheduling tools to develop a timeline chart Use scheduling tools to develop a timeline chart Define schedule tracking mechanisms Define schedule tracking mechanisms

6 Estimation Estimation of resources, cost, and schedule for a software engineering effort requires Estimation of resources, cost, and schedule for a software engineering effort requires experience experience access to good historical information (metrics access to good historical information (metrics the courage to commit to quantitative predictions when qualitative information is all that exists the courage to commit to quantitative predictions when qualitative information is all that exists Estimation carries inherent risk and this risk leads to uncertainty Estimation carries inherent risk and this risk leads to uncertainty

7 Write it Down! SoftwareProjectPlan Project Scope EstimatesRisksSchedule Control strategy

8 To Understand Scope... Understand the customers needs Understand the customers needs understand the business context understand the business context understand the project boundaries understand the project boundaries understand the customer’s motivation understand the customer’s motivation understand the likely paths for change understand the likely paths for change understand that... understand that... Even when you understand, nothing is guaranteed!

9 What is Scope? Software scope describes Software scope describes the functions and features that are to be delivered to end-users the functions and features that are to be delivered to end-users the data that are input and output the data that are input and output the “content” that is presented to users as a consequence of using the software the “content” that is presented to users as a consequence of using the software the performance, constraints, interfaces, and reliability that bound the system. the performance, constraints, interfaces, and reliability that bound the system. Scope is defined using one of two techniques: Scope is defined using one of two techniques: A narrative description of software scope is developed after communication with all stakeholders. A narrative description of software scope is developed after communication with all stakeholders. A set of use-cases is developed by end-users. A set of use-cases is developed by end-users.

10 Resources

11 Project Estimation Project scope must be understood Project scope must be understood Elaboration (decomposition) is necessary Elaboration (decomposition) is necessary Historical metrics are very helpful Historical metrics are very helpful At least two different techniques should be used At least two different techniques should be used Uncertainty is inherent in the process Uncertainty is inherent in the process

12 Estimation Techniques Past (similar) project experience Past (similar) project experience Conventional estimation techniques Conventional estimation techniques task breakdown and effort estimates task breakdown and effort estimates size (e.g., FP) estimates size (e.g., FP) estimates Empirical models Empirical models Automated tools Automated tools

13 Estimation Accuracy Predicated on … Predicated on … the degree to which the planner has properly estimated the size of the product to be built the ability to translate the size estimate into human effort, calendar time, and dollars (a function of the availability of reliable software metrics from past projects) the degree to which the project plan reflects the abilities of the software team the stability of product requirements and the environment that supports the software engineering effort.

14 Functional Decomposition functionaldecomposition StatementofScope Perform a Grammatical “parse”

15 Conventional Methods: LOC/FP Approach compute LOC/FP using estimates of information domain values compute LOC/FP using estimates of information domain values use historical data to build estimates for the project use historical data to build estimates for the project

16 Example: LOC Approach Average productivity for systems of this type = 620 LOC/pm. The total LOC: Burdened labor rate =$8000 per month, the cost per line of code is approximately $13. Based on the LOC estimate and the historical productivity data, the total estimated project cost is $461,000 (33200*13*1.068) and the estimated effort is 54 person-months.

17 Example: FP Approach The estimated number of FP is derived: FP estimated = count-total * [ * ∑(F i )] If count-total = 320, ∑(Fi) = 52, then FP estimated = 375 If organizational average productivity = 6.5 FP/pm. The burdened labor rate = $8000 per month, the cost per FP is approximately $1230. Based on the FP estimate and the historical productivity data, the total estimated project cost is $461,000 and the estimated effort is 58 person-months.

18 Process-Based Estimation Obtained from “process framework” applicationfunctions framework activities Effort required to accomplish each framework activity for each application function

19 Process-Based Estimation Example Based on an average burdened labor rate of $8,000 per month, the total estimated project cost is $368,000 and the estimated effort is 46 person-months.

20 Estimation with Use-Cases LOC estimate = N*LOC avg +[(S a /S h -1) +(P a /P h -1)]*LOC adjust LOC estimate = N*LOC avg +[(S a /S h -1) +(P a /P h -1)]*LOC adjust N: actual number of use-cases N: actual number of use-cases LOC avg :historical average LOC per use-case for this type of subsystem LOC avg :historical average LOC per use-case for this type of subsystem LOC adjust :an adjustment based on n percent of LOC avg where n is defined locally LOC adjust :an adjustment based on n percent of LOC avg where n is defined locally S a : actual scenarios per use-case S a : actual scenarios per use-case S h :Average scenarios per use-case for this type of subsystem S h :Average scenarios per use-case for this type of subsystem P a :Actual pages per use-case P a :Actual pages per use-case P h :Average pages per use-case for this type of subsystem P h :Average pages per use-case for this type of subsystem

21 Estimation with Use-Cases Using 620 LOC/pm as the average productivity for systems of this type and a burdened labor rate of $8000 per month, the cost per line of code is approximately $13. Based on the use-case estimate and the historical productivity data, the total estimated project cost is $552,000 and the estimated effort is 68 person-months. LOC estimate (3366) = N(6)*LOC avg (560)+[(S a (10)/S h (12)-1) +(P a (6)/P h (5)-1)]*LOC adjust (60)

22 The Software Equation A dynamic multivariable model E = [LOC x B /P] 3 x (1/t 4 ) where E = effort in person-months or person-yearsE = effort in person-months or person-years t = project duration in yearst = project duration in years B = “special skills factor”B = “special skills factor” P = “productivity parameter” P = 2000 for RT embeddedP = 2000 for RT embedded P = 10, 000 for tele comm/system software (sw)P = 10, 000 for tele comm/system software (sw) P = 28,000 for business swP = 28,000 for business sw

23 Computation t min = 8.14 (LOC/P) 0.43 (>6 months, in months) t min = 8.14 (LOC/P) 0.43 (>6 months, in months) E=180Bt 3 (>= 20pms) (t in years) E=180Bt 3 (>= 20pms) (t in years) For the CAD project For the CAD project B = (B small + B large ) /2 =( )/2 =0.28 B = (B small + B large ) /2 =( )/2 =0.28 t min = 8.14 (33200/12000) 0.43 =12.6 months = 1.5 years t min = 8.14 (33200/12000) 0.43 =12.6 months = 1.5 years E=180*0.28*(1.05) 3 = 58pms E=180*0.28*(1.05) 3 = 58pms

24 Estimation for OO Projects-I Develop estimates using effort decomposition, FP analysis, and any other method that is applicable for conventional applications. Develop estimates using effort decomposition, FP analysis, and any other method that is applicable for conventional applications. Using object-oriented analysis modeling (Chapter 8), develop use-cases and determine a count. Using object-oriented analysis modeling (Chapter 8), develop use-cases and determine a count. From the analysis model, determine the number of key classes (called analysis classes in Chapter 8). From the analysis model, determine the number of key classes (called analysis classes in Chapter 8). Categorize the type of interface for the application and develop a multiplier for support classes: Categorize the type of interface for the application and develop a multiplier for support classes: Interface typeMultiplier Interface typeMultiplier No GUI 2.0 No GUI 2.0 Text-based user interface 2.25 Text-based user interface 2.25 GUI 2.5 GUI 2.5 Complex GUI 3.0 Complex GUI 3.0

25 Estimation for OO Projects-II Multiply the number of key classes (step 3) by the multiplier to obtain an estimate for the number of support classes. Multiply the number of key classes (step 3) by the multiplier to obtain an estimate for the number of support classes. Multiply the total number of classes (key + support) by the average number of work-units per class. Lorenz and Kidd suggest 15 to 20 person-days per class. Multiply the total number of classes (key + support) by the average number of work-units per class. Lorenz and Kidd suggest 15 to 20 person-days per class. Cross check the class-based estimate by multiplying the average number of work-units per use-case Cross check the class-based estimate by multiplying the average number of work-units per use-case

26 The Make-Buy Decision

27 Computing Expected Cost (path probability) x (estimated path cost) (path probability) x (estimated path cost) i i For example, the expected cost to build is: expected cost build = 0.30 ($380K) ($450K) = $429 K similarly, expected cost reuse = $382K expected cost buy = $267K expected cost contr = $410K expected cost =

28 Project Scheduling Why Are Projects Late? Why Are Projects Late? an unrealistic deadline established by someone outside the software development group an unrealistic deadline established by someone outside the software development group changing customer requirements that are not reflected in schedule changes; changing customer requirements that are not reflected in schedule changes; an honest underestimate of the amount of effort and/or the number of resources that will be required to do the job; an honest underestimate of the amount of effort and/or the number of resources that will be required to do the job; predictable and/or unpredictable risks that were not considered when the project commenced; predictable and/or unpredictable risks that were not considered when the project commenced; technical difficulties that could not have been foreseen in advance; technical difficulties that could not have been foreseen in advance; human difficulties that could not have been foreseen in advance; human difficulties that could not have been foreseen in advance; miscommunication among project staff that results in delays; miscommunication among project staff that results in delays; a failure by project management to recognize that the project is falling behind schedule and a lack of action to correct the problem a failure by project management to recognize that the project is falling behind schedule and a lack of action to correct the problem

29 Scheduling Principles compartmentalization—define distinct tasks compartmentalization—define distinct tasks interdependency—indicate task interrelationship interdependency—indicate task interrelationship effort validation—be sure resources are available effort validation—be sure resources are available defined responsibilities—people must be assigned defined responsibilities—people must be assigned defined outcomes—each task must have an output defined outcomes—each task must have an output defined milestones—review for quality defined milestones—review for quality

30 Effort and Delivery Time

Effort/Delivery time Based of Software Equation L = P×E 1/3 ×t 4/3 L = P×E 1/3 ×t 4/3 L is the number of lines of code; L is the number of lines of code; E is development effort in person- months; E is development effort in person- months; P is a productivity parameter that reflects a variety of factors that lead to high-quality software engineering work; P is a productivity parameter that reflects a variety of factors that lead to high-quality software engineering work; t is the project duration in calendar months. t is the project duration in calendar months. E= L 3 /(P 3 ×t 4 ) E= L 3 /(P 3 ×t 4 ) If 148 = /(P 3 *16 4 ), If 148 = /(P 3 *16 4 ), Then 50 = /(P 3 *21 4 ) Then 50 = /(P 3 *21 4 ) 31 Et 12 PY(148 PM)1.3 years (16 months) 4.17PY (50months) 1.75years (21months) E.G. Suppose a Complex Real-time software with 33,000LOC, used 1.3 year? If we decide to use 1.75 years, what is the Effort?

32 Effort Allocation 40-50% 30-40% “front end” activities “front end” activities customer communication customer communication analysis analysis design design review and modification review and modification construction activities construction activities coding or code generation coding or code generation testing and installation testing and installation unit, integration unit, integration white-box, black box white-box, black box regression regression 15-20%

33 Defining Task Sets determine type of project determine type of project assess the degree of rigor required assess the degree of rigor required identify adaptation criteria identify adaptation criteria select appropriate software engineering tasks select appropriate software engineering tasks

34 Task Set Refinement 1.1Concept scoping determines the overall scope of the project. Task definition: Task 1.1 Concept Scoping 1.1.1Identify need, benefits and potential customers; 1.1.2Define desired output/control and input events that drive the application; Begin Task FTR: Review written description of need FTR indicates that a formal technical review (Chapter 26) is to be conducted Derive a list of customer visible outputs/inputs FTR: Review outputs/inputs with customer and revise as required; endtask Task Define the functionality/behavior for each major function; Begin Task FTR: Review output and input data objects derived in task 1.1.2; Derive a model of functions/behaviors; FTR: Review functions/behaviors with customer and revise as required; endtask Task Isolate those elements of the technology to be implemented in software; 1.1.5Research availability of existing software; 1.1.6Define technical feasibility; 1.1.7Make quick estimate of size; 1.1.8Create a Scope Definition; endTask definition: Task 1.1 is refined to

35 Define a Task Network

36 Timeline Charts Tasks Week 1 Week 2 Week 3 Week 4 Week n Task 1 Task 2 Task 3 Task 4 Task 5 Task 6 Task 7 Task 8 Task 9 Task 10 Task 11 Task 12

37 Use Automated Tools to Derive a Timeline Chart

38 Schedule Tracking conduct periodic project status meetings in which each team member reports progress and problems. conduct periodic project status meetings in which each team member reports progress and problems. evaluate the results of all reviews conducted throughout the software engineering process. evaluate the results of all reviews conducted throughout the software engineering process. determine whether formal project milestones (the diamonds shown in Figure 24.3) have been accomplished by the scheduled date. determine whether formal project milestones (the diamonds shown in Figure 24.3) have been accomplished by the scheduled date. compare actual start-date to planned start-date for each project task listed in the resource table (Figure 24.4). compare actual start-date to planned start-date for each project task listed in the resource table (Figure 24.4). meet informally with practitioners to obtain their subjective assessment of progress to date and problems on the horizon. meet informally with practitioners to obtain their subjective assessment of progress to date and problems on the horizon. use earned value analysis (Section 24.6) to assess progress quantitatively.

39 Progress on an OO Project-I Technical milestone: OO analysis completed Technical milestone: OO analysis completed All classes and the class hierarchy have been defined and reviewed. All classes and the class hierarchy have been defined and reviewed. Class attributes and operations associated with a class have been defined and reviewed. Class attributes and operations associated with a class have been defined and reviewed. Class relationships (Chapter 8) have been established and reviewed. Class relationships (Chapter 8) have been established and reviewed. A behavioral model (Chapter 8) has been created and reviewed. A behavioral model (Chapter 8) has been created and reviewed. Reusable classes have been noted. Reusable classes have been noted. Technical milestone: OO design completed Technical milestone: OO design completed The set of subsystems (Chapter 9) has been defined and reviewed. The set of subsystems (Chapter 9) has been defined and reviewed. Classes are allocated to subsystems and reviewed. Classes are allocated to subsystems and reviewed. Task allocation has been established and reviewed. Task allocation has been established and reviewed. Responsibilities and collaborations (Chapter 9) have been identified. Responsibilities and collaborations (Chapter 9) have been identified. Attributes and operations have been designed and reviewed. Attributes and operations have been designed and reviewed. The communication model has been created and reviewed. The communication model has been created and reviewed.

40 Progress on an OO Project-II Technical milestone: OO programming completed Technical milestone: OO programming completed Each new class has been implemented in code from the design model. Each new class has been implemented in code from the design model. Extracted classes (from a reuse library) have been implemented. Extracted classes (from a reuse library) have been implemented. Prototype or increment has been built. Prototype or increment has been built. Technical milestone: OO testing Technical milestone: OO testing The correctness and completeness of OO analysis and design models has been reviewed. The correctness and completeness of OO analysis and design models has been reviewed. A class-responsibility-collaboration network (Chapter 8) has been developed and reviewed. A class-responsibility-collaboration network (Chapter 8) has been developed and reviewed. Test cases are designed and class-level tests (Chapter 14) have been conducted for each class. Test cases are designed and class-level tests (Chapter 14) have been conducted for each class. Test cases are designed and cluster testing (Chapter 14) is completed and the classes are integrated. Test cases are designed and cluster testing (Chapter 14) is completed and the classes are integrated. System level tests have been completed. System level tests have been completed.

41 Summary Basic concepts Basic concepts Resources Resources Project estimation Project estimation Decomposition Decomposition Make-Buy Decision Make-Buy Decision Project Scheduling Project Scheduling Task a task set Task a task set Scheduling techniques Scheduling techniques