Project Management Phases. Initiating Planning Executing Controlling Closing

Transcription

1 Project Management Project Management is the application of knowledge, skills, tools and techniques to the project activities with the aim of meeting or exceeding the stakeholder's requirements.

2 Project Management Phases Initiating Planning Executing Controlling Closing

3 Initiation Includes all those activities which helps in bringing the project formally into existence. Bringing the proposal Validating the proposal Getting the approval Appointing project manager Allocating resources

4 Planning The goal of this phase is to develop a plan for software development following which the objectives of the project can be met successfully and. It decides What work to do When to do it Who will do it How to commit resources

5 Executing & controlling During execution, planned solution is implemented During execution, all activities need to be monitored and if necessary, corrective actions are to be taken to get the project back on track.

6 Closing Closing process brings the project formally to an end Formalizing customer acceptance Settling the bills Archiving the project reports Documenting the lessons learned over the course of the project Celebrating project success

7 Impact of Good Project Management Increases Discipline Productivity Control Improves Estimation Quality Communication You will have a successful project

8 Planning Planning entails all activities that must be performed before starting the development work. During planning all the activities that management needs to perform are planned. The basic goal is to identify the activities that need to be done to complete the project successfully, and plan the scheduling and resources. The inputs to the planning activity are the requirements specification and the architecture description The major issues project planning addresses are: 1. Process planning 2. Effort estimation 3. Schedule and Resource Estimation 4. Quality plans 5. Configuration management plans 6. Risk management 7. Project monitoring plans

9 Process Planning For a project, during planning, a key activity is to plan and specify the process that should be used in the project. This means specifying the various stages in the process, the entry criteria for each stage, the exit criteria, and the verification activities that will be done at the end of the stage. Process planning activity mostly entails selecting a standard process and tailoring it for the project

10 Effort Estimation For a given set of requirements it is desirable to know how much it will cost to develop the software, and how much time the development will take. The Bulk of the Cost involved is Human Resources, then other overheads (H/w, S/w etc.) Effort and schedule estimates are also required to determine the staffing level for a project during different phases. it is generally accepted that it is important to have a more scientific approach to estimation through the use of models.

11 Uncertainties in Effort Estimation At any point, the accuracy of the estimate will depend on the amount of reliable information we have about the final product. when the product is delivered, the effort can be accurately determined, as all the data about the project and the resources spent can be fully known by then. On the other extreme is the point when the project is being initiated. At this time, we have only some idea of the classes of data the system will get and produce and the major functionality of the system. There is a great deal of uncertainty about the actual specifications of the system. Specifications with uncertainty represent a range of possible final products, not one precisely defined product. Estimates at this phase of the project can be off by as much as a factor of four from the actual final effort.

12 Uncertainties in Effort Estimation

13 Uncertainties in Effort Estimation Once the design is complete, the estimates can be made still more accurately. Note that this figure is simply specifying the limitations of effort estimating strategies For actual effort estimation, estimation models or procedures have to be developed. Despite the limitations, estimation models have matured considerably and generally give fairly accurate estimates. For example, when the COCOMO model was checked with data from some projects, it was found that the estimates were within 20% of the actual effort 68% of the time. if the estimate is within 20% of the actual, the effect of this inaccuracy will not even be reflected in the final cost and schedule.

14 Building Effort Estimation Models An estimation model can be viewed as a "function" that outputs the effort estimate. It gets the input from the project specifications. The effort for a project is a function of many parameters, it is generally agreed that the primary factor that controls the effort is the size of the project, that is, the larger the project, the greater the effort requirement. One common approach therefore for estimating effort is to make it a function of project size, and the equation of effort is considered as EFFORT = a * SIZE b where a and b are constants, and project size is generally in KLOC or function points. Values for these constants for a particular process are determined through regression analysis, which is applied to data about the projects that has been performed in the past.

15 Building Effort Estimation Models Top Down Approach Bottom Up Approach

16 Top down Approach. Estimating total effort from the total size is called Top down Approach as overall effort is first determined and then from this the effort for different parts are obtained. In this approach generally we do size estimation first and then effort estimation because size estimation is easier than direct effort estimation. For estimating size, system is divided into components, as it is easy to estimate for small component. After getting the size for all the components, we add the estimates of all the components. Same can not be applied on effort. Good Estimate of size will give good estimate of effort.

17 Bottom Up Approach. The project is first divided into tasks and then estimates for the different tasks of the project are first obtained. The overall estimate of the project is derived from the estimates of its parts. Once the project is partitioned into smaller tasks, it is possible to directly estimate the effort required for them, specially if tasks are relatively small. In Top Down approach required information is size, and in Bottom Up List of Tasks. Most of the time these two approaches are complementary.

18 An Estimation Procedure Identify programs in the system and classify them as simple, medium, or complex (S/M/C) Define the average coding effort for S/M/C Get the total coding effort. Use the effort distribution in similar projects to estimate effort for other tasks and total Refine the estimates based on project specific factors

19 Project Planning Activities Estimation: Effort, cost, resource, and project duration Project scheduling: Staff organization: staffing plans Risk handling: identification, analysis, and abatement procedures Miscellaneous plans: quality assurance plan, configuration management plan, etc.

20 Software Cost Estimation Determine size of the product. From the size estimate, determine the effort needed. From the effort estimate, determine project duration, and cost.

21 Software Project Planning Activities Size estimate Cost estimation Development Time Resource requirements Project Scheduling

22 Software Estimation Approaches Three main approaches to estimation: Empirical Heuristic Analytical

23 Software Estimation Techniques Empirical techniques: an educated guess based on past experience. Heuristic techniques: assume that the characteristics to be estimated can be expressed in terms of some mathematical expression. Analytical techniques: derive the required results starting from certain simple assumptions

24 COCOMO Constructive Cost Model COCOMO is one of the most widely used software cost estimation model introduced by Barry Boehm in 1981 COCOMO predicts the cost, effort and schedule for a software product development based on inputs relating to the size of the software and a number of cost drivers that affect productivity

25 The Development Modes Organic Mode Semidetached Mode Embedded Mode

26 Organic Mode Working to develop well understood application size of the development team is reasonably small developed in a familiar, stable environment, relatively small and requires little innovation Example a payroll system

27 Semidetached Mode intermediate between Organic and Embedded Developers have an intermediate level of experience with related systems Mixture of experienced and inexperienced developers Team can have experience relative only in some project aspects Example interactive banking system

28 Embedded Mode The software is strongly coupled to complex hardware, or real-time systems. Project developed within tight constraints Project on not very known fields The product requires great innovation Example Nuclear Reactor Control System

29 Types of Project

30 Levels of COCOMO Basic Intermediate Complete

31 Basic COCOMO Static single model that computes software development effort (and cost) as a function of program size expressed in estimated thousands of delivered lines of code (KDLOC).

32 Formula Effort = a1 * (KDLOC) a2 PM T dev = b1 * (Effort) b2 Months KDLOC is the estimated size of software product expressed in Kilo Delivered lines of code Tdev is the estimated time to develop the software a1, a2,b1,b2 are constants for each category of product. a1 a2 b1 b2 Software project Organic mode Semidetached mode Embedded mode

33 Example A project size of 32 KLOC is to be developed. Software development team has average experience on similar type of projects. The project schedule is not very tight. Calculate the effort, development time, average staff size of the project.

34 Example - answer Effort = 3.0*(32) 1.12 = 146 PM Schedule = 2.5*(146) 0.35 = 14 months Average Staffing = 146 PM /14 months = 10 FSP

35 Intermediate COCOMO model The intermediate COCOMO is an extension of the basic COCOMO model The Intermediate Model estimates the software development effort by using fifteen cost driver variables besides the size variable used in Basic COCOMO refines the initial estimate obtained using the basic COCOMO expressions by using a set of 15 cost drivers (multipliers) based on various attributes of software development

36 Cost Drivers COST DRIVE R RELY DATA CPLX TIME STOR VIRT TURN ACAP AEXP PCAP VEXP LEXP MODP TOOL SCED DESCRIPTION Required software reliability Database size Product complexity Execution time constraints Main storage constraints Virtual machine volatility- degree to which the operating system changes Computer turn around time Analyst capability Application experience Programmer capability Virtual machine (i.e. operating system) experience Programming language experience Use of modern programming practices Use of software tools e.g. CASE tools Required development schedule

37 COCOMO Cost Drivers Rating COST DRIVER RATING v.low low nominal high v.high ex. high (Product) RELY DATA CPLX (Computer) TIME STOR VIRT TURN (Personnel) ACAP AEXP PCAP VEXP LEXP (Project) MODP TOOL SCED

38 Formula E = Enom * EAF, EAF = RELY * DATA * CPLX * TIME * STOR * VIRT * TURN * ACAP * AEXP * PCAP * VEXP * LEXP * MODP * TOOL * SCED The coefficients a, b, c and d are given below : a1 a2 b1 b2 Software project Organic mode Semidetached mode Embedded mode

39 Complete COCOMO Detailed Model uses the same equations for estimations as the Intermediate Model Cost of each sub-system is estimated separately. Costs of the sub-systems are added to obtain total cost. Reduces the margin of error in the final estimate.

40 Example A Management Information System (MIS) for an organization having offices at several places across the country: Database part (semi-detached) Graphical User Interface (GUI) part (organic) Communication part (embedded) Costs of the components are estimated separately: summed up to give the overall cost of the system.

41 Steps in using COCOMO model Identify the mode of development for the new project. Estimate the size of the project in KDSI to derive a nominal effort prediction. Adjust the 15 cost drivers to reflect your project, producing an effort adjustment factor. Calculate the predicted project effort using equation 1 and the effort adjustment factor. Calculate the project duration using equation 2.

42 Project Scheduling A project Schedule is at two levels - overall schedule and detailed schedule Overall schedule comprises of major milestones and final date Detailed schedule is the assignment of lowest level tasks to resources

43 Overall Schedule Depends heavily on the effort estimate For an effort estimate, some flexibility exists depending on resources assigned Eg a 56 PM project can be done in 8 months (7 people) or 7 months (8 people) Stretching a schedule is easy; compressing is hard and expensive

44 Overall Scheduling... One method is to estimate schedule S (in months) as a function of effort in PMs Can determine the fn through analysis of past data; the function is non linear Schedule =23.46 (Effort) COCOMO: S = 2.5 (Effort) 3.8 Often this schedule is checked and corrected for the specific project One checking method square root check

45 square root check the proposed schedule can be around the square root of the total effort in person months For example, if the effort estimate is 50 personmonths, a schedule of about 7 to 8 months will be suitable

46 Schedule (Days) Determining Overall Schedule from past data Effort in person-days

47 Determining Milestones With effort and overall schedule decided, avg project resources are fixed Manpower ramp-up in a project decides the milestones Manpower ramp-up in a project follows a Rayleigh curve - like a normal curve In reality manpower build-up is a step function

48 Manpower Ramp-up PTS Design Build Test

49 Milestones... With manpower ramp-up and effort distribution, milestones can be decided Effort distribution and schedule distribution in phases are different Generally, the build has larger effort but not correspondingly large schedule

50 An Example Schedule # Task Dur. (days) Work (pdays) Start Date End Date 2 Project Init tasks /4 6/23 74 Training /8 9/ Knowledge sharing /2 9/ Elaboration iteration I /15 6/ Construction iteration I /10 7/21

51 Detailed Scheduling To reach a milestone, many tasks have to be performed Lowest level tasks - those that can be done by a person (in less than 2-3 days) Scheduling - decide the tasks, assign them while preserving high-level schedule Is an iterative task - if cannot fit all tasks, must revisit high level schedule

52 Detailed Scheduling Detailed schedule not done completely in the start - it evolves Can use MS Project for keeping it Detailed Schedule is the most live document for managing the project Any activity to be done must get reflected in the detailed schedule

53 An example task in detail schedule Module Act Code Task Duration Effort History PUT Unit test # 17 1 day 7 hrs St. date End date %comp Depend. Resource 7/18 7/18 0% Nil SB

54 .Project Scheduling.. The scheduling process Identify activities Identify activity dependencies Estimate resources for activities Allocate people to activities Create project charts Software requirements Activity charts and bar charts

55 ..Project Scheduling. Graphical notations used in software project scheduling: Tables: summary description of tasks Bar charts: show schedule against the time Activity charts: graphs that depict dependencies between tasks and indicate the critical path (the longest path in the activity graph)

56 Project Scheduling Example of tabular description [Fig. 5.5, SE-7]: Task Duration (days) Dependencies T1 8 T2 15 T3 15 T1 (M1) T4 10 T5 10 T2, T4 (M2) T6 5 T1, T2 (M3) T7 20 T1 (M1) T8 25 T4 (M5) T9 15 T3, T6 (M4) T10 15 T5, T7 (M7) T11 7 T9 (M6) T12 10 T11 (M8)

57 Activity Network: An Example Design database 45 Code database 60 RAS 15 Design GUI 30 Code GUI 45 Integrate and Test 60 Document 5 User Manual and Documentation 90

58 .Project Scheduling.. Example of activity chart 14/7 /03 15 da ys 8 da ys M1 T3 T1 5 da ys 25/7 /03 4/7 /03 T6 M3 star t 15 da ys 20 da ys T2 T7 10 da ys 25/7 /03 10 da ys T4 M2 T5 18/7 /03 M5 4/8/03 M4 11/8/03 M7 15 da ys T9 25/8/03 M6 7 da ys T11 5/9/03 M8 15 da ys T10 10 da ys T12 25 da ys T8 19/9/03 Finish

59 ..Project Scheduling. Example of bar chart 4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9 T4 T1 T2 Start M1 T7 T3 M5 T8 M3 M2 T6 T5 T9 M4 M7 T10 T11 T12 M6 M8 Finish

60 Project Scheduling Staff allocation chart 4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9 Fred Jane Anne Jim Mary T4 T1 T2 T3 T7 T8 T6 T5 T9 T10 T11 T12

61 Work breakdown structure (WBS) Hierarchical decomposition of a project into subtasks Shows how tasks are decomposed into subtasks Does not show duration Does not show precedence relations (e.g. task A must be finished before task B can start)

62 Project Scheduling Identify all the activities needed to complete the project Determine the dependency among different activities Estimate the duration required to complete each activity Prepare the schedule using activity dependencies, activity duration and available resources as input Allocate resources to activities Plan the starting and ending dates for various activities Determine the critical path. A critical path is the chain of activities that determine the duration of the project

63 Methods of Scheduling Work Breakdown Structure (WBS) Activity Network and Critical Path Method (CPM) Gantt Charts Program Evaluation and Review Technique (PERT) charts

64 Work Breakdown Structure (WBS) WBS is used to decompose a given task set recursively into smaller tasks It provides a notation to represent major tasks needed to be carried out in order to develop a project The WBS is basically a tree structure (just like a directory in Unix OS) The depth of the tree is decided by the project size Any activity that is at the lowest level should not be less than two week effort

65 Work breakdown structure (WBS) Hierarchical decomposition of a project into subtasks Shows how tasks are decomposed into subtasks Does not show duration Does not show precedence relations (e.g. task A must be finished before task B can start)

66 Activity Network and Critical Path Method (AN/CPM) WBS does not show any interdependencies among the activity An AN incorporates the following Different activities making up the project Interdependencies among the activities shows precedence relations Estimated duration of each activity Parallel activities etc.

67 Activity Network: An Example Design database 45 Code database 60 RAS 15 Design GUI 30 Code GUI 45 Integrate and Test 60 Document 5 User Manual and Documentation 90

68 Critical Path Method (CPM) CPM chart can answer the following:? Minimum time (MT) to complete the project? The earliest start (ES) time of a task? The latest start (LS) time to start a task? The earliest finish (EF) time of a task? The latest finish (LF) time of a task? Flexibility (slack time (ST) ) of a task? Critical tasks and Critical path

69 PERT Charts Consists of network of tasks and their dependencies CPM is with normal distribution (single estimate) PERT is with statistical distribution (three estimates) Each task is annotated with optimistic, likely and pessimistic time of completion

70 PERT Charts Design database 30, 45, 60 Code database 45, 60, 90 RAS 15 Design GUI 15, 30, 45 Code GUI 30, 45, 60 Integrate and Test 45, 60, 75 Finish 0 User Manual and Documentation 60, 90, 120

71 PERT charts PERT chart (Program Evaluation and Review Technique) A network (graph) where the nodes represent tasks and arrows describe precedence relations Shows task duration (on the task node) Shows precedence relations Generally does not show task decomposition

72 Gantt Charts Gantt chart (Henry Gantt) is a special bar chart to represent activities and resources (staff, hardware and software) allocation Duration is along the horizontal axis Activities (in the form of a bar) is along vertical axis

73 Gantt charts A graphical visualization of a schedule, where the time span for each activity is depicted by the length of a segment drawn on an adjacent calendar Generally does not show task decomposition Does not show duration, only the time span over which the task is scheduled Does not show precedence relations Can show activity of multiple developers in parallel Makes it easy to monitor a project s progress and expenditures

74 Activity and Milestone Activity is a part of the project that takes place over a period of time. Milestone is the completion of an activity - - a particular point in time. Describe each activity precursor duration due date endpoint

75 Staffing Level Estimation After estimating the effort required for our project, our next step is to estimate the required staffing level Norden work Putnam work Staffing: the number of personnel required during the project Is not constant 75

76 Norden s Work Norden studied the staffing patterns of several R&D projects He noted that the staffing pattern can be approximated by a Rayleigh distribution curve Norden s represented this distribution using the following equation: E t K d 2 t e 2 t d Where E is the effort required at time t, K is the area under the curve, t d is the time the curve attains its maximum value t

77 Norden s Work Rayleigh Curve 77

78 Putnam s Work Norden s work is for general R&D projects; it was not meant to be used for software development projects Putnam s studied the work of Norden, and determined that we can use the curve to relate the number of lines of code to the time and effort required by the project 78

79 Putnam s Work Putnam s derived the following expression L C K is the total effort (in PM) L is the product size in KLOC 1 3 k K t d t d corresponds to the time of system and integration testing. Therefore, t d can be approximately considered as the time required to develop the software

80 Putnam s Work C k is the state of technology constant and reflects constraints that impede the progress of the programmer Typical values of C k = 2 for poor development environment (no methodology, poor documentation, and review, etc.) C k = 8 for good software development environment (software engineering principles are adhered to) C k = 11 for an excellent environment (in addition to following software engineering principles, automated tools and techniques are used) The exact value of C k for a specific project can be computed from the historical data of the organization developing it 80

81 Putnam s Work Putnam suggested that we should follow the Rayleigh curve Start with small number of personnel As the project progress add extra personnel as needed Once the development is done (by the end of the unit testing), the personnel number starts to decrease The project personnel build up should not be carried in large installments 81

82 Putnam s Work Increasing the personnel staff in large installments may cause schedule slippage Fixed number of personnel will result in wasted efforts, and increase the time and effort (cost) required to finish the project Results of overstaffing and understaffing From Rayleigh curve we can see that Almost 40% is to the left of the t d Almost 60% is to the right of t d Putnam-Norden-Rayleigh curve is also called PNR Curve 82

83 Effect of Schedule Change on Cost Back to Putnam s equation: or K 3 4 K since C is a constant for the same product size C L 3 C k t d C ( t d L ( Ck 4 ) 3 ) 3 83

84 Effect of Schedule Change on Cost To compare two projects: K1 K 2 ( t ( t d 2 d1 ) ) 4 4 When the schedule of the project is compressed the required effort increases in proportion to the fourth power if the degree of compression 84

85 Effect of Schedule Change on Cost This means that a small compression in delivery schedule can result in substantial penalty on human effort Reduce project time from one year to 6 months then the total effort required increases 16 times It is very difficult to keep the extra hired engineers occupied with work, parallel activities are restricted 85

86 Effect of Schedule Change on Cost Benefits can be gained by using fewer people over a somewhat longer time span to accomplish the same objective Extreme penalties for schedule compression Extreme rewards for schedule expansion But, increasing the development time beyond some optimal time increases the total effort rather than decrease it Boehm states that if project manager want to compress the project more than 25%, the project is unlikely to succeed 86

87 Team structure Problems of different complexities and sizes require different team structures: Chief-programmer team Democratic team Mixed organization

88 Democratic Team Basic underlying concept egoless programming

89 Democratic Team (contd..) Consist of ten or fewer programmer Does not enforce any formal team hierarchy All programmers are on one level Group leadership rotates among group members All decisions are based on team consensus

90 Advantages Democratic organization provides higher morale and job satisfaction to the engineers therefore leads to less employee turnover. Encourages egoless programming as programmers can share and review one another s work Suitable for: small projects requiring less than five or six engineers less understood problems research-oriented projects

91 Disadvantages Team members may waste a lot time arguing about trivial points due to lack of any authority in team to resolve such debates

92 Chief Programmer Team A senior engineer provides leadership: technical partitions the task among the team members. verifies and integrates the products developed by the members.

93 Advantages Well suited for projects with simple solutions and strict deadlines Faster decisions

94 Disadvantages subject to single point failure Leads to lower team morale

95 Controlled Decentralized Team Combined the strength of democratic as well as chief programmer teams Decentralize the decision-making process where appropriate

96 Software Configuration Management IEEE defines SCM as the process of identifying and defining the items in the system, controlling the change of these items throughout their lifecycle, recording and reporting the status of items and change requests, and verifying the completeness and correctness of items

97 SCM Terminology Configuration Item (CI) Any development output for which change control is considered necessary. A configuration item is a document or artifact explicitly placed under configuration control Examples: Management plan Requirement Design specification Source code and executable code Test specification, data, and records Log information User documentation Library and supporting software Bug reports, etc.

98 SCM Terminology (contd..) Baseline A collection of configuration item(s) which is reviewed and approved, and thus under change control often a project milestone. IEEE Definition for Baseline a specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures

99 Baseline Refers to a set of configuration items which together depict a product at a specific point of time Configuration of a software at discrete points in time is a baseline A baseline is a set of CI that has been formally reviewed and agreed upon. Each baseline serves as a point of departure or reference for next development stage Each baseline is subject to configuration control and must be formally updated to reflect approved changes

100 SCM Terminology (contd..) Revision a change to a baseline Configuration a particular assembly of configuration items (such as the all the source code files for release 3.0) Version- a configuration adding repair or new functionality Variant a configuration with similar functionality on a different platform Release a version or variant distributed to users.

101 The configuration database All CM information should be maintained in a configuration database This should allow queries about configurations to be answered Who has a particular system version? What platform is required for a particular version? What versions are affected by a change to component X? How many reported faults in version T? The CM database should preferably be linked to the software being managed

102 CM Mechanisms modified SCIs Project database Software engineering tasks SCIs Formal technical reviews approved SCIs stored SCIs SCM controls extracted SCIs BASELINES: System Specification Software Requirements Design Specification Source Code Test Plans/Procedures/Data Operational System

103 The SCM process How does an organization identify and manage the many existing versions of a program (and its documentation) in a manner that will enable change to be accommodated efficiently? How does an organization control changes before and after software is released to a customer? Who has responsibility for approving and prioritizing changes? How can we assure that changes have been made properly? What mechanism is used to appraise others of changes that are made? these questions lead to the definition of 5 SCM tasks

104 SCM tasks Identification Version control Change control Configuration auditing Status reporting

105 Configuration Identification The configuration identification process involves the selection, designation, and description of the software configuration items. Selection involves the grouping of software into configuration items that are subject to configuration management. Designation is the development of a numbering and/or naming scheme that correlates the software components and their associated documentation. Description is the documentation of functional, performance, and physical characteristics for each of the software components.

106 Configuration item identification Large projects typically produce thousands of documents which must be uniquely identified Some of these documents must be maintained for the lifetime of the software Document naming scheme should be defined so that related documents have related names. A hierarchical scheme with multi-level names is probably the most flexible approach

107 Version control combines procedures and tools to manage different versions of configuration objects that are created during the SE process allows user to specify alternative configurations of the software system through the selection of appropriate versions This is supported by associating attributes with each software version and then allowing a configuration to be specified (and constructed) by describing a set of desired attributes Versions and variants

108 Version Control A version control system implements or is directly integrated with four major capabilities: a project database (repository) that stores all relevant configuration objects a version management capability that stores all versions of a configuration object (or enables any version to be constructed using differences from past versions); a make facility that enables the software engineer to collect all relevant configuration objects and construct a specific version of the software. an issues tracking (also called bug tracking) capability that enables the team to record and track the status of all outstanding issues associated with each configuration object.

109 Change Control Change control is the process of evaluating, coordinating, and deciding on the disposition of proposed changes to the configuration items, and for implementing approved changes to baselined software and associated documentation. The change control process ensures that changes which have been initiated are classified and evaluated, approved or disapproved, and that those approved are implemented, documented, and verified.

110 The change management process Request change by completing a change request form Analyze change request if change is valid then Assess how change might be implemented Assess change cost Submit request to change control board if change is accepted then repeat make changes to software submit changed software for quality approval until software quality is adequate create new system version else reject change request else reject change request

111 Change Control Process Submission of Change Request (CR) Technical and business evaluation and impact analysis Approval by Change Control Board (CCB) Engineering Change Order (ECO) is generated stating changes to be made criteria for reviewing the changed CI CI s checked out Changes made and reviewed CI s checked in

112 Configuration audit Configuration audits verify that the configuration identification for a configured item is accurate, complete, and will meet specified program needs. Audit should periodically be performed to ensure that the SCM practices and procedures are rigorously followed

113 Configuration Status Reporting (CSR) Configuration status accounting is the process used to trace changes to the software. It ensures that status is recorded, monitored, and reported on both pending and completed actions affecting software baselines. This process also defines the current as-built status of the code and associated documentation. a SCM task that answers these questions What happened? Who did it? When did it happen? What else will be affected?

114 Versions/variants/releases Version An instance of a system which is functionally distinct in some way from other system instances Variant An instance of a system which is functionally identical but non-functionally distinct from other instances of a system Release An instance of a system which is distributed to users outside of the development team

115 The CM plan Identify configuration item Define a naming scheme for the configuration items Define the directory structure needed for CM Define version management procedures and methods for tracking changes to configuration items Define access restrictions Define change control procedures Identify and define responsibility of the CC Identify points at which baselines will be created Define a backup procedure, if needed Define a release procedure

116 Quality Assurance Plans To ensure that final product is of high quality SQAP specifies the tasks that need to be undertaken at different times in the life cycle to improve the software quality and how they are to be managed

117 Quality Management To ensure that the final product is of high quality, some quality control activities must be performed throughout the development The task of quality management is to plan suitable quality control activities and then to properly execute and control them so the projects quality goals are achieved.

118 Verification and Validation Verification Are we building the product right? determine whether or not the products of a given phase of software development fulfill the specifications established during the previous phase Validation Are we building the right product? The software should do what the user really requires

119 V&V approaches Inspection static Testing - dynamic

120 Software Inspection Concerned with analysis of the static system representation to discover problems (static verification)

121 Testing Concerned with execution and observing product behavior (dynamic verification) The system is executed with test data and its operational behavior is observed

122 Software Inspection Inspection is a review of a software work product by a group of peers following a clearly defined process. Involves people examining the source representation with the aim of discovering anomalies and defects. IEEE defines inspection as a formal evaluation technique in which software requirement, design or code are examined in detail by a person or a group other than the author to detect faults, violation of development standards and other problems.

123 Reasons for having inspection Finding defects Productivity increase Provide information for project monitoring

124 Inspection Roles Author or Owner Inspector Reader Recorder Moderator

125 Procedure Planning Overview Preparation Inspection meeting Rework Follow-up

126

127 Approaches to Quality Management Reviews and testing are the two most common QC activities. Ad hoc - some testing, some reviews done as and when needed Procedural - defined procedures are followed in a project Quantitative - defect data analysis done to manage the quality process

128 Procedural Approach A quality plan defines what QC tasks will be undertaken and when Main QC tasks - reviews and testing Guidelines and procedures for reviews and testing activities are planned During project execution, they are carried out according to the defined procedures

129 Quantitative Approach Goes beyond asking has the procedure been executed Analyzes defect data to make judgements about quality Past data is very important Key parameters - defect injection and removal rates, defect removal efficiency (DRE)

130 Quality Plan The quality plan drives the quality activities in the project Specifies the quality control tasks that will be performed in the project

131 Project Monitoring Plans

132 Background A plan is a mere document that can guide It must be executed To ensure execution goes as per plan, it must be monitored and controlled Monitoring requires measurements And methods for interpreting them Monitoring plan has to plan for all the tasks related to monitoring

133 Measurements Must plan for measurements in a project Without planning, measurements will not be done Main measurements effort, size, schedule, and defects Effort as this is the main resource; often tracked through effort reporting tools Defects as they determine quality; often defect logging and tracking systems used During planning what will be measured, how, tool support, and data management

134 Project Tracking Goal: To get visibility in project execution so corrective actions can be taken when needed to ensure project succeeds Diff types of monitoring done at projects; measurements provide data for it

135 Tracking Activity-level monitoring Each activity in detailed schedule has been done properly and within time Often done daily by managers A task done marked 100%; tools can determine status of higher level tasks Status reports Prepared weekly to take stock of what has happened and what needs to be done. Summary of activities completed, pending Issues to be resolved and if everything is in place for the next week

136 Tracking Milestone analysis A bigger review at milestones Actual vs estimated for effort and scheduled is done Risks are revisited Changes to product and their impact may be analyzed Cost-schedule milestone graph is another way of doing this

137 Cost-schedule milestone graph

138 Risk Management

139 Risk A project risk is any unanticipated event, which if they occur will have an unexpected usually negative impact on the project objective

140 Risk Management Risk management include activities that are undertaken to reduce the impact of risk on cost, quality and schedule. Software risk management is the formal process in which risk factors are systematically identified, assessed and mitigated

141 Boehm s Project Risk Management Model

142 Risk Management Activities risk assessment, consisting of identification of those risks likely to cause problems analysis to determine the loss probability and loss magnitude for each risk and to develop a compound risk prioritization to rank the identified risk items according to their compound risks risk control, consisting of management planning to bring the risk items under control resolution to eliminate or resolve the risk items monitoring to track the project's risk reduction progress and to apply corrective action where necess

143 Top Ten List of Risk Items 1. Personnel shortfalls 2. Unrealistic schedules and budgets 3. Developing the wrong software functions 4. Developing the wrong user interface 5. Gold plating (cost overrun) 6. Continuing stream of requirements changes 7. Shortfalls in externally (other groups or co.) performed tasks 8. Shortfalls in externally furnished components 9. Real-time performance shortfalls 10. Straining computer science capabilities

144 Risk Exposure Risk exposure (impact/factor) RE = P(UO) L(UO) RE: risk exposure UO: unsatisfactory outcome P(UO): probability of UO L(UO): loss due to UO

145 Table 1. Boehm s Top Ten Risk Items 1.Personnel Shortfalls: Staffing with top talent; job matching; team-building; morale-building; cross-training; pre-scheduling key people. 2.Unrealistic Schedules and Budgets: Detailed, multi-source cost and schedule estimation; design to cost; incremental development; software reuse; requirements scrubbing. 3.Developing the wrong software functions: Organizational analysis; mission analysis; operational concept formulation; user surveys; prototyping; early users manuals. 4.Developing the wrong user interface: Prototyping; scenarios; task analysis. 5.Gold-plating. Requirements scrubbing: prototyping; cost-benefit analysis; design to cost. 6.Continuing stream of requirements changes: High change threshold; information-hiding; incremental development (defer changes to later increments). 7.Shortfalls in externally-performed tasks: Reference-checking; pre-award audits; award-fee contracts; competitive design or prototyping; team-building. 8.Shortfalls in externally-furnished components: Benchmarking; inspections; reference checking; compatibility analysis. 9.Real-time performance shortfalls: Simulation; benchmarking; modelling; prototyping; instrumentation; tuning. 10.Straining computer science capabilities: Technical analysis; cost-benefit analysis; prototyping; reference checking.

146 Project Monitoring Plans A plan is a mere document that can guide It must be executed To ensure execution goes as per plan, it must be monitored and controlled Monitoring requires measurements And methods for interpreting them Monitoring plan has to plan for all the tasks related to monitoring

147 Cost-schedule milestone graph