2. Project, People, Processes and Products Project management skills – schedule, monitoring, risk management, … People management skills – delegation, mentoring, staffing, promoting, evaluating, training, … Process management skills – life cycle model processes and deliverables Product management skills – quality control, metrics, …

3. The 5 functions of management Planning – selection of missions and objectives, commitment of resources and scheduling of actions Organizing – structure of role for people, assignment of responsibilities and authorities Staffing – hiring, retaining, training, evaluating, promoting people Leading – create a healthy working environment to motivate people and help achieving results Controlling – taking corrective actions if actual performance deviates from planned performance, rewarding and disciplining people

4. 5 Management functions

5. Project management activities Project startup – at the beginning – Estimation, staffing, training, scheduling, risk identification … Project execution – during the project – Control, reviews, SQA, risk monitoring, … Project closeup – at the end – Post mortem evaluation, archiving, …

7. Top 10 reasons why projects fail Inadequately trained and/or inexperienced project managers Failure to set and manage expectations Poor leadership at any and all levels Failure to adequately identify, document and track requirements Poor plans and planning processes Poor effort estimation Cultural and ethical misalignment Misalignment between project team and business it serves Inadequate or misused methods Inadequate communication, including progress tracking and reporting

8. Estimation techniques Estimation during project startup Time and effort to be included in initial project schedule Avoid overestimation or underestimation Micro level and macro level estimation – Macro level: not detailed, based on Kilo line of code – Micro level: detailed, more accurate,

9. Estimation techniques Requirements level estimation – black-box, high level – Function point, feature point, use case point Implementation level estimation – white box, low level based on code – COCOMO

10. Empirical estimation models E = (a + (b x Size c )) x F – a, b and c are model coefficients that are empirically obtained, – Size is the estimated size of the project in KLOC – F is a product of factors influencing project estimates. In the Bailey-Basili model: E = (5.5 + (0.73 x Size 1.16 ) x F – The same general equation is also used to estimate the effort for projects where the Size is estimated in terms of function points needed. In Kemerer model: E = (-37 + 0.96 x Size) x F – F depends on project complexity factors.

11. Function point metrics Complexity of software and the effort needed to develop it are a function of the number and type of five different kinds of functional components that can be obtained and assessed at the requirements specifications phase. – internal files (IF) corresponding to the database files that are created and maintained within the application to develop. – external files (EF) corresponding to the files owned and maintained by other applications, but are used by the application to develop. – external inputs (EI) corresponding to the inputs that affect the control flow and internal logic of the application leading to the creation and maintenance of data. – external outputs (EO) corresponding to the data leaving the application to different output devices, files or external systems. – external inquiries (EIQ) corresponding to simple user queries resulting in responses to them.

13. Example 10.1 Suppose the software to develop has 1 EIs, 3 EOs, and 1 UI, all of simple complexities, the number of unadjusted function points (UFP) would then be 3*1+4*3+3*1 = 18. In addition, it has 2 Eis and 1 UI of average complexity, and 1 EI, 1 EO, 1 IF and 3 EF of high complexity. Similar computations should be performed for the remaining average and complex components. The total number of UFPs is: (3*1+4*3+3*1) + (4*2+4*1) + (6*1+7*1+15*3+10*1) = 98 UFPs.

16. A rating from 0 to 5 is assigned to each factor. Their sum is computed to obtain a value for S.

17. Computing the adjusted function points (AFP) The overall complexity factor F is then computed using the equation: CF = 0.65 + 0.01 x S – CF will be within the range 0.65 to 1.35. – The number of adjusted function points (AFP) is UFP x CF

18. Reconciling estimations Another approach the manager can take to reduce the risk of underestimation is to produce estimates using different techniques and performed by different experts. Differences between the estimated efforts can then be reconciled using statistical analysis techniques. For example, if the three estimates, E Low, E High and E Mid are obtained, such that E Low < E Mid < E High, the value for E that can be used is computed using the equation: E = (E Low + 4 x E Mid + E High) / 6

19. Mapping AFP to Effort m = f 3*j / 27 person-months. j depends on the type of the software application involved and the capabilities and expertise of the development team and varies from 0.39 to 0.48. In Example 10.1, if we consider j = 0.43, the number of person-months would be 13.71 Average number of LOC per function point in the C and Java are 162 and 63, respectively In Example 10.1, the estimated number of lines would be about 15 KLOC of C code or 6 KLOC of Java code.

20. FP estimation excel sheet >sheet Assumptions: Effort exponent is 0.43 Cost per day is 400 $ 20 working day per month 65 Java lines of code per AFP

21. Use case point (UCP) estimation By Kamer in 1993 – an extension of FP method based on UCM. Based on steps or transactions in a Use Case Unadjusted Actor Weight (UAW), Unadjusted Use Case Weight (UUCW) Unadjusted Use Case Point UUCP = UAW + UUCW Adjusted UCP AUCP = UUCP x TCF x ENVF

23. TCF = 0.6 + 0.01 x TF, TF is sum of weighted values EF = 1.4 – 0.03 x ENVF, ENVF is sum of all weighed values

26. Computing the effort 25 person-hours per AUCP Use case PlaceOrder: complex use case, 3 actors: buyer is complex and warehouse and accounting are simple UAW = 5, UUCW = 15, UUCP = 20 TF = 38.5, TCF = 0.985, ENVF = 21.5, EF = 0.755 AUCP = 20 x 0.985 x 0.75 = 14.87 Effort is (14.87 x 25) / 7hrs/day = 53.11 days

27. UCP estimation excel sheet >Sheet Assumptions: Person-Hours per AUCP is 25 7 hours of work per day 400 $ per day

28. COCOMO Constructive Cost Model by Boehm in 1981 Based on estimated program size in KLOC Basic – no consideration for factors E = a x Size b D = c x E d P = E / D Intermediate – considers effort adjustment factor Detailed – adjustment factors for different phases of development

30. Example 10.3 Semi-detached software, estimated 100 KLOC. Estimated effort in person-months E = 3 x 100 1.12 = 521 person-months, D = 2.5 x 521 0.35 = 8.93 months and P is E / D = 58.36 persons. The formula used in intermediate COCOMO is: E = a x Size b x EAF where coefficients a and b are given in Table 10.9, Size is the estimated KLOC and EAF computed using the cost drivers rating table.

33. Example 10.4 For the same semi-detached software project we have considered in Example 10.3, the ratings and corresponding multipliers for each of the 15 factors are shown in Table 10.11. The EAF for this project is 1.63. The effort E in persons-months is 3 x 100 1.12 x 1.63 = 849.78 persons-months.

35. Risk Management One main reason for project failure: inability to deal adequately with anticipated or unanticipated problem Ideally all risks must be anticipated by manager Software risk: a problem occurring during the development of the software and the consequence of that problem. Continuous process: Risk engineering cycle Aim: make timely and informed decisions and take appropriate risk control actions to deal with the risk – Prevention, detection, response

37. Risk management planning Planning involves startup risk management activities for the software project. Meetings for – defining the risk efforts – risk management budget and schedule – assigning risk responsibilities within the development group and beyond – defining the interactions with other stakeholders – deciding on the templates, risk taxonomies and other standards and procedures to follow.

38. Risk identification First step in a risk management process Risk identification requires the expertise of application domain experts in addition to general project management experience. Early identification reduces the costs incurring should the risk occur. Late identification may limit the available risk mitigation solutions and make them costlier A formal process involving the various stakeholders may be needed for complex high stakes projects. Involve reviewing project documents to identify potential problems, conducting information gathering techniques including brainstorming and interviewing, and performing checklist evaluation.

39. Types of risks Product risks and its capabilities – Examples of risks in this category are the unfeasibility of a requirement, the bad performance of a selected design solution, and the insecurity of an access control mechanism. Process risks – Examples of risks in this category are the unfamiliarity of the development team with the adopted process model, the unsuitability of the adopted process model, and the potential communication problem and lack of team coherence. Technical and developmental risks – Examples of risks in this category are the unfamiliarity of the development team with the development system, and the unfamiliarity of the team with the tools and techniques used.

40. Project risks Project risks are technical and non-technical risks related to project management style, project plan, effort estimation, risk planning, and project dependencies and constraints. Examples of technical project risks are the underestimation of effort for scheduled project activities, the inadequacy or lack of project progress monitoring methods, the unavailability of third party software when needed, and the project constraints are unfeasible and overly restrictive. Examples of non-technical people-related project risks include the lack of synergy among team members, and the lack of communication among the various project stakeholders.

41. Getting risks To cover all potential risks, the manager must be experienced, rely on the expertise of others in the organization, consider different published project risks taxonomies, and participate in brainstorming sessions with other project stakeholders to elicit potential software risks. Identified risks must also be well documented and maintained. Each risk is assigned to an owner. The risk owner is a developer who will be responsible for following up on the planning, tracking and control of the risk.

42. Risk analysis (assessment) After identifying the risks, they must be assessed and verified for appropriateness and applicability. The likelihood of their occurrence and their impacts on the project schedule, cost and quality must be evaluated either qualitatively or quantitatively. In a qualitative assessment, the risk likelihood (RL) ranges from very low, low, medium, high to very high. The risk impact (RI) ranges from negligible, minor, tolerable, significant, to major. In a quantitative assessment, risk likelihood and risk impacts are continuous. In a quantitative assessment, the risk exposure (RE) for each risk can then be computed as follows: RE = RL x RI

43. Risk prioritization For example, if the risk likelihood is 25%, and its impact is the loss of 1000 $, then the risk exposure is 250 dollars. Based on the risk exposure, identified risks can then be assigned different priorities. A risk priority can be very low, low, medium, high or very high. Obviously, high exposure risks should be dealt with very thoroughly since they will most probably be assigned a very high priority. The main challenge in analyzing the risks is to find the correct likelihood of occurrence of each risk and its exact impact. – Use interviews and meeting with internal experts or consultants in the application domain.

45. Risk planning A risk response plan must be designed for every risk identified. A risk response plan aims at enhancing the opportunities to counter the risk and to reduce the threats it poses to the project. – Avoidance, mitigation, acceptance and transference The different types of risk actions are developed and prioritized.

46. Risk reduction leverage The aim of a risk action is to reduce the risk exposure. The risk reduction leverage (RRL) can be computed for every risk action as follows: RRL = (Exposure before reduction – Exposure after reduction) / Risk action cost – if a risk action costs $2000 and reduces the risk exposure from $100000 to $20000, the RRL would be 40. Clearly, for the same risk action cost, the higher the RRL, the better is the return on investment leading to a lesser exposure. The RRL can be used to assess the effectiveness of the possible risk control actions and to decide on the most effective action with the highest return on investment.

47. Risk avoidance and risk mitigation Risk avoidance actions to prevent the risk from occurring. – Examples are actions to improve the communications among team members and to increase by 20% the efforts estimated for critical activities in the project schedule to deal with the risk of project delivery delays. Risk mitigation actions to reduce the risk impact should it occur. Timely and planned actions to reduce the likelihood and impact of a risk are typically taken when the risk is unavoidable but its impact could be very costly. – An example of a mitigation action is the development of a disaster recovery plan to deal with the risk of a natural or man-made disaster.

48. Risk acceptance and risk transference Risk acceptance meaning no action is to be taken should the risk occur. – Typically, very low impact and low exposure risks are accepted and their costs are assumed without further actions. Risk transfer actions to shift the responsibility of dealing with the risk and taking the appropriate action to a third party should the risk occur. – The third party could be an insurance company or a financial institution. – Risk transference are normally considered when dealing with non-technical risks such as contracts, financing risks and natural disasters.

49. Risk tracking An ongoing activity based on the monitoring of the risks by continuously checking the conditions for their occurrences. The proper implementations of risk actions are also monitored. Risk tracking techniques includes periodic risk status reports, and the monitoring of key risk indicators. The early detection of the imminence of a risk occurrence is desirable since it enhances the preparedness of the team to initiate, implement and control the risk actions planned earlier. Once a risk is realized, the planned risk actions are activated to deal with that risk.

50. Risk control Risk control is part of the overall project control dealing with the proper implementation of the control actions and risk plan. If corrections to the actions or to their implementations are needed, updates to the risk management plan will be made. Risk control may involve risk reassessment, risk audits and risk status meeting. These risk control activities are normally needed when some identified risks are not being dealt with according to plan or if the manager notices the occurrence of an unusual number of unanticipated risks.

51. Risk communication Risks must be communicated to the concerned stakeholders. Failing to communicate risks and risk plans gives a false sense of protection against the occurrence of these risks. To properly follow up and control risks, risks must be communicated to different units within the organization and to the different levels of management. Risks may need to be communicated to the client’s organization. – For example, the client must be aware of the risks related to changes to the requirements and the implication consequences of such changes on the project schedule.

53. Scheduling and tracking projects Schedule is influenced by available resources and estimations Tracking project progress to avoid delays and take timely necessary actions To manage and track a large project, the project manager needs to divide the project work into related tasks. Tasks need to be structured around the phases of the life cycle model adopted by the development company.

54. Project tasks A task has an identity and a purpose, a duration, a start time, a list of predecessor tasks if any, and the resources needed to complete it. Predecessor tasks are those tasks needed prior to the start of the task at hand. Resources include human, software, hardware and possibly financial resources. A milestone is a particular point in time at which the task is completed. Breaking the project into small and manageable tasks will allow the early detection of lateness in a project. Task duration need not be too long or too short

56. Tracking techniques Different techniques can be used to track or monitor the progress of a project. Monitoring the adherence to completion dates or milestones set for the project tasks can be achieved by conducting progress review meetings, or by periodically reporting the progress achieved so far. Once early signs of lateness are detected, the manager can intervene in different ways depending on the severity of the problem and the causes of lateness.

57. Representing project tasks The tasks of a project can be summarized in both a tabular or graphical form. A typical template for the tabular representation of a project schedule includes one row per task. Columns correspond to the attributes of the task including the task id, task name, duration, start date, finish date, and the predecessor task(s) if any. A task whose duration is 0 day is called a milestone task. It is used to represent the termination of a phase or a group of tasks in the project schedule.

58. Task network A graphical representation of a project schedule. Composed of nodes and directed arcs joining them. A node represents a task and includes its name and its duration. A directed arc between two nodes represents the dependency of the sink node or task on the completion of the start node or task. The task represented by the sink node cannot start until all the predecessor tasks have successfully terminated. Initial tasks are represented by nodes with no incoming edges. Final tasks are represented by nodes with no outgoing edges.

59. Task network The project length is the duration in days of the longest path in the task network, the length of the project critical path. Given the available resources, including human and other system resources, and the tasks dependencies between the tasks the manager must exploit the concurrent execution of tasks to its fullest. The concurrent execution of tasks leads to better resource utilization and to shorter project length.

60. Example A project schedule table composed of 9 tasks including a milestone task. Task A is the initial task, task H is the final A critical path (CP) on the task network is the longest duration path from start to finish. A task network may have more than one CP all having the same total duration. A task that is included in a CP is called a critical task. Any delay in the completion of a critical task leads to a delay in the project termination.

62. Monitoring CP Closely monitor the progress made on critical paths. For critical tasks, the earliest start date and latest start date are equal. No delays can be afforded on these tasks. Example has 2 CPs in the project schedule – duration is 16 days: A-C-D-F-H-M and A-C-E-G-H-M. Non-critical tasks may have different earliest start and latest start dates without compromising the scheduled project termination date or milestone. The task slack time for a non-critical task is (latest start – earliest start). The slack time represents the flexibility that the manager has in scheduling non-critical tasks. The slack time for a critical task is 0.

64. Example 10.6

65. Earned value analysis Technique for the quantitative assessment and measurement of progress made in a project Percent of project completeness Given an estimate in Person-Months of effort needed for each scheduled task BCWSi – Budgeted Cost of Work Scheduled for Task i is the estimated effort Progress made at time T: sum of all BCWSi of all tasks that should have been completed at time T – BAC Budget at Completion

66. Earned value analysis BCWP – Budgeted Cost of Work Performed at time T BCWP is the sum of the BCWSs for tasks that have been completed at time T ACWP – Actual Cost of Work Performed SPI is the Schedule Performance Index = BCWP/BCWS – Measure of performance BCWP/BAC indicates the percentage of work completed at time T Schedule variance SV = BCWP – BCWS – Negative variance SV means over-budget project

67. Earned value analysis (EVA) EVA can be used to find estimate and variance at the completion of the project given the situation at T and the estimated efforts for the remaining tasks Estimate at Completion – EAC = BAC/CPI – EAC = (BAC – BCWP)/CPI + ACWP Variance at Completion – Projection of the final cost variance of the project – VAC = BAC – EAC Schedule at Completion (SAC) – SAC = BAC/SPI

68. Example 10.7 20 tasks, 200 P-M At T, 6 tasks should have been completed Only 5 were completed BCWS = 67 P-M BCWP = 58 P-M SPI = BCWP/BCWS = 0.91 SV = BCWP – BCWS = -9 % of completeness BCWP/BAC = 29% ACWP = 61.5 CPI = BCWP/ACWP = 0.94 CV = BCWP-ACWP = -3.5 EAC = BAC/CPI = 212 VAC = BAC – EAC = -12 SAC = BAC/SPI = 219

70. IEEE 1058 – the software project management plan (SPMP) document Standard for communicating a software project plan

73. 5. Managerial process plan Project startup: estimation, staffing and HR, training Project work plan: work activities, resource allocation and budget Project control plan: methods and tools to control schedule, budget, quality, reporting and metrics collection Risk management plan: identification, assessment, prioritization, monitoring, controlling, mitigation. Project closeout; analysis of metrics, assessment of success

74. 6. Technical process plan Process model plan – Life cycle model to follow; activities, methods, techniques, tools and deliverables Infrastructure plan – Project development environment – Procedures, policies, standards and facilities needed to operate and maintain the environment Product acceptance plan – Criteria for accepting the product by the client – Tools and methods used to verify these criteria

75. 7. Supporting plans SCM plan (chapter 9) Verification and validation plan Documentation plan Reviews and audit plans Subcontractor management plan Process improvement and metrics collection plans

76. 8. Additional plans Safety plan Installation and deployment plan User training plan Integration plan Conversion and transition plan Maintenance and support plan