1 / 60

Software Project Management SE603 Unit 10 : metrics and project related measures.

Software Project Management SE603 Unit 10 : metrics and project related measures. Egypt, 15.6.2015. Introduction. Software developers are usually not interested in using metrics as collecting them requires an effort of several years.

jadon
Download Presentation

Software Project Management SE603 Unit 10 : metrics and project related measures.

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Project Management SE603Unit 10: metrics and project related measures. Egypt, 15.6.2015

  2. Introduction • Software developers are usually not interested in using metrics as collecting them requires an effort of several years. • However the lack of measurements won’t give us the chance to know if we are progressing well or not. • Software metrics spot the areas that needsimprovement in every stage of the management process. • For example, in the planning phase, such metrics are used to plan resources allocation and estimate budgets and monitor schedules.

  3. Introduction • The metrics are developed to empower decision makers to highlight weakness and spot deviations, as a result, they could take the corrective actions. • The project manager considers comparing the metrics figures with the industry benchmark to determine how far your project metrics are far from the industry standards • In this unit, the concept of the metrics and project related measures illustrated and the importance of the metrics in monitoring project performance highlighted while going through different types of metrics and how they are calculated.

  4. Objectives Understanding the concept of the metrics and project related measures Going through different types of metrics and how they are calculated Determining the importance of the metrics in monitoring project performance

  5. Unit 10: List of topics 1. Introduction 2. Causes of Project Failure 3. What are Metrics? 4. Motivation for Metrics 5. Metrics Types 5.1 Project Scope related 5.2 Project requirements related 5.3 Project Software related 6. Integrating Metrics within the Software Process 7. Setting up metrics

  6. 1. Introduction • As mentioned earlier in unit 1, on history baseline ITprojects have huge failure rates. • As project management advances with easier project management tools and the availability of the Internetthat made communication much easier successfully, failure rates started to drop. • However, despite this support, still a big portion of projects still failed or not become complete successes.

  7. 1. Introduction • According to a study conducted In 2001 by the US Commerce Department's National Institute of Standards and Technology (NIST) [1], software "bugs” cost the American companies around $60 billion dollars.

  8. 2. Causes of Project Failure • There are many causes contributing to the project failure such as: • Poor planning, • constantly-changing requirements and goals, • limited knowledge of software tools and technology, • lack of strong communications. • In these types of situations, mostly the management is the last to know about any problems.

  9. 2. Causes of Project Failure • However these failures don’t appear all of a sudden, there are warning signs for smelling theses failures such as[2,3,4]: • Excessive working overtime • Struggling to meet Milestones • Changes in the Project scope • Lackof interest in the project • Poorcommunicationamong workers • Fearof talking about project problems

  10. 2. Causes of Project Failure • Therefore, project metrics are required to track and measurethe success of the IT project. • Project metrics are used to measure the health of processes, activities, resources, and deliverables.

  11. 3. What are Metrics? • Metrics are used to measure and report on the stateof a particular IT processes, activities, resources, and deliverables. • Measure [5] is a quantitative indication of certain attribute (weight (kg), distance (meter), time (seconds) or size (Number of lines of code or Number of Errors)).

  12. 3. What are Metrics? • Metric[5] is the scalefor measurement. E.g., number of errors found in thousand lines of code. The number of of errors is a measurement and the number of lines of code is anothermeasurement.

  13. 4. Motivation for Metrics • The metrics should be developed in order to empower decision makers to highlight weakness and spot deviations, as a result, they could take the corrective actions. • The project manager consider comparing the metrics figureswith the industry benchmarkto determine how far your project metrics are far from the industry standards.

  14. 4. Motivation for Metrics • As soon as the project metrics figures approach the averageor optimal cases of the benchmarks that means that the project is running on safe railroad. Otherwise, many enhancements should be injected and considered. • So metrics are notlimited to measuring the quality of the project and monitor the status but they are extended to estimatecost & schedule of future projects, forecast the productivity and staffing needs.

  15. 5. Metrics Types • Metrics types are many. Some are related to the project scope, others are related to the requirements, another group is related to software, etc. There are metrics for every aspect or stage your are interested to track. In this unit, we present the most common know project metrics on the following domains: • Project Scope metrics • Project requirements metrics • Software metrics

  16. 5.1 Project Scope Metrics (1/19) • Quantitative metrics • Earned Value metrics are used to measure current project performance and forecastfuture performance. • In figure 1, the Planned Value (PV) line represents the planned budget for the project to have it complete. The Actual Cost (AC) line represents the amount of money spent for the completed work items. As depicted, we might consider the project is running under budget.

  17. 5.1 Project Scope Metrics (2/19) • Quantitative metrics • From work complete standpoint, we might run under budget as we had less work complete than we should. Therefore, we should depict the amount of work done. • In Figure 3, The Earned value (EV)line represents the amount work done. As the earned value line is higher than actual cost line, that implies that the amount of work complete is more in value that the amount of money spent. We are running under budget.

  18. 5.1 Project Scope Metrics (3/19) • Quantitative metrics • However, in figure 2, we have less work complete than planned. What this really means we are behind schedule. • Figure 4 combines EV, PV and AC together. The best way to read these three-line charts is to identify the EV curve first, then compare it to PV (for schedule performance) and AC (for cost performance).

  19. 5.1 Project Scope Metrics (1/ http://www.lynda.com/ [15]

  20. 5.1 Project Scope Related (4/19) • To apply the Earned Value metrics, the following should be available: [15] • A project plan that identifies the work to be accomplished where work is broken into manageable and small enough in size that can get real visibility components. All these components are organized into Work Breakdown Structure.

  21. 5.1 Project Scope Related (5/19) • A project schedule that define when each element of work should be accomplished, the logical sequence of operations and the relationships between the work products • Aprojectbudgetplan that identify the costs down to the work package leveland the assigned a cost to each of these components in your Work Breakdown Structure • Ameasurement system for tracking Earned Valueto track costs at the work package level.

  22. 5.1 Project Scope Related (6/19) • Schedule Based Metrics • Calculation of Schedule Variance (SV) and Schedule Performance Index (SPI) [15] • Consider the case of developing two SW components and having them complete on Wednesday consider the budget value of the component is 100$. By Wednesday, only one complete is complete, which means we are behind schedule by $100 worth of work. So the Schedule Variance is a -$100 worth of work. SV = EV (100$) - PV (200$), which means less work is completed than planned. We are behind schedule. In this case a corrective action is recommend.

  23. 5.1 Project Scope Related (7/19) • Schedule Based Metrics • Calculation of Schedule Variance (SV) • If SV equals $0 we are on schedule. • If SV > $0 we are ahead of schedule. • If SV < $0 we are behind schedule.

  24. 5.1 Project Scope Related (8/19) • Schedule Based Metrics • and Schedule Performance Index (SPI) [15] • the Schedule Performance Index (SPI) = Earned Value / Planned Value = $100 / $200 = 1/2. This means we are progressing at 1/2 the rate expected. As it was planned to have two components complete, we only have one component complete. • If SPI = 1 we are right on schedule • If SPI > 1 we are ahead of schedule • If SPI < 1 we are behind schedule.

  25. 5.1 Project Scope Related (9/19) • Cost Based Metrics • Calculation of Cost variance (CV) • Completing the previous example of the development of two software components. One component is done that should cost $100, however, it did cost $400. So, the Cost Variance (CV) = Earned Value (EV) -Actual Cost (AC) = -300$. If mean we run over budget by $300. • If CV = $0 we are on budget • If CV > $0 we run under budget. • If CV < $0 we run over budget.

  26. 5.1 Project Scope Related (10/19) • Cost Based Metrics • Cost performance index (CPI) • The CPI = Earned Value / Actual Cost = $100/$400 = 1/4. which means that for every dollar we spend we're getting .25 cents of value. We have done one component complete with plans to spend $100. However, we spent $400. We are getting a quarter of the value expected. • If CPI = 1 we are on budget • If CPI > 1 we run under budget • If CPI < 1 we run over budget.

  27. 5.1 Project Scope Related (11/19) • ForecastingEstimate At Completion (EAC) • A real critical benefit of Earned Value management is using the current results to forecast future performance. • This forecast is called the Estimate at Completion(EAC).It is a forecast of what we expect the entire project to cost. To forecast, several assumptions assumed:

  28. 5.1 Project Scope Related (12/19) • First Assumption: • Continuing to the previous example of the two software components. Having spent $400 to complete one component while planning to have 4 components. if we continue to spend at the same rate, it should cost $1,600 to complete the total project. So the EAC = BAC/CPI. BAC is the original budget for the project. EAC = $400 / 0.25 = $1,600(in case spending at the same rate)

  29. 5.1 Project Scope Related (13/19) • Second Assumption: • Assuming that the remainder of the work will be completed at the original planned rate. We have spent $400 so far for the work that is complete. Three components left for $100 each. So the EAC is $400 for the done component and $300 for the remaining components, giving a total of $700. EAC = AC + (BAC-EV) = $400 + ($400 - $100) = $700.

  30. 5.1 Project Scope Related (14/19) • Third Assumption • Assuming the EAC is influenced not only by Cost Performance, but also by Schedule Performance. Being behind schedule at times certainly has led to an increased cost and the vice versa. EAC = AC + [(BAC-EV)/(SPI*CPI)] = $2,800. EAC is high as we are running both over budget and behind schedule.

  31. 5.1 Project Scope Related (15/19) • Forecasting Estimate To Completion (ETC) and Variance At Completion (VAC) • ETC is an estimate or a forecast of how much more we need to spend over what we have already spent. Two ways to determine ETC

  32. 5.1 Project Scope Related (16/19) • First Assumption: • Assuming we spend at the same rate. Continuing to the software components example, we estimate the total project will cost $1,600. Then the ETC would be $1,600 - $400 = $1,200 over what we have spent to complete the project. • ETC = EAC-AC. This ETC is not as useful on the actual projects. On most actual projects, we most likely will not have forecasted Estimate at Completion yet. Therefore, someone or maybe multiple team members will need to determine ETC based on a bottoms-up estimate.

  33. 5.1 Project Scope Related (17/19) • Second Assumption: • VAC is a measure of how much we expect to overrun or under run from the project budget. • We have a budget of $400. If we assume we will continue to spend at the same rate, we have estimated the Estimate at Completion to be $1,600. Therefore, we are forecasting an overrun of $1,200. the VAC = BAC ($400$) – EAC ($1600) = -$1,200. We are forecasting an overrun with negative variance.

  34. 5.1 Project Scope Related (18/19) • (2) Qualitative metrics [6] • These metrics are based on subjective evaluationof the factors. For example, Social abilities are based on communication skills and knowledge. Ability to be an effective team member is based on skills, training and social behavior between the project team members.

  35. 5.1 Project Scope Related (19/19) • (2) Qualitative metrics [6] • The Degree of Satisfaction (DS) can be computed as: • DS value of zero means poor satisfaction. • DS value of one means complete satisfaction. DSRi – the degree of satisfaction for requirement i TR – total number of requirements P = the number of requirements

  36. 5.2 Project requirements related (1/4) • Project Requirements metrics • The continuous change in the project requirementscauses a severe deviation in the scope and the exponential increase in workload resulting the project manager to struggle in steering the project operations. • Requirement metrics are used to identify risks by spotting errors and changes in the requirements document [9,10].

  37. 5.2 Project requirements related (1/4) • Project Requirements metrics • Several metrics exist in this category such as requirement traceability metric, andvolatilitymetric. Using one metric doesn’t ensure the overall quality. It is highly preferable to use multiple metrics for measurement.

  38. 5.2 Project requirements related (1/4) • Project Requirements metrics • (1) Requirements Traceability Metric (RTM) • This metric traces the requirements from the project inception to the final phase. That is done to ensure that scope, requirements and outputs are aligned with the baseline. RTM is implemented across all phases of a project [11].

  39. Sample of Requirements Traceability Matrix (2/4) http://www.rbreporting.com/requirements_traceability_matrix_report.htm

  40. 5.2 Project requirements related (3/4) (2) Requirements Volatility Metric (RVM) [12] Requirement change rate (volatility) drops significantly from the inception of the project till the final implementation phases. It starts high and ends very low.

  41. 5.2 Project requirements related (4/4) (2) Requirements Volatility Metric (RVM) [12] The degree of the requirement changes over the time period is called Requirement Volatility. RV metric is used to determine if the changes are consistent with current development activities or not and helps in tracing future requirements, design, and code volatility by indicating the requirements changes such as addition, deletion and modifications.

  42. 5.3 Project Software related (1/5) • This category of metrics are concerned with the programming language and the functionality delivered by the application • For Software development effort and cost Metrics, there are two widely known metrics Size-Oriented and Function Oriented.

  43. 5.3 Project Software related (2/5) • (1) Size-oriented Metrics [13] • These metrics consider the size of the software produced. These metrics are based on the thousand lines of code (KLOC) as the normalization value. The metrics could be: • Errors per KLOC - Errors per person-month • Dollars per KLOC -Dollars per page of documents • Pages of documentation per KLOC • These metrics are very poor as they are highly dependent on the programming language and don’t accommodate the nonprocedural languages easily.

  44. 5.3 Project Software related (3/5) • (2) Function-oriented metrics [13] • Function Point (FP) is an example metric for this category. The FP mentioned earlier in the effort estimation unit. The normalization value of these metrics is the functionality delivered by the application. • Function point values are derived from the past projects data, for example, the average number of lines of code per function point (e.g., 60)

  45. 5.3 Project Software related (3/5) • (2) Function-oriented metrics [13] • The advantages of the FB over the KLOC that FP is programming language independent and FP is based on data that could be collected in the early stages of a project and could be as an estimation approach as mentioned in the effort estimation unit. • The disadvantages of the FB that its computation depends on subjective data.

  46. 5.3 Project Software related (5/5) • For Software Quality Metrics, an example of such metrics is the maintainability. • Maintainability [13] • This metric measure the easiness for correcting errors in the program and adaptability for the requirements changes. The time for analyzing, implementing, testing and distributing the changes to all users is called Mean Time To Change (MTTC). The maintainable programs have low MTTC value.

More Related