1. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1 Process, Product and Project Metrics Product Metrics for Software Estimation for Software Projects based on Chapter 15 Chapter 22 Chapter 23 Software Engineering: A Practitioner’s Approach, 6/e Process, Product and Project Metrics Product Metrics for Software Estimation for Software Projects based on Chapter 15 Chapter 22 Chapter 23 Software Engineering: A Practitioner’s Approach, 6/e copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited. San Diego International Airport – Access Control System : System transactions—over 250000 per. day. Average processing time—less than 15. seconds. Reliability—99.99%. System capability—upgradeable and. expandable... [www.biometric.org]

2. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 2 McCall’s Triangle of Quality Maintainability Maintainability Flexibility Flexibility Testability Testability Portability Portability Reusability Reusability Interoperability Interoperability Correctness Correctness Reliability Reliability Efficiency Efficiency Integrity Integrity Usability Usability PRODUCT TRANSITION PRODUCT TRANSITION PRODUCT REVISION PRODUCT REVISION PRODUCT OPERATION PRODUCT OPERATION proposed in the early 1970s.

3. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 3 A Good Manager Measures measurement What do we use as a basis? size? size? function? function? project metrics process metrics process product product metrics What’s the diff. between Process and Product metrics?

4. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 4 Measures, Metrics A measure provides a quantitative indication of the extent, amount, dimension, capacity, or size of some attribute of a product or process A measure provides a quantitative indication of the extent, amount, dimension, capacity, or size of some attribute of a product or process The IEEE glossary defines a metric as “a quantitative measure of the degree to which a system, component, or process possesses a given attribute.” The IEEE glossary defines a metric as “a quantitative measure of the degree to which a system, component, or process possesses a given attribute.” Software measurement (Sommerville; http://www.utdallas.edu/~chung/SE3354Honors/IEEInaugural.pdf)http://www.utdallas.edu/~chung/SE3354Honors/IEEInaugural.pdf Measurement of products or systems is absolutely fundamental to the engineering process. I am convinced that measurement as practised in other engineering disciplines is IMPOSSIBLE for software engineering Can you quantify user-friendliness, security, evolvability, …? Not everything that can be counted counts, and not everything that counts can be counted. [Albert Einstein]

5. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 5 Project Estimation Project scope must be understood (is your ADS to cover HR) ? Project scope must be understood (is your ADS to cover HR) ? Elaboration (decomposition) is necessary Elaboration (decomposition) is necessary task breakdown and effort estimates (how many do you have for your ADS?) task breakdown and effort estimates (how many do you have for your ADS?) size (e.g., FP) estimates size (e.g., FP) estimates Historical metrics are very helpful (if not, the first time will be hard) Historical metrics are very helpful (if not, the first time will be hard) Empirical models (hopefully, statistical) Empirical models (hopefully, statistical) Past (similar) project experience Past (similar) project experience At least two different techniques should be used (WHY?) At least two different techniques should be used (WHY?) Uncertainty is inherent in the process (and just about everywhere in real SE projects) Uncertainty is inherent in the process (and just about everywhere in real SE projects) 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 Conventional Methods: Establish a pragmatic strategy for controlling, tracking, and monitoring a complex technical project. So the end result gets done on time, with quality!

6. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 6 Typical Size-Oriented Metrics errors per KLOC (thousand lines of code) errors per KLOC (thousand lines of code) defects per KLOC defects per KLOC $ per LOC $ per LOC pages of documentation per KLOC pages of documentation per KLOC errors per person-month errors per person-month Errors per review hour Errors per review hour LOC per person-month LOC per person-month $ per page of documentation $ per page of documentation Typical Function-Oriented Metrics errors per FP (thousand lines of code) errors per FP (thousand lines of code) defects per FP defects per FP $ per FP $ per FP pages of documentation per FP pages of documentation per FP FP per person-month FP per person-month

7. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 7 Function-Based Metrics The function point metric (FP), first proposed by Albrecht [ALB79], can be used effectively(?) as a means for measuring the functionality delivered by a system. The function point metric (FP), first proposed by Albrecht [ALB79], can be used effectively(?) as a means for measuring the functionality delivered by a system. FPs are derived using an empirical relationship based on countable (direct) measures of software's information domain and assessments of software complexity FPs are derived using an empirical relationship based on countable (direct) measures of software's information domain and assessments of software complexity Information domain values are defined in the following manner: Information domain values are defined in the following manner:

8. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 8 Function-Based Metrics Information domain values are defined in the following manner: Information domain values are defined in the following manner: number of external inputs (EIs){password, panic button, activate/deactivate} number of external inputs (EIs){password, panic button, activate/deactivate} number of external outputs (EOs){messages, sensor status} number of external outputs (EOs){messages, sensor status} number of external inquiries (EQs){zone inquery, sensor inquery} number of external inquiries (EQs){zone inquery, sensor inquery} number of internal logical files (ILFs){system configuration file} number of internal logical files (ILFs){system configuration file} Number of external interface files (EIFs) {test sensor, zone setting, activate/deactivate, alarm alert} Number of external interface files (EIFs) {test sensor, zone setting, activate/deactivate, alarm alert} User Password Zone inquery Sensor inquery Panic button Activate/deactivate SafeHome User interaction function Sensors User Monitoring & response system Test sensor Zone setting messages Sensor status Alarm alert Activate/deactivate System configuration data Password, Sensors, … What kind of diagram is this?

9. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 9 Computing Function Points x x x x x What would be the total function points for the safehome system? What do we do next with the total function points for the safehome system? assume simple

10. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 10 LOC Approach Historical data : Average productivity for systems of this type = 620 LOC/pm. Average productivity for systems of this type = 620 LOC/pm. Labor rate = $8000/pm, Cost/LOC = 8000/620 ? Labor rate = $8000/pm, Cost/LOC = 8000/620 ? Based on the LOC estimate and the historical productivity data, estimated effort = 33200/620=54 person-months. estimated effort = 33200/620=54 person-months. total estimated project cost = 33200/620 * 8000 = $431,000 total estimated project cost = 33200/620 * 8000 = $431,000Function Estimated LOC 2-d geometric analysis 2300 3-d geometric analysis 5300 DBM3350 Graphics display facilities 4950 Peripheral control function 2100 UI2300 Design analysis modules 8400 Estimated LOC 33200 (per-month) A CAD application

11. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 11 Example: FP Approach FP estimated = count-total * [0.65 + 0.01 * Sum (F i )] --- p442 adjustment factors = 320 * [0.65 + 0.01 * 52] = 374 Historical data: organizational average productivity = 6.5 FP/pm. organizational average productivity = 6.5 FP/pm. labor rate = $8000 pm, cost per FP = ?. labor rate = $8000 pm, cost per FP = ?. Based on the FP estimate and the historical productivity data, total estimated project cost = 374/6.5 * 8000 = $461,000 total estimated project cost = 374/6.5 * 8000 = $461,000 estimated effort = 374/6.5 = 58 person-months. estimated effort = 374/6.5 = 58 person-months. See safehome example x x x x x 320 (e.g., factor in reliability, performance, reusability, complexity, …) A CAD application

12. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 12 Comparing LOC and FP Representative values developed by QSM So, which would you prefer – LOC or FP?

13. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 13 Estimation with Use-Cases Historical data: average productivity for systems of this type620 LOC/pm average productivity for systems of this type = 620 LOC/pm labor rate = $8000 pm, labor rate = $8000 pm, => cost/LOC = ?. Based on the use-case estimate and the historical productivity data, - total estimated project cost = 42568/620 * 8000 = $552,000 - estimated effort = 42568/620 = 68 pm.

14. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 14 The Make-Buy Decision (path probability) i x (estimated path cost) i (path probability) i x (estimated path cost) i expected cost build = 0.30 ($380K) + 0.70 ($450K) = $429 K = $429 K expected cost reuse = ??? = $382K expected cost buy = ??? = $267K expected cost contr = ??? = $410K expected cost =

15. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 15 Class-Oriented Metrics methods per class methods per class depth of the inheritance tree depth of the inheritance tree number of children number of children coupling between object classes coupling between object classes Proposed by Chidamber and Kemerer: class size class size number of operations overridden by a subclass number of operations overridden by a subclass number of operations added by a subclass number of operations added by a subclass Proposed by Lorenz and Kidd [LOR94]: average number of parameters per operation average number of parameters per operation Can you depict these in UML?

16. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 16 Measurement Principles The objectives of measurement should be established before data collection begins; The objectives of measurement should be established before data collection begins; Each technical metric should be defined in an unambiguous manner; Each technical metric should be defined in an unambiguous manner; Metrics should be derived based on a theory that is valid for the domain of application Metrics should be derived based on a theory that is valid for the domain of application Metrics should be tailored to best accommodate specific products and processes [BAS84] Metrics should be tailored to best accommodate specific products and processes [BAS84] How do you define technical metric unambiguously?

17. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 17 The Mythical Man-Month What is so mythical? What is so mythical? Review The Mythical Man-Month Review The Mythical Man-Month

18. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 18 Omitted Slides

19. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 19 Defect Removal Efficiency DRE = E /(E + D) E is the number of errors found before delivery of the software to the end-user D is the number of defects found after delivery. What would be the relationship betw. DRE and reliability prediction?

20. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 20 Why Do We Measure? assess the status of an ongoing project track potential risks uncover problem areas before they go “critical,” adjust work flow or tasks, evaluate the project team’s ability to control quality of software work products. SPI Process model Improvement goals Process metrics Process improvement recommendations

21. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 21 Process Measurement We measure the efficacy of a software process indirectly. We measure the efficacy of a software process indirectly. That is, we derive a set of metrics based on the outcomes that can be derived from the process. That is, we derive a set of metrics based on the outcomes that can be derived from the process. Outcomes include Outcomes include measures of errors uncovered before release of the software measures of errors uncovered before release of the software defects delivered to and reported by end-users defects delivered to and reported by end-users work products delivered (productivity) work products delivered (productivity) human effort expended human effort expended calendar time expended calendar time expended schedule conformance schedule conformance other measures. other measures.

22. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 22 Project Metrics used to minimize the development schedule by making the adjustments necessary to avoid delays and mitigate potential problems and risks used to minimize the development schedule by making the adjustments necessary to avoid delays and mitigate potential problems and risks used to assess product quality on an ongoing basis and, when necessary, modify the technical approach to improve quality. used to assess product quality on an ongoing basis and, when necessary, modify the technical approach to improve quality. every project should measure: every project should measure: inputs—measures of the resources (e.g., people, tools) required to do the work. inputs—measures of the resources (e.g., people, tools) required to do the work. outputs—measures of the deliverables or work products created during the software engineering process. outputs—measures of the deliverables or work products created during the software engineering process. results—measures that indicate the effectiveness of the deliverables. results—measures that indicate the effectiveness of the deliverables. Typical Project Metrics Effort/time per software engineering task Effort/time per software engineering task Errors uncovered per review hour Errors uncovered per review hour Scheduled vs. actual milestone dates Scheduled vs. actual milestone dates Changes (number) and their characteristics Changes (number) and their characteristics Distribution of effort on software engineering tasks Distribution of effort on software engineering tasks

23. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 23 Object-Oriented Metrics Number of scenario scripts (use-cases) Number of scenario scripts (use-cases) Number of support classes ( Number of support classes (required to implement the system but are not immediately related to the problem domain) Number of subsystems (an aggregation of classes that support a function that is visible to the end-user of a system)

24. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 24 WebE Project Metrics Number of static Web pages (the end-user has no control over the content displayed on the page) Number of dynamic Web pages (end-user actions result in customized content displayed on the page) Number of internal page links (internal page links are pointers that provide a hyperlink to some other Web page within the WebApp) Number of persistent data objects Number of external systems interfaced Number of static content objects Number of dynamic content objects Number of executable functions

25. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 25 Goal-Oriented Software Measurement The Goal/Question/Metric Paradigm The Goal/Question/Metric Paradigm (1) establish an explicit measurement goal that is specific to the process activity or product characteristic that is to be assessed (1) establish an explicit measurement goal that is specific to the process activity or product characteristic that is to be assessed (2) define a set of questions that must be answered in order to achieve the goal, and (2) define a set of questions that must be answered in order to achieve the goal, and (3) identify well-formulated metrics that help to answer these questions. (3) identify well-formulated metrics that help to answer these questions. Goal definition template Goal definition template Analyze {the name of activity or attribute to be measured} Analyze {the name of activity or attribute to be measured} for the purpose of {the overall objective of the analysis} for the purpose of {the overall objective of the analysis} with respect to {the aspect of the activity or attribute that is considered} with respect to {the aspect of the activity or attribute that is considered} from the viewpoint of {the people who have an interest in the measurement} from the viewpoint of {the people who have an interest in the measurement} in the context of {the environment in which the measurement takes place}. in the context of {the environment in which the measurement takes place}.

26. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 26 Measurement Process Formulation. The derivation of software measures and metrics appropriate for the representation of the software that is being considered. Formulation. The derivation of software measures and metrics appropriate for the representation of the software that is being considered. Collection. The mechanism used to accumulate data required to derive the formulated metrics. Collection. The mechanism used to accumulate data required to derive the formulated metrics. Analysis. The computation of metrics and the application of mathematical tools. Analysis. The computation of metrics and the application of mathematical tools. Interpretation. The evaluation of metrics results in an effort to gain insight into the quality of the representation. Interpretation. The evaluation of metrics results in an effort to gain insight into the quality of the representation. Feedback. Recommendations derived from the interpretation of productmetrics transmitted to the software team. Feedback. Recommendations derived from the interpretation of product metrics transmitted to the software team.

27. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 27 Establishing a Metrics Program Identify your business goals. Identify what you want to know or learn. Identify your subgoals. Identify the entities and attributes related to your subgoals. Formalize your measurement goals. Identify quantifiable questions and the related indicators that you will use to help you achieve your measurement goals. Identify the data elements that you will collect to construct the indicators that help answer your questions. Define the measures to be used, and make these definitions operational. Identify the actions that you will take to implement the measures. Prepare a plan for implementing the measures.

28. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 28 Why Opt for FP? Programming language independent Programming language independent Used readily countable characteristics that are determined early in the software process Used readily countable characteristics that are determined early in the software process Does not “penalize” inventive (short) implementations that use fewer LOC that other more clumsy versions Does not “penalize” inventive (short) implementations that use fewer LOC that other more clumsy versions Makes it easier to measure the impact of reusable components Makes it easier to measure the impact of reusable components

29. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 29 Omitted Slides from Estimation for Software Projects

30. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 30 Project Planning Task Set Establish project scope Establish project scope Determine feasibility Determine feasibility Analyze risks Analyze risks Define required resources Define required resources human resources, reusable software resources human resources, reusable software resources Estimate cost and effort Estimate cost and effort Decompose the problem Decompose the problem Develop two or more estimates using size, FPs, process tasks or use-cases Develop two or more estimates using size, FPs, 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

31. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 31 Resources

32. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 32 Write it Down! SoftwareProjectPlan Project Scope EstimatesRisksSchedule Control strategy

33. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 33 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

34. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 34 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!

35. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 35 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.

36. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 36 Process-Based Estimation Obtained from “process framework” applicationfunctions framework activities Effort required to accomplish each framework activity for each application function

37. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 37 Functional Decomposition functionaldecomposition StatementofScope Perform a Grammatical “parse”

38. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 38 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.

39. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 39 Tool-Based Estimation project characteristics calibration factors LOC/FP data

40. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 40 COCOMO-II COCOMO II is actually a hierarchy of estimation models that address the following areas: COCOMO II is actually a hierarchy of estimation models that address the following areas: Application composition model. Used during the early stages of software engineering, when prototyping of user interfaces, consideration of software and system interaction, assessment of performance, and evaluation of technology maturity are paramount. Application composition model. Used during the early stages of software engineering, when prototyping of user interfaces, consideration of software and system interaction, assessment of performance, and evaluation of technology maturity are paramount. Early design stage model. Used once requirements have been stabilized and basic software architecture has been established. Early design stage model. Used once requirements have been stabilized and basic software architecture has been established. Post-architecture-stage model. Used during the construction of the software. Post-architecture-stage model. Used during the construction of the software.

41. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 41 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

42. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 42 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

43. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 43 Metrics for OO Design Whitmire [WHI97] describes nine distinct and measurable characteristics of an OO design: Whitmire [WHI97] describes nine distinct and measurable characteristics of an OO design: Size Size Size is defined in terms of four views: population, volume, length, and functionality Size is defined in terms of four views: population, volume, length, and functionality Complexity Complexity How classes of an OO design are interrelated to one another How classes of an OO design are interrelated to one another Coupling Coupling The physical connections between elements of the OO design The physical connections between elements of the OO design Sufficiency Sufficiency “the degree to which an abstraction possesses the features required of it, or the degree to which a design component possesses features in its abstraction, from the point of view of the current application.” “the degree to which an abstraction possesses the features required of it, or the degree to which a design component possesses features in its abstraction, from the point of view of the current application.” Completeness Completeness An indirect implication about the degree to which the abstraction or design component can be reused An indirect implication about the degree to which the abstraction or design component can be reused Cohesion Cohesion The degree to which all operations working together to achieve a single, well-defined purpose The degree to which all operations working together to achieve a single, well-defined purpose Primitiveness Primitiveness Applied to both operations and classes, the degree to which an operation is atomic Applied to both operations and classes, the degree to which an operation is atomic Similarity Similarity The degree to which two or more classes are similar in terms of their structure, function, behavior, or purpose The degree to which two or more classes are similar in terms of their structure, function, behavior, or purpose Volatility Volatility Measures the likelihood that a change will occur Measures the likelihood that a change will occur

44. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 44 Estimation for Agile Projects Each user scenario (a mini-use-case) is considered separately for estimation purposes. Each user scenario (a mini-use-case) is considered separately for estimation purposes. The scenario is decomposed into the set of software engineering tasks that will be required to develop it. The scenario is decomposed into the set of software engineering tasks that will be required to develop it. Each task is estimated separately. Note: estimation can be based on historical data, an empirical model, or “experience.” Each task is estimated separately. Note: estimation can be based on historical data, an empirical model, or “experience.” Alternatively, the ‘volume’ of the scenario can be estimated in LOC, FP or some other volume-oriented measure (e.g., use-case count). Alternatively, the ‘volume’ of the scenario can be estimated in LOC, FP or some other volume-oriented measure (e.g., use-case count). Estimates for each task are summed to create an estimate for the scenario. Estimates for each task are summed to create an estimate for the scenario. Alternatively, the volume estimate for the scenario is translated into effort using historical data. Alternatively, the volume estimate for the scenario is translated into effort using historical data. The effort estimates for all scenarios that are to be implemented for a given software increment are summed to develop the effort estimate for the increment. The effort estimates for all scenarios that are to be implemented for a given software increment are summed to develop the effort estimate for the increment.

45. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 45 Empirical Estimation Models General form: effort = tuning coefficient * size exponent usually derived as person-months of effort required either a constant or a number derived based on complexity of project usually LOC but may also be function point empirically derived

46. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 46 The Software Equation A dynamic multivariable model E = [LOC x B 0.333 /P] 3 x (1/t 4 ) where E = effort in person-months or person-years t = project duration in months or years B = “special skills factor” P = “productivity parameter” (typical value for developing real-time embedded sw = 2000; telecom = 10000; business application = 28000) “derived from productivity data collected for over 4000 contemporary software projects”