SOFTWARE PROJECT MONITORING AND CONTROL

1. SOFTWARE PROJECT MONITORING AND CONTROL

2. Qalitative and Quantitative Data Software project managers need both qualitative and quantitative data to be able to make decisions and control software projects so that if there are any deviations from what is planned, control can be exerted. Control actions may include: Extending the schedule Adding more resources Using superior resources Improving software processes Reducing scope (product requirements)

3. Measures and Software Metrics Measurements enable managers to gain insight for objective project evaluation. If we do not measure, judgments and decision making can be based only on our intuition and subjective evaluation. A measure provides a quantitative indication of the extend, amount, dimension, capacity, or size of some attribute of a product or a process. IEEE defines a software metric as “a quantitative measure of the degree to which a system, component, or process possesses a given attribute”.

4. Measures and Software Metrics Engineering is quantitative discipline, and direct measures such as voltage, mass, velocity, or temperature are measured. But unlike other engineering disciplines, software engineering is not grounded in the basic laws of physics. Some members of software community argue that software is not measurable. There will always be a qualitative assessments, but project managers need software metrics to gain insight and control. “Just as temperature measurement began with an index finger...and grew to sophisticated scales, tools, and techniques, so too is software measurement maturing”.

5. Direct and Indirect Measures A direct measure is obtained by applying measurement rules directly to the phenomenon of interest. For example, by using the specified counting rules, a software program’s “Line of Code” can be measured directly.http://sunset.usc.edu/research/CODECOUNT/ An indirect measure is obtained by combining direct measures. For example, number of “Function Points” is an indirect measure determined by counting a system’s inputs, outputs, queries, files, and interfaces.

6. Software Metrics Types Product metrics, also called predictor metrics are measures of software product and mainly used to determine the quality of the product such as performance. Process metrics, also called control metrics are measures of software process and mainly used to determine efficiency and effectiveness of the process, such as defects discovered during unit testing They are used for Software Process Improvement (SPI). Project metrics are measures of effort, cost, schedule, and risk. They are used to assess status of a project andtrack risks.

7. Risk Triggers As the project proceeds, risk monitoring activities commence. Project manager monitors factors that may provide an indication of whether a risk is becoming more or less likely. For example, if a risk of “staff turnover” is identified, general attitude of team members, how they get along, interpersonal relationships, potential problems with compensation and benefits should be monitored. Also, effectiveness of risk mitigation strategies should be monitored. If mitigation plans fail, contingency plans should be executed.

8. Metrics Repository Software Metrics Usage • Project Time • Project Cost • Product Scope/Quality • Risk Management • Future Project Estimation • Software Process Improvement Product, Process,Project Metrics

9. Project Management Life Cycle

10. Monitoring And Controlling Monitoring and Controlling proces group consists of those processes required to track, review, and orchestrate progress and performance of the project.

11. Knowledge Areas

12. Scope Control • Monitoring project and product scope and management changes to scope baseline. • Scope is controlled by using traceability management techniques.

13. Traceability Management • An item is traceable if we can fully figure out • WHERE it comes from, WHY it is there • WHAT it will be used for, HOW it will be used • Objectives of traceability are to assess impact of proposed changes • For example, how does an item such as SDD document gets affected if we change a Use Case in SRS document? • We have to have a traceability link between SRS and SDD.

14. Traceability Management • To be identified, recorded, retrieved • Bidirectional: for accessibility from ... • source to target (forward traceability) • target to source (backward traceability) • Within same phase (horizontal) or among phases (vertical)

15. Traceability Management • Backward traceability • Why is this here? (and recursively) • Where does it come from? (and recursively) • Forward traceability • Where is this taken into account? (and recursively) • What are the implications of this? (and recursively) ß Localize & assess impact of changes along horizontal/vertical links

16. Traceability Matrix • Matrix representation of single-relation traceability graph • e.g. Dependency graph Traceable itemT1 T2 T3 T4T5 T10 1 01 0 T200 10 1 T310 00 1 T400 10 1 T5 0 0 00 0 across Ti's row: forward retrieval of elements depending on Ti down Ti's column: backward retrieval of elements which Tidepends on Jforward, backward navigation Jsimple forms of analysis e.g. cycle T1®T4®T3®T1can be detected Lunmanageable, error-prone for large graphs; single relation only

17. Scedule and Cost Control Monitoring project activities and taking corrective actions if there are any deviations from what is planned like project crashing.

18. Binary Tracking Binary tracking requires that progress on a work package, change requests, and problem reports be counted as: • 0% complete until the associated work products pass their acceptance criteria • 100% complete when the work products pass their acceptance criteria

19. Binary Tracking Assume a 20,000 LOC system (estimated), with development metrics: 270 of 300 requirements designed: 90% 750 of 1000 modules reviewed: 75% 500 of 1000 modules through CUT: 50% 200 of 1000 modules integrated: 20% 43 of 300 requirements tested: 14% CUT: Code and Unit Test These numbers are obtained using binary tracking of work packages

20. Binary Tracking Also assume our typical distribution of effort is: • Arch. Design: 17 % • Detailed Design: 26 % • Code & Unit Test: 35 % • Integration Test: 10 % • Acceptance Test: 12 % • Percent complete is therefore: 90(.17)+75(.26)+50(.35)+20(.10)+14(.12) = 56% complete

21. Binary Tracking Project is 56% complete; 44% remains Effort to date is 75 staff-months Estimated effort to complete is therefore: (44 / 56) * 75 = 60 staff-months

22. Earned Value Management EVM compares PLANNED work to COMPLETED work to determine if work accomplished, cost, and schedule are progressing as planned. The amount of work actually completed and resources actually consumed at a certain point in a project TO The amount of work planned (budgeted) to be completed and resources planned to be consumed at that same point in the project

23. Earned Value Management Budgeted Cost of Work Scheduled (BCWS): The cost of the work scheduled or planned to be completed in a certain time period per the plan. This is also called the PLANNED VALUE. Budgeted Cost of Work Performed (BCWP): The budgeted cost of the work done up to a defined point in the project. This is called the EARNED VALUE. Actual Cost of Work Performed (ACWP): The actual cost of work up to a defined point in the project.

24. Earned Value Management Schedule Variance: SV = BCWP – BCWS Schedule Performance Index: SPI = BCWP / BCWS Cost Variance: CV = BCWP - ACWP Cost Performance Index: CPI = BCWP / ACWP

25. Earned Value Management SV, CV = 0 Project On Budget and Schedule SV, CV < 0 Over Budget and Behind Schedule SV, CV > 0 Under Budget and Ahead of Schedule CPI, SPI = 1 Project On Budget and Schedule CPI, SPI < 1 Over Budget and Behind Schedule CPI, SPI > 1 Under Budget and Ahead of Schedule

26. Earned Value Management Project Description: We are supposed to build 10 units of equipment We are supposed to complete the project within 6 weeks We estimated that 600 man-hours to complete 10 units It costs us $10/hour to build the equipment Our Plan: We are supposed to build 1.67 units each week Each unit costs $600 We will spend $1,000 each week

27. Earned Value Management Project status: Week 3 4 units of equipment completed 400 man-hours spent How are we doing? Are we ahead or behind schedule? Are we under or over budget? Results: Accomplished Work: 4/10 = %40 complete Schedule: 3/6 = %50 over Budget: 400/600 = %67 spent

28. Earned Value Management BCWS=(600 man-hours*$10/hour)*(3/6 weeks) = $3000 BCWP=(600 man-hours*$10/hour)*(4/10 units) = $2400 ACWP=400 man-hours*$10/hour = $4000 The price of the job that we have done is only $2400 (4 units) Schedule: in 3 weeks, the price of the job that we should have done was $3000 Cost: We spent much more; we spent $4000

29. Earned Value Management SV = BCWP – BCWS = $2400 - $3000 = -$600 SV is negative; we are behind schedule CV = BCWP – ACWP = $2400 - $4000 = -$1600 CV is negative; we are over budget SPI = BCWP / BCWS = $2400 / $3000 = 0.8 SPI is less than 1; we are behind schedule CPI = BCWP / ACWP = $2400 / $4000 = 0.6 CPI is less than 1; we are over budget

30. Earned Value Management Earned Value analysis results are used to predict the future performance of the project Budget At Completion (BAC) = The total budget (PV or BCWS) at the end of the project. If a project has Management Reserve (MR), it is typically added to the BAC. Amount expended to date (AC) Estimated cost To Complete (ETC) ETC = (BAC – EV) / CPI Estimated cost At Completion (EAC) EAC = ATC + AC

31. Risk Control Implementing risk response plans, tracking identified risks, identifying new risks, and evaluating risk process effectiveness.

32. Risk Control

33. Risk Exposure Risk exposure is the product of PROBABILITY x POTENTIAL LOSS A project with 30% probability of late delivery and a penalty of $100,000 for late delivery has a risk exposure of: 0.3 x 100,000 = $30,000

34. Risk Leverage Factor Risk Leverage Factor: RLF = (REb - REa) / RMc where REb is the risk exposure before risk mitigation, REa is the risk exposure after risk mitigation and RMc is the cost of the risk mitigating actions

35. Risk Leverage Factor Suppose we are considering spending $25,000 to reduce the probability of a risk factor with potential impact of $500,000 from 0.4 to 0.1 then the RLF is:(200,000 - 50,000) / 25,000 = 6.0 • Larger RLFs indicate better investment strategies • RLFs can be used to prioritize risk and determine mitigation strategies

36. Risk Register A risk register contains the following information for each identified risk factor: • Risk factor identifier • Revision number & revision date • Responsible party • Risk category (schedule, resources, cost, technical, other) • Description • Status (Closed, Action, Monitor)

37. Risk Register If closed: date of closure and disposition (disposition: avoided, transferred, removed from watch list, immediate action or contingent action completed, crisis managed) If active: action plan number of contingency plan number & status of the action) (status: on plan; or deviating from plan and risk factors for completing the plan)

38. Quality Control Monitoring and controlling project and product quality

39. Reviews and Inspections • The review process in agile software development is usually informal. • In Scrum, for example, there is a review meeting after each iteration of the software has been completed (a sprint review), where quality issues and problems may be discussed. • In extreme programming, pair programming ensures that code is constantly being examined and reviewed by another team member. • XP relies on individuals taking the initiative to improve and re-factor code. Agile approaches are not usually standards-driven, so issues of standards compliance are not usually considered.

40. Reviews and Inspections • These are peer reviews where engineers examine the source of a system with the aim of discovering anomalies and defects. • Inspections do not require execution of a system so may be used before implementation. • They may be applied to any representation of the system (requirements, design,configuration data, test data, etc.). • They have been shown to be an effective technique for discovering program errors.

41. Reviews and Inspections • Agile processes rarely use formal inspection or peer review processes. • Rather, theyrely on team members cooperating to check each other’s code, and informal guidelines, such as ‘check before check-in’, which suggest that programmers should check their own code. • Extreme programming practitioners argue that pair programming is an effective substitute for inspection as this is, in effect, a continual inspection process. • Two people look at every line of code and check it before it is accepted.

42. Software Process Improvement SPI encompasses a set of activities that will lead to a better software process, and as a consequence a higher-quality software delivered in a more timely manner. SPI help software engineering companies to find their process inefficiencies and try to improve them.

43. Software Process Improvement

44. Software Process Improvement • Process measurement • Attributes of the current process are measured. These are a baseline for assessing improvements. • Process analysis • The current process is assessed and bottlenecks and weaknesses are identified. • Process change • Changes to the process that have been identified during the analysis are introduced. For example, process change can be better UML tools, improved communications, changing order of activities, etc.

45. Software Process Improvement

46. Software Process Improvement There are 2 different approaches to SPI: Process Maturity: It is for “Plan-Driven” development and focuses on improving process and project management. Agile: Focuses on iterative development and reduction of overheads. SPI frameworks are intended as a means to assess the extent to which an organization’s processes follow best practices and help to identify areas of weakness for process improvement.

47. CMMI Process Improvement Framework • There are several process maturity models: • SPICE • ISO/IEC 15504 • Bootstrap • Personal Software Process (PSP) • Team Software Process (TSP) • TickIT • SEI CMMI

48. CMMI Process Improvement Framework • Capability Maturity Model Integrated (CMMI) framework is the current stage of work on process assessment and improvement that started at the Software Engineering Institute (SEI) in the 1980s. • The SEI’s mission is to promote software technology transfer particularly to US defense contractors. • It has had a profound influence on process improvement. • Capability Maturity Model introduced in the early 1990s • Revised maturity framework (CMMI) introduced in 2001

49. CMMI Process Improvement Framework • CMMI allows a software company’s development and management processes to be assessed and assigned a score. • There are 4 process groups which include 22 process areas. • These process areas are relevant to software process capability and improvement.

50. CMMI Process Improvement Framework