1. Unit II Planning and Management of software Projects

2. Topics to be covered Effective project management Effective project management Measures, metrics, and indicators Measures, metrics, and indicators Software process and project metrics Software process and project metrics Metrics for software quality Metrics for software quality Software project planning Software project planning Software project estimation Software project estimation The make/buy decision The make/buy decision Project scheduling and tracking Project scheduling and tracking Task/ work breakdown structure Task/ work breakdown structure Software risk Software risk Project plan Project plan

3. Effective software project management focuses on the four P’s: People, People, Product (Problem), Product (Problem), Process, and Process, and Project. Project.

4. People The most important contributor to a successful software project The most important contributor to a successful software project The Players: The Players: Participate in the software process and the manner in which they are organized to perform effective software engineering. Participate in the software process and the manner in which they are organized to perform effective software engineering. Team Leaders: Team Leaders: The job of the team leader is to organize the project team in a way that maximizes each person’s skills and abilities The job of the team leader is to organize the project team in a way that maximizes each person’s skills and abilities

5. The Players: 1. Senior managers who define the business issues that often have significant influence on the project. 2. Project (technical) managers who must plan, motivate, organize, and control the practitioners who do software work. 3. Practitioners who deliver the technical skills that are necessary to engineer a product or application. 4. Customers who specify the requirements for the software to be engineered and other stakeholders who have a peripheral interest in the outcome. 5. End-users who interact with the software once it is released for production use.

6. Team Leaders: MOI model of leadership Motivation. The ability to encourage (by “push or pull”) technical people to produce to their best ability. Motivation. The ability to encourage (by “push or pull”) technical people to produce to their best ability. Organization. The ability to mold existing processes (or invent new ones) that will enable the initial concept to be translated into a final product. Organization. The ability to mold existing processes (or invent new ones) that will enable the initial concept to be translated into a final product. Ideas or innovation. The ability to encourage people to create and feel creative even when they must work within bounds established for a particular software product or application. Ideas or innovation. The ability to encourage people to create and feel creative even when they must work within bounds established for a particular software product or application.

7. THE PRODUCT Define problem objective Define problem objective Software Scope Software Scope Problem Decomposition: partitioning or problem elaboration Problem Decomposition: partitioning or problem elaboration is applied in two major areas: is applied in two major areas: (1) the functionality that must be delivered and (2) the process that will be used to deliver it.

8. THE PROCESS A Process is a sequence of activities undertaken to achieve some purpose or goal. A Process is a sequence of activities undertaken to achieve some purpose or goal. Processes are the foundations on which to build Project Plans Processes are the foundations on which to build Project Plans Based on the set of common process framework activities. Based on the set of common process framework activities. The project manager must decide which process model is most appropriate The project manager must decide which process model is most appropriate Then process decomposition begins Then process decomposition begins

9. Project Why is the system being developed? Why is the system being developed? What will be done, by when? What will be done, by when? Who is responsible for a function? Who is responsible for a function? Where are they organizationally located? Where are they organizationally located? How will the job be done technically and managerially? How will the job be done technically and managerially? How much of each resource is needed? How much of each resource is needed?

10. Project Prepare PROJECT PLAN Prepare PROJECT PLAN Formal risk management Formal risk management Cost and schedule estimation Cost and schedule estimation Metric-based project management Metric-based project management Project tracking and control Project tracking and control Defect tracking against quality targets Defect tracking against quality targets People-aware program management People-aware program management

11. Software Metrics Measures software productivity and quality Measures software productivity and quality Output as a function of effort and time applied for its production Output as a function of effort and time applied for its production Four reasons for measuring software processes, products, and resources: Four reasons for measuring software processes, products, and resources: To characterize, to evaluate, to predict, or to improve. To characterize, to evaluate, to predict, or to improve.

12. MEASURES, METRICS, AND INDICATORS 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. Measurement is the act of determining a measure. Measurement is the act of determining a measure. An indicator is a metric or combination of metrics that provide insight into the software process, a software project, or the product itself An indicator is a metric or combination of metrics that provide insight into the software process, a software project, or the product itself An indicator provides insight that enables the project manager or software engineers to adjust the process, the project, or the process to make things better. An indicator provides insight that enables the project manager or software engineers to adjust the process, the project, or the process to make things better.

13. SOFTWARE PROCESS AND PROJECT METRICS Process metrics: Process metrics: Measures efficiency of existing process model Measures efficiency of existing process model Private metrics: metrics collected on individual basis Private metrics: metrics collected on individual basis Serve for improvement of individual software engineer Serve for improvement of individual software engineer E.g. defect rates, errors found during development on individual basis E.g. defect rates, errors found during development on individual basis Public metrics: metrics used to measure team performance Public metrics: metrics used to measure team performance Uncover problems to improve team performance Uncover problems to improve team performance E.g. Project level defects rates, effort E.g. Project level defects rates, effort Project metrics: Project metrics: Used to monitor and control progress Used to monitor and control progress Helps in controlling the schedule Helps in controlling the schedule

14. METRICS FOR SOFTWARE QUALITY Correctness: Correctness: It is the degree to which the software performs its required function. It is the degree to which the software performs its required function. Measure for correctness is defects per KLOC Measure for correctness is defects per KLOC Maintainability: Maintainability: Maintainability is the ease with which a program can be corrected if an error is encountered, adapted if its environment changes, or enhanced if the customer desires a change in requirements Maintainability is the ease with which a program can be corrected if an error is encountered, adapted if its environment changes, or enhanced if the customer desires a change in requirements A simple time-oriented metric is mean-time-to change (MTTC) A simple time-oriented metric is mean-time-to change (MTTC)

15. METRICS FOR SOFTWARE QUALITY Integrity: Integrity: This attribute measures a system's ability to withstand attacks (both accidental and intentional) to its security. This attribute measures a system's ability to withstand attacks (both accidental and intentional) to its security. To measure integrity, two attributes must be defined: To measure integrity, two attributes must be defined: Threat is the probability that an attack of a specific type will occur within a given time. Threat is the probability that an attack of a specific type will occur within a given time. Security is the probability that the attack of a specific type will be repelled. Security is the probability that the attack of a specific type will be repelled. The integrity of a system can then be defined as The integrity of a system can then be defined as integrity = summation [(1 – threat) (1 – security)] integrity = summation [(1 – threat) (1 – security)] where threat and security are summed over each type of attack. where threat and security are summed over each type of attack.

16. METRICS FOR SOFTWARE QUALITY Usability: Usability: Refers to the user friendliness of the software and can be measured in terms of 4 characteristics Refers to the user friendliness of the software and can be measured in terms of 4 characteristics (1) the physical and or intellectual skill required to learn the system, (2) the time required to become moderately efficient in the use of the system, (3) the net increase in productivity measured when the system is used by someone who is moderately efficient, and (4) a subjective assessment of users attitudes toward the system.

17. Software quality Conformance to explicitly stated functional and performance requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software.

18. McCall’s quality factors Two categories of software quality factors: Two categories of software quality factors: Factors that can be directly measured (bugs or defects) Factors that can be directly measured (bugs or defects) Factors that can be measured only indirectly (usability or maintainability) Factors that can be measured only indirectly (usability or maintainability) Both sets can (and should) be measured Both sets can (and should) be measured

19. McCall’s quality factors McCall, Richards, and Walters group these factors into three categories, focused on three aspects of a software product: McCall, Richards, and Walters group these factors into three categories, focused on three aspects of a software product: Its operational characteristics Its operational characteristics (PRODUCT OPERATION) Its ability to undergo change Its ability to undergo change (PRODUCT REVISION) Its adaptability to new environments Its adaptability to new environments (PRODUCT TRANSITION)

20. McCall’s quality factors

21. Product Operation Correctness: Correctness: the extent to which a program satisfies its specifications and fulfills the customer’s mission objectives the extent to which a program satisfies its specifications and fulfills the customer’s mission objectives Reliability: Reliability: the extent to which a program can be expected to perform its intended function with required precision the extent to which a program can be expected to perform its intended function with required precision Usability: Usability: the amount of computing resources and code required by the program to perform its function the amount of computing resources and code required by the program to perform its function

22. Product Operation (cont.) Integrity: Integrity: the extent to which access to software or data by unauthorized persons can be controlled the extent to which access to software or data by unauthorized persons can be controlled Efficiency: Efficiency: the effort required to learn, operate, prepare input for, and interpret output of a program the effort required to learn, operate, prepare input for, and interpret output of a program

23. Product Revision Maintainability: Maintainability: the effort required to locate and fix an error in a program the effort required to locate and fix an error in a program Flexibility: Flexibility: the effort required to modify an operational program the effort required to modify an operational program Testability: Testability: the effort required to test a program to ensure that it performs its intended function the effort required to test a program to ensure that it performs its intended function

24. Product Transition Portability: Portability: the effort required to transfer the program from one hardware and/or software system to another the effort required to transfer the program from one hardware and/or software system to another Reusability: Reusability: the extent to which a program (or parts or a program) can be reused in other applications the extent to which a program (or parts or a program) can be reused in other applications Interoperability: Interoperability: the effort required to couple one system to another the effort required to couple one system to another

25. McCall’s quality factors It is difficult (and sometimes impossible) to directly measure all of these quality factors It is difficult (and sometimes impossible) to directly measure all of these quality factors Many of McCall’s metrics can only be measured subjectively Many of McCall’s metrics can only be measured subjectively The metrics may be in the form of a checklist to “grade” attributes of the software The metrics may be in the form of a checklist to “grade” attributes of the software

26. SOFTWARE PROJECT ESTIMATION Software team should estimate the work to be done, the resources that are required and the time required from start to finish Software team should estimate the work to be done, the resources that are required and the time required from start to finish Estimation of resources, cost and schedule for a software engineering requires experience, access to good historical information and courage to commit to quantitative predictions Estimation of resources, cost and schedule for a software engineering requires experience, access to good historical information and courage to commit to quantitative predictions Too many variables can affect the ultimate cost of software and effort applied to develop it Too many variables can affect the ultimate cost of software and effort applied to develop it Human, technical, environmental and political Human, technical, environmental and political

27. SOFTWARE PROJECT ESTIMATION Estimation techniques: Estimation techniques: Decomposition techniques Decomposition techniques Empirical techniques Empirical techniques Decomposition techniques take a "divide and conquer“ approach Decomposition techniques take a "divide and conquer“ approach Decomposing a project into major functions and related software engineering activities, cost and effort estimation can be performed in a stepwise fashion Decomposing a project into major functions and related software engineering activities, cost and effort estimation can be performed in a stepwise fashion Empirical techniques based on historical data Empirical techniques based on historical data

28. Decomposition technique LOC and FP estimation LOC and FP estimation  Define the project scope  Decompose a problem into functions  Compute LOC/ FP for each one of them  Calculate Productivity metrics i.e. LOC/PM or FP/PM  Calculate estimation of cost and effort for the entire project cost in $ and effort in PM (persons- months)

29. An Example of LOC-Based Estimation Consider a software CAD (computer-aided design) application and define project scope (problem definition) Consider a software CAD (computer-aided design) application and define project scope (problem definition) The CAD software will accept two- and three- dimensional geometric data from an engineer. The engineer will interact and control the CAD system through a user interface that will exhibit characteristics of good human/machine interface design. All geometric data and other supporting information will be maintained in a CAD database. Design analysis modules will be developed to produce the required output, which will be displayed on a variety of graphics devices. The software will be designed to control and interact with peripheral devices that include a mouse, digitizer, laser printer, and plotter. The CAD software will accept two- and three- dimensional geometric data from an engineer. The engineer will interact and control the CAD system through a user interface that will exhibit characteristics of good human/machine interface design. All geometric data and other supporting information will be maintained in a CAD database. Design analysis modules will be developed to produce the required output, which will be displayed on a variety of graphics devices. The software will be designed to control and interact with peripheral devices that include a mouse, digitizer, laser printer, and plotter.

30. An Example of LOC-Based Estimation Following major software functions are identified: Following major software functions are identified: User interface and control facilities (UICF) User interface and control facilities (UICF) Two-dimensional geometric analysis (2DGA) Two-dimensional geometric analysis (2DGA) Three-dimensional geometric analysis (3DGA) Three-dimensional geometric analysis (3DGA) Database management (DBM) Database management (DBM) Computer graphics display facilities (CGDF) Computer graphics display facilities (CGDF) Peripheral control function (PCF) Peripheral control function (PCF) Design analysis modules (DAM) Design analysis modules (DAM)

31. An Example of LOC-Based Estimation Ev= (opt+ 4m + pess)/6 Ev= (opt+ 4m + pess)/6 Where opt: optimize Where opt: optimize m: most likely m: most likely pess: pessimistic pess: pessimistic Ev= estimated value of any variable size (LOC) Ev= estimated value of any variable size (LOC) E.g. the range of LOC estimates for the 3D geometric analysis function is optimistic—4600 LOC, most likely— 6900 LOC, and pessimistic—8600 LOC. E.g. the range of LOC estimates for the 3D geometric analysis function is optimistic—4600 LOC, most likely— 6900 LOC, and pessimistic—8600 LOC. Estimated LOC for 3DGA=(4600+4*6900+8600)/6 Estimated LOC for 3DGA=(4600+4*6900+8600)/6 =6800 =6800

32. An Example of LOC-Based Estimation Estimation table for the LOC method

33. An Example of LOC-Based Estimation If average productivity of the organization= 620 LOC/PM Estimated effort=LOC/Productivity = 33200/620 = 33200/620 = 54 PM = 54 PM Assume that cost for developing 1 LOC as 13 $/ LOC Estimated cost=$/LOC* LOC =13*33200 =13*33200 = 431600 $ = 431600 $

34. FP based estimation Info domain characteristicscountComplexity factorTotal No of user inputs *346 No of user outputs *457 No of user inquires *346 No of files *71015 No of external interfaces *5710 Count Totalsimpleaverag e complex

35. An Example of FP-Based Estimation The project planner estimates inputs, outputs, inquiries, files, and external interfaces for the CAD software. The project planner estimates inputs, outputs, inquiries, files, and external interfaces for the CAD software. For the purposes of this estimate, the complexity weighting factor is assumed to be average. For the purposes of this estimate, the complexity weighting factor is assumed to be average.

36. An Example of FP-Based Estimation Each of the complexity weighting factors is estimated and the complexity adjustment factor is computed Each of the complexity weighting factors is estimated and the complexity adjustment factor is computed Factor Value Backup and recovery 4 Data communications 2 Distributed processing 0 Performance critical 4 Existing operating environment 3 On-line data entry 4 Input transaction over multiple screens 5 Master files updated on-line 3 Information domain values complex 5 Internal processing complex 5 Code designed for reuse 4 Conversion/installation in design 3 Multiple installations 5 Application designed for change 5 52

37. An Example of FP-Based Estimation Assign the rating of 0 to 5 according to these values: 0 - factor not present or has no influence 1 - insignificant influence 2 - moderate influence 3 - average influence 4 - significant influence 5 - strong influence (absolutely essential)

38. An Example of FP-Based Estimation Finally, the estimated number of FP is derived: FP estimated = count-total x [0.65 + 0.01 x (Fi)] = 320 x [0.65+0.01 x52] = 320 x [0.65+0.01 x52] Complexity adjustment factor =1.17 FP estimated = 375 FP estimated = 375 The organizational average productivity for systems is 6.5 FP/pm. The cost per FP is approximately $1230. The total estimated project cost is $461,250 and the estimated effort is 58 person-months.

39. Safe home software External Input: password, panic button, activate/deactivate External Input: password, panic button, activate/deactivate External Output: messages, sensors status External Output: messages, sensors status External inquires: zone inquire, sensor inquiry External inquires: zone inquire, sensor inquiry Internal logical files: system configuration file Internal logical files: system configuration file External interface files: test sensor, zone setting, alarm alert, monitoring system External interface files: test sensor, zone setting, alarm alert, monitoring system

40. FP based estimation Factorvalue Back up and recovery4 Data communications2 Distributed processing0 Performance critical4 Online data entry3 Master files updated online2 :: :: :: ( Fi ) i=1 to 1446

41. 41 Function Point Example FP = count total * [0.65 + 0.01 * sum(F i )] FP = count total * [0.65 + 0.01 * sum(F i )] FP = 50 * [0.65 + (0.01 * 46)] FP = 50 * [0.65 + (0.01 * 46)] FP = 55.5 (rounded up to 56) FP = 55.5 (rounded up to 56) Information Weighting Factor Domain ValueCountSimpleAverageComplex External Inputs3 x 3 4 6= 9 External Outputs2 x 4 5 7= 8 External Inquiries2 x 3 4 6= 6 Internal Logical Files1 x 7 10 15= 7 External Interface Files4 x 5 7 10= 20 Count total 50

42. 42 Empirical Estimation Models Uses empirically derived formulas to predict effort as a function of LOC or FP Uses empirically derived formulas to predict effort as a function of LOC or FP The empirical data are derived from a limited sample of projects The empirical data are derived from a limited sample of projects So, no estimation model is appropriate for all classes of s/w and in all development environments So, no estimation model is appropriate for all classes of s/w and in all development environments The results obtained from such models must be used judiciously The results obtained from such models must be used judiciously An estimation model should be calibrated to reflect local conditions An estimation model should be calibrated to reflect local conditions

43. 43 The Structure of Estimation Models Derived using regression analysis on data collected from past s/w projects Derived using regression analysis on data collected from past s/w projects Overall structure, E = A + B  (e v ) c Overall structure, E = A + B  (e v ) c Here, Here, A, B, and C are empirically derived constants A, B, and C are empirically derived constants E is effort in person-months E is effort in person-months e v is the estimation variable (either LOC or FP) e v is the estimation variable (either LOC or FP) Some form of project adjustment component is also used Some form of project adjustment component is also used

44. 44 The Structure of Estimation Models Example of a LOC-oriented estimation model (Bailey-Basili model) Example of a LOC-oriented estimation model (Bailey-Basili model)  E = 5.5 + 0.73  (KLOC) 1.16 Example of a FP-oriented estimation model (Kemerer model) Example of a FP-oriented estimation model (Kemerer model)  E = -37 + 0.96 FP Estimation models must be calibrated for local needs. Estimation models must be calibrated for local needs. E=3.2*(KLOC)^1.05 (Boehm simple model) E=3.2*(KLOC)^1.05 (Boehm simple model)

45. 45 The COCOMO II Model COnstructive COst Model COnstructive COst Model A hierarchy of estimation models A hierarchy of estimation models Addresses the following areas Addresses the following areas Application composition model Application composition model Early design stage model Early design stage model Post-architecture stage model Post-architecture stage model Three different sizing options are available Three different sizing options are available Object points Object points Function points Function points Lines of source code Lines of source code

46. 46 The COCOMO II Model (2) The COCOMO II application composition model uses object points The COCOMO II application composition model uses object points Object point is computed using counts of the number of Object point is computed using counts of the number of Screens (at the user interface) Screens (at the user interface) Reports Reports Components likely to be required to build the application Components likely to be required to build the application

47. 47 The COCOMO II Model (3) Object type Complexity weight SimpleMediumDifficult Screen123 Report258 component10 Figure 23.6: Complexity weighting for object types

48. 48 The COCOMO II Model (4) Developer’s experience/capability Very low LowNominalHigh Very High Environment maturity/capability Very low LowNominalHigh Very High PROD47132550 Figure 23.7: Productivity rate for object points

49. 49 The COCOMO II Model (5) NOP = (object points)  [(100-%reuse)/100] NOP = (object points)  [(100-%reuse)/100] NOP = New Object Points NOP = New Object Points Object Points = Weighted Total Object Points = Weighted Total %reuse = Percent of reuse %reuse = Percent of reuse Estimated effort = NOP/PROD Estimated effort = NOP/PROD PROD = Productivity Rate PROD = Productivity Rate PROD = NOP/person-month PROD = NOP/person-month

50. Assessment of a software system shows that: ●The system includes 6 screens: 2 simple + 3 medium + 1 difficult 3 reports: 2 medium + 1 difficult 2 GL components ● 30 % of the objects could be supplied from previously developed components ● Productivity is high Compute the estimated effort PM ‘Person- months’ needed to develop the system. Object-Point Estimation Example

51. Object counts: 2 simple screens x 1 = 2 3 medium screens x 2 = 6 1 difficult screen x 3 = 3 2 medium reports x 5 = 10 1 difficult report x 8 = 8 2 3GL components x 10 = 20 OP 49 OP Estimation Example: Solution

52. Adjusted NOP ‘New OP’= OP * (1 -% reuse/ 100) = 49 * ( 1-(30/100)) = 49 * ( 1-(30/100)) = (34.3) = (34.3) = 35 = 35 For high productivity (metric table): PROD = 25 OP/P-M Estimated effort Person-Month = Adjusted NOP/ PROD = 35/ 25 = 35/ 25 = 1.4P-M = 1.4P-M

53. 53 The Make/Buy Decision S/W acquisition options S/W acquisition options s/w may be purchased (or licensed) off the shelf s/w may be purchased (or licensed) off the shelf “full-experience” or “partial-experience” s/w components may be acquired and then modified and integrated to meet specific needs “full-experience” or “partial-experience” s/w components may be acquired and then modified and integrated to meet specific needs s/w may be custom built by an outside contractor to meet the purchaser’s specifications s/w may be custom built by an outside contractor to meet the purchaser’s specifications

54. The Make/Buy Decision Make/Buy decision is made based on Make/Buy decision is made based on Will the delivery date of the software product be sooner than that for internally developed software? Will the delivery date of the software product be sooner than that for internally developed software? Will the cost of acquisition plus cost of customization be less than the cost of developing the software internally? Will the cost of acquisition plus cost of customization be less than the cost of developing the software internally? Will the cost of outside support (e.g. maintenance contract) be less than the cost of internal support? Will the cost of outside support (e.g. maintenance contract) be less than the cost of internal support?

55. Creating a Decision Tree Software based system can be Software based system can be Build system from scratch Build system from scratch Reuse existing partial experience components to construct the system Reuse existing partial experience components to construct the system Buy an available software product and modify it to meet local needs Buy an available software product and modify it to meet local needs Contract the software development to an outside vendor Contract the software development to an outside vendor

56. 56 Creating a Decision Tree

57. 57 Creating a Decision Tree (2) The expected value for cost, computed along any branch of the decision tree, is The expected value for cost, computed along any branch of the decision tree, is Expected cost =  (path probability) i  (estimated path cost) i Where, i is the decision tree path Many other criteria must be considered Many other criteria must be considered Availability, experience of the developer/ vendor/ contractor, conformance to requirements, local politics and likelihood of change Availability, experience of the developer/ vendor/ contractor, conformance to requirements, local politics and likelihood of change

58. 58 Outsourcing S/W engineering activities are contracted to a third party who does the work at lower cost and, hopefully, higher quality S/W engineering activities are contracted to a third party who does the work at lower cost and, hopefully, higher quality S/W work conducted within a company is reduced to a contract management activity S/W work conducted within a company is reduced to a contract management activity The decision to outsource can be either strategic or tactical The decision to outsource can be either strategic or tactical Has both merits and demerits Has both merits and demerits

59. PROJECT SCHEDULING Software project scheduling is an activity that distributes estimated effort across the planned project duration by allocating the effort to specific software engineering tasks. Software project scheduling is an activity that distributes estimated effort across the planned project duration by allocating the effort to specific software engineering tasks. The activities that make up the process need to be decomposed further and ‘made concrete’ with descriptions of actual tasks, start dates, finish dates and durations. The activities that make up the process need to be decomposed further and ‘made concrete’ with descriptions of actual tasks, start dates, finish dates and durations.

60. PROJECT SCHEDULING Basic principles guide software project scheduling: Basic principles guide software project scheduling: Compartmentalization. Compartmentalization. Interdependency. Interdependency. Time allocation. Time allocation. Effort validation Effort validation Defined responsibilities Defined responsibilities Defined outcomes. Defined outcomes. Defined milestones: products has been reviewed for quality and has been approved Defined milestones: products has been reviewed for quality and has been approved

61. PROJECT SCHEDULING PROCESS Identify activities: Identify activities: Identify activity dependencies Identify activity dependencies Estimate resources for activities Estimate resources for activities Allocate people to activities Allocate people to activities Create project charts Create project charts

62. Identify activities (Work breakdown structure) Project is divided into major activities. The activities should be neither too small or too long

63. DEPENDENCIES Tasks and sub-tasks have dependencies based on their sequencing - that is, starting one task will depend on the completion of another task.

64. Estimate resources for activities TASK DURATIONS AND DEPENDENCIES

65. Allocate people to activities: Staff allocation Staff allocation is done considering the expertise, task dependencies and staff burden Staff allocation is done considering the expertise, task dependencies and staff burden TaskStaff allocation T01A T02C T03B T04A,B T05C,A T06D

66. Allocate people to activities: Staff allocation

67. Create project charts BAR CHARTS AND ACTIVITY NETWORKS Graphical notations are used to show the project schedule. They show project breakdown into tasks and sub-tasks. Graphical notations are used to show the project schedule. They show project breakdown into tasks and sub-tasks. Activity Charts (Network): show the dependencies between tasks and the ‘Critical Path’. Activity Charts (Network): show the dependencies between tasks and the ‘Critical Path’. Bar Charts: show the schedule of tasks against calendar time. Bar Charts: show the schedule of tasks against calendar time.

68. GANTT CHARTS Gantt charts are bar charts used to track project schedules and progress. Gantt charts provide us with information about durations, criticality. Gantt charts are bar charts used to track project schedules and progress. Gantt charts provide us with information about durations, criticality. They come, essentially, directly from the work breakdown structures. They come, essentially, directly from the work breakdown structures.

69. ACTIVITY BAR CHART

70. ACTIVITY NETWORK OR PERT PERT (Program Evaluation and Review Technique) charts represent the project schedule as an activity network. PERT (Program Evaluation and Review Technique) charts represent the project schedule as an activity network. A Milestone is an event that takes zero time. It is often used to represent the completion of an activity or the delivery of something. A Milestone is an event that takes zero time. It is often used to represent the completion of an activity or the delivery of something. An Activity is part of a project that requires resources and time. An Activity is part of a project that requires resources and time.

71. ACTIVITY NETWORK OR PERT Optimistic time (O): the minimum possible time required to accomplish a task, assuming everything proceeds better than is normally expected. Optimistic time (O): the minimum possible time required to accomplish a task, assuming everything proceeds better than is normally expected. Pessimistic time (P): the maximum possible time required to accomplish a task, assuming everything goes wrong (but excluding major catastrophes). Pessimistic time (P): the maximum possible time required to accomplish a task, assuming everything goes wrong (but excluding major catastrophes). Most likely time (M): the best estimate of the time required to accomplish a task, assuming everything proceeds as normal. Most likely time (M): the best estimate of the time required to accomplish a task, assuming everything proceeds as normal. Expected time (TE): the best estimate of the time required to accomplish a task, assuming everything proceeds as normal Expected time (TE): the best estimate of the time required to accomplish a task, assuming everything proceeds as normal

72. CONSTRUCTING AN ACTIVITY NETWORK Identify Goals, Activities and Milestones; Identify Goals, Activities and Milestones; Determine the dependencies between activities and the sequence of activities to meet goals and achieve milestones Determine the dependencies between activities and the sequence of activities to meet goals and achieve milestones Construct the network diagram; Construct the network diagram; Estimate activity times: Estimate activity times: Optimistic time; Optimistic time; Most likely time Most likely time Pessimistic time. Pessimistic time. Determine the critical path Determine the critical path

73. ACTIVITY NETWORK OR PERT

74. CRITICAL PATHS For each activity we need to estimate: ES – Earliest start time ES – Earliest start time EF – Earliest finish time EF – Earliest finish time LS – Latest start time LS – Latest start time LF – Latest finish time LF – Latest finish time The ‘length’ of each path is calculated by adding up the The ‘length’ of each path is calculated by adding up the optimistic, expected and pessimistic durations of each activity on the path. The LONGEST path in the project is the CRITICAL The LONGEST path in the project is the CRITICALPATH.

75. CRITICAL PATHS Delays on the critical path will delay the project. For the activity network above: For the activity network above: T1 T3 T9 T11 T12 = 55 days ----- CRITCIAL PATH T1 T3 T9 T11 T12 = 55 days ----- CRITCIAL PATH T1 T6 T9 T11 T12 = 45 days T1 T6 T9 T11 T12 = 45 days T1 T7 T10 = 43 days T1 T7 T10 = 43 days T2 T6 T9 T11 T12 = 52 days T2 T6 T9 T11 T12 = 52 days T2 T5 T10 = 40 days T2 T5 T10 = 40 days T4 T8 = 35 days T4 T8 = 35 days

76. Tracking the Schedule Conducting periodic project status meetings in which each team member reports progress and problems. Conducting periodic project status meetings in which each team member reports progress and problems. Evaluating the results of all reviews conducted throughout the software engineering process. Evaluating the results of all reviews conducted throughout the software engineering process. Determining whether formal project milestones have been accomplished by the scheduled date. Determining whether formal project milestones have been accomplished by the scheduled date. Comparing actual start-date to planned start-date for each project task Comparing actual start-date to planned start-date for each project task Meeting informally with practitioners to obtain their subjective assessment of progress to date and problems on the horizon. Meeting informally with practitioners to obtain their subjective assessment of progress to date and problems on the horizon.

77. SOFTWARE RISKS Risk is the probability of failure Risk is the probability of failure Software risk involves two characteristics Software risk involves two characteristics Uncertainty—the risk may or may not happen; that is, there are no 100% probable Risks. Uncertainty—the risk may or may not happen; that is, there are no 100% probable Risks. Loss—if the risk becomes a reality, unwanted consequences or losses will occur. Loss—if the risk becomes a reality, unwanted consequences or losses will occur. Different categories of risks are Different categories of risks are Project risks threaten the project plan. Project risks threaten the project plan. Technical risks threaten the quality and timeliness of the software to be produced. Technical risks threaten the quality and timeliness of the software to be produced. Business risks threaten the feasibility of the software to be built. Business risks often make vulnerable the project or the product. Business risks threaten the feasibility of the software to be built. Business risks often make vulnerable the project or the product. market risk, strategic risk, management risk, budget risks market risk, strategic risk, management risk, budget risks

78. RISK IDENTIFICATION Risk identification is a systematic attempt to specify threats to the project plan (estimates, schedule). Risk identification is a systematic attempt to specify threats to the project plan (estimates, schedule). By identifying known and predictable risks, the project manager take steps toward avoiding them when possible and controlling them when necessary. By identifying known and predictable risks, the project manager take steps toward avoiding them when possible and controlling them when necessary. Generic risks are a potential threat to every software project. Generic risks are a potential threat to every software project. Product-specific risks can be identified only by those with a clear understanding of the technology, the people, and the environment that is specific to the project Product-specific risks can be identified only by those with a clear understanding of the technology, the people, and the environment that is specific to the project

79. RISK IDENTIFICATION The risk item checklist can be used for risk identification The risk item checklist can be used for risk identification Product size Product size Business impact Business impact Customer characteristics Customer characteristics Process definition Process definition Development environment Development environment Technology to be built Technology to be built Staff size and experience Staff size and experience Technical issue Technical issue

80. Risk Components and Drivers Software risk components— Software risk components— Performance risk—the degree of uncertainty that the product will meet its requirements and be fit for its intended use. Performance risk—the degree of uncertainty that the product will meet its requirements and be fit for its intended use. Cost risk—the degree of uncertainty that the project budget will be maintained. Cost risk—the degree of uncertainty that the project budget will be maintained. Support risk—the degree of uncertainty that the resultant software will be easy to correct, adapt, and enhance. Support risk—the degree of uncertainty that the resultant software will be easy to correct, adapt, and enhance. Schedule risk—the degree of uncertainty that the project schedule will be maintained and that the product will be delivered on time. Schedule risk—the degree of uncertainty that the project schedule will be maintained and that the product will be delivered on time. The impact of each risk driver on the risk components— The impact of each risk driver on the risk components— negligible, marginal, critical, or catastrophic. negligible, marginal, critical, or catastrophic.

81. Risk Components and Drivers

82. Risk projection or Risk estimation Developing a Risk Table Impact values: 1 catastrophic 2 critical 3 marginal 4 negligible

83. Developing a Risk Table

85. Risk projection or Risk estimation The table is sorted by probability and by impact. The table is sorted by probability and by impact. first-order risk prioritization: first-order risk prioritization: High-probability, high-impact risks percolate to the top of the table, and low-probability risks drop to the bottom. High-probability, high-impact risks percolate to the top of the table, and low-probability risks drop to the bottom. Defines a cutoff line: Defines a cutoff line: Implies that only risks that lie above the line will be given further attention Implies that only risks that lie above the line will be given further attention All risks that lie above the cutoff line must be managed All risks that lie above the cutoff line must be managed The column labeled RMMM contains a pointer into a Risk Mitigation, Monitoring and Management Plan The column labeled RMMM contains a pointer into a Risk Mitigation, Monitoring and Management Plan

86. Risk projection or Risk estimation The overall risk exposure, RE, is determined using RE = P x C where P is the probability of occurrence for a risk, C is the cost to the project overall cost (impact)=components to be developed x LOCs x cost for each LOC

87. Risk projection or Risk estimation For example: Risk probability: 80% (likely). If 18 components would have to be developed from scratch and the average component is 100 LOC and the software engineering cost for each LOC is $14.00 Solution: The overall cost (impact)= 18 x 100 x 14 = $25,200 Risk exposure. RE = 0.80 x 25,200 ~ $20,200. Risk exposure. RE = 0.80 x 25,200 ~ $20,200.

88. RISK MITIGATION, MONITORING, AND MANAGEMENT An effective strategy must consider three issues: An effective strategy must consider three issues: Risk avoidance Risk avoidance Risk monitoring Risk monitoring Risk management Risk management

89. RISK MITIGATION, MONITORING, AND MANAGEMENT Risk: Computer Crash (1.1) · Mitigation The cost associated with a computer crash resulting in a loss of data is crucial. A computer crash itself is not crucial, but rather the loss of data. A loss of data will result in not being able to deliver the product to the customer. This will result in a not receiving a letter of acceptance from the customer. Without the letter of acceptance, the group will receive a failing grade for the course. As a result the organization is taking steps to make multiple backup copies of the software in development and all documentation associated with it, in multiple locations. · Monitoring When working on the product or documentation, the staff member should always be aware of the stability of the computing environment they’re working in. Any changes in the stability of the environment should be recognized and taken seriously. · Management The lack of a stable-computing environment is extremely hazardous to a software development team. In the event that the computing environment is found unstable, the development team should cease work on that system until the environment is made stable again, or should move to a system that is stable and continue working there.

90. Project plan It provides baseline cost and scheduling information that will be used throughout the software process. It provides baseline cost and scheduling information that will be used throughout the software process. It must It must (1) communicate scope and resources to software management, technical staff, and the customer; (2) define risks and suggest risk aversion techniques; (3) define cost and schedule for management review; (4) provide an overall approach to software development for all people associated with the project; and (5) Outline how quality will be ensured and change will be managed.

91. Project plan Software Project Plan is not a static document. Software Project Plan is not a static document. That is, the project team revisits the plan repeatedly— updating risks, estimates, schedules and related information—as the project proceeds and more is learned. That is, the project team revisits the plan repeatedly— updating risks, estimates, schedules and related information—as the project proceeds and more is learned. Project Plan Template Project Plan Template