Lecture 1

1) Synopsis Project Planning Cost Estimation uncertainties- models-COCOMO model. 2) Target: At the completion of this lecture you should be able to answer questions like (a) What is cost estimation? (b) Explain briefly about COCOMO model. 3) Introduction Now that I have covered about software lifecycle, SRS and other basic software concepts, in this module I will be discussing about project planning. As every activity needs a lot of planning our software development needs a lot of planning. To complete the project successfully, the large workforce has to be properly organized so that the entire workforce is contributing effectively and efficiently. Controlling the development, ensuring quality, satisfying the constraints of the selected process model all require careful management of the project. In this lecture I will explain to you what is cost estimation and the models used for it. We should also have an estimate about the cost to develop the software to satisfy the given requirements, and how much time development it will take. We will discuss about an estimation modelCOCOMO model .In particular we will discuss on the following: (i) Cost Estimation (ii) Uncertainties models (iii)COCOMO model. 4) Revision/Prerequisites Please refer to pages 159 to 170 of your textbook.

Module-2

5) Concepts: Project Planning Software development is a highly labor intensive activity. To complete the project successfully, the large workforce has to be properly organized so that the entire workforce is contributing effectively and efficiently the project. Controlling the development, ensuring quality, satisfying the constraints of the selected process model all require careful management of the project. For a successful project, competent management and technical staff are both essential. We have seen in our previous lectures that project management has three phases basically: project planning, monitoring and control, and termination. Planning may be the most important activity. Without planning, no real monitoring or controlling of the project is possible. Planning may also be perhaps the weakest activity in many software projects, and many failures caused by mismanagement can be attributed to lack of proper planning. The basic goal of planning is to look into the future, identify the activities that need to be done to complete the project successfully, and plan the scheduling and resource allocation for these activities. Economic, political, and personnel factors should be taken into account for a realistic plan and thus for a successful project. The input to the planning activity is the requirements specification. The output of this phase is the project plan, which is a document describing the development process through the remaining fazes .The major issues the project plan addresses are: i) Cost estimation ii) Schedule and milestones iii) Personnel plan iv) Software quality assurance plans v) Configuration management plans vi) Project monitoring plans vii) Risk management

Module-2

Cost Estimation It is desirable to know how much it will cost to develop the software to satisfy the given requirements, and how much time development will take. These estimates are needed before development is initiated the primary reason for cost and schedule estimation is to enable the client or developer to perform a cost-benefit analysis and for project monitoring and control. For a software development project, detailed and accurate cost and schedule estimates are essential prerequisites for managing the project. Cost and schedule estimates are also required to determine the staff leveling for a project during different phases. Cost in a project is due to the requirements for software, hardware, and human resources. The bulk of the cost of software development is due to the human resources needed, and most cost estimation procedures focus on this aspect. Most cost estimates are determined in terms of persons-months (PM). Estimates can be based on subjective opinion of some person or determined through the use of models. Uncertainties in Cost Estimation Cost estimation can be done at any point in the software cycle. As the cost of the project depends on the nature and characteristics of the project, 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 cost can be accurately determined, as all the data about the project and the resources spent can be fully known. On the other extreme when the project is initiated or during feasibility study, there is a great deal of uncertainty about the actual specifications of the system. The cost estimation based on this type of information cannot be accurate. Estimates at this phase of the project can be off by as much as a factor of four from the actual final cost. As we specify the system more fully and accurately, the uncertainties are reduced .More accurate cost estimates can be made then. Despite the limitations, cost estimation models have matured considerably and generally give fairly accurate estimates. Building Cost Estimation Models Any cost estimation model can be viewed as a function that outputs the cost estimate. As the cost of a project depends on the nature of the project, clearly this cost estimation function will need inputs about the project, from which it can produce the estimate. The basic idea of having a model is that it reduces the

Module-2

problem of estimation to estimating the value of the key parameters that characterize the project. The primary factor that controls the cost is the size of the project. Other factors that affect the cost include programmer ability, experience of the developers in the area, complexity of the project and reliability requirements. The goal of a cost model is to determine which of these many parameters have a significant effect on cost and then to discover the relationships between the cost and these characteristics. The most common approach for determining the significant parameters and their relationship to cost is to build models through regression analysis. This approach can be applied only if the process is under statistical control. The most common approach for estimating efforts is to make it a function of a single variable. Often this variable is also the project size, and the equation of effort is considered EFFORT = a * SIZE b , where a and b are constants. A smaller study on smaller projects showed that the data fits a straight line, and the equation is of the form EFFORT =a * SIZE + b, where a and b are again constants obtained by analysis of data of past projects. These models use LOC as the size measure. An advantage of using function points is that the size in Fp can be calculated , while size in LOC will require size estimation be done. COCOMO Model Introduction: The structure of empirical estimation models is a formula, derived from data collected from past software projects, that uses software size to estimate effort. Size, itself, is an estimate, described as either lines of code (LOC) or function points (FP). The typical formula of an estimation model for software development effort is: E = a + b(S)c where: E represents effort, in person months

Module-2

S is the size of the software development, in LOC or FP a, b, and c are values derived from data collected from past projects. No size or effort estimation model is appropriate for all software development environments, development processes, or application types. Models must be customized so that results from the model agree with the data from the particular software development environment. The relationship seen between development effort and software size is generally:

S This graph demonstrates that the amount of effort accelerates as size increases, i.e. the value c in the typical formula above is greater than 1. The original COCOMO model was a set of models; 3 development modes (organic, semi-detached, and embedded) and 3 levels (basic, intermediate, and advanced). COCOMO model levels: Basic - predicted software size (lines of code) was used to estimate development effort.

Module-2

Intermediate - predicted software size (lines of code), plus a set of 15 subjectively assessed 'cost drivers' was used to estimate development effort. Advanced - on top of the intermediate model, the advanced model allows phase-based cost driver adjustments and some adjustments at the module, component, and system level. COCOMO development modes: Organic - relatively small, simple software projects in which small teams with good application experience work to a set of flexible requirements. Embedded - the software project has tight software, hardware and operational constraints. Semi-detached - an intermediate (in size and complexity) software project in which teams with mixed experience levels must meet a mix of rigid and less than rigid requirements.1 COCOMO model: The basic COCOMO model follows the general layout of effort estimation models: E = a(S)b where: E represents effort in person-months S is the size of the software development in KLOC a and b are values, derived from past project data, dependent on the development mode a and b are values are: Organic development mode Embedded development mode a = 2.4 a = 3.6 b = 1.05 b = 1.12 b = 1.20 Semi-detached development mode a = 3.0

The intermediate and advanced COCOMO models incorporate 15 'cost drivers'. These 'drivers' multiply the effort derived for the basic COCOMO model. The importance of each driver is assessed and the corresponding value multiplied into the COCOMO equation, which becomes:
1

Module-2

E = a(S)b x product(cost drivers) Descriptions of COCOMO Cost Drivers:

COST DRIVER PRODUCT COMPUTER PERSONNE L PROJECT 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 Required development schedule

University Questions a. BTech Degree Examination, May 2005,New Scheme-2002 Admission onwards 1. What are the limitations of cost estimation models? (4marks) b. BTech Degree Examination, Nov 2005, New Scheme-2002 Admission onwards 1. Explain the objectives of software project planning? Explain how to achieve these objectives. (12 marks) c. BTech Degree Examination, Nov 2005, New Scheme-2002 Admission onwards

Module-2

1.Explain COCOMO software cost estimation model. (12 marks) 6) Summary: Here, I discussed about project planning and the various cost estimation techniques. Why is cost estimation important? It is important since you should be able to complete the project with the requirements from the user with the specified budget and on the specified date. So for that you should be having a proper plan. For that we will make use of the estimation models. We discussed about COCOMO model. In my next lecture, I will be discussing on Project Scheduling that helps in determining the total duration of the project and the duration of the different phases.

7) Exercise Questions i) The detailed roadmap for a project is the ________ that specifies what specific activities to perform for a particular project, when and how to ensure the project progresses smoothly a. Project roadmap b. System roadmap c. Project plan d. System plan ii) The objective of ------------ is to provide a framework that enables the manager to make reasonable estimates of resources, cost, and schedule a. Project Testing b. Quality Assurance c. Design d. Project Planning iii) COCOMO model is a a. Cost estimation technique b. Size estimation technique c. Quality estimation technique d. None of these

Module-2

iv) COCOMO model is a a. b. c. d. Static single-variable model Static multivariable model Dynamic single-variable model Dynamic multivariable model

Lecture 2
1) Synopsis Project Scheduling-average duration estimation-Project scheduling and milestones 2) Target: At the completion of this lecture you should be able to answer questions like (a) Explain project scheduling. 3) Introduction In my last lecture I had discussed about project planning and various cost estimation models in detail. In this lecture, let us discuss about project scheduling. What is schedule estimation? It helps in determining the total duration of the project and the duration of the different phases. Schedule estimation and staff requirement estimation forms an important activity after cost estimation. We need to prepare schedules. For that we can use Gantt Charts and PERT charts. In particular we will discuss on the following: (i) Project scheduling

Module-2

(ii) (iii)

Average Duration estimation Project Scheduling and Milestones

4) Revision/Prerequisites Please refer to pages 170 to 173 of your textbook. 5) Concepts: Project Scheduling Schedule estimation and staff requirement estimation may be the most important activities after cost estimation. In this lecture, let us discuss about schedule estimation. What is schedule estimation? It helps in determining the total duration of the project and the duration of the different phases. Schedule is independent of the person-month. There is some relationship between the project duration and the total effort required for completing the project. But the relationship is not linear. The basic reason this is that if the staff needs to communicate for the completion of a task, then the communication time should be accounted for communication time increases with the square of the number of staff. Each project will require some time to finish, and this time cannot be reduced by putting more people on the project. Hence project schedule is an independent variable, which must be assessed for planning. Models are used to assess the project duration. Average Duration Estimation Single variable models can be used to determine the overall duration of the project. Schedule is modeled as depending on the total effort. The total duration, M, in calendar months can be estimated by M=4.1E.36 In COCOMO, the schedule is determined in a similar manner. The equation for an organic type of software is M=2.5E.38 For other projects, the constants vary only slightly. The duration or schedule of the different phases is obtained in the same manner as in effort distribution. The percentages for the different phases is given in the following table.

Module-2

Phase

Size Small 2 KDLOC 19 63 18

Intermediate 8 KDLOC 19 59 22

Medium 32 KDLOC 19 55 26

Large 128 KDLOC 19 51 30

Product Design Programming Integration

The percentage of total project duration spent in detailed design, coding and unit testing is somewhat higher than the percentage of total effort spent in these activities. Since the percentages are only slightly different, it means that the average staff sizes computed for the different phases will not be too different from the overall average staff size for the project. Project Scheduling and Milestones Now that we finished with the effort and time requirement for the different phases, a schedule of the project can be prepared. This schedule will be used later to monitor the progress of the project. A conceptually simple and effective scheduling technique is using a Gantt chart. Now what is a Gantt chart? This chart uses a calendar oriented chart to represent the project schedule. Each activity is represented as a bar in the calendar, starting from the starting date of the project. The start and the end of each project become milestones for the project. Now what are the advantages and disadvantages of this method? Progress can be represented easily in a Gantt chart, by ticking off each milestone when completed. The main drawback is that it does not depict the dependency relationships among the different activities. For large project, the dependencies are to be depicted .we make use of PERT charts. It is a graph-based chart, that can be used to determine the activities that form the critical path. It is neither simple nor clear like a Gantt chart. University Questions a. BTech Degree Examination, May 2005, New Scheme-2002 Admission onwards 1. Explain project scheduling. (6 marks)

Module-2

6) Summary: Now that we have completed project scheduling, you must have realized the importance of preparing a schedule. The methods of preparing these schedules have also been discussed. We know that estimating manpower is the most important activity in any company. So in my next lecture I will discuss on staffing and personnel planning. Also Rayleigh curves will be discussed. 6) Exercise Questions i) helps in determining the total duration of the project and the duration of the different phases. a. Schedule Estimation b. System Design c. Cost Estimation d. None of the above ii) A conceptually simple and effective scheduling technique is using a. PERT b. Gantt Chart c. Pie Chart d. None of the above iii) CPM and PERT are a. Automated Estimation Tools b. Object Oriented Modeling Techniques c. Project Scheduling Methods d. Estimation Models iv) Which of the following is used during project estimation ? a. LOC b. LOC , FP c. FP d. None of the above

Module-2

Lecture 3
1)Synopsis Staffing and Personnel Plan-Rayleigh Curve-personnel plan-team structure 2) Target: At the completion of this lecture you should be able to answer questions like

Module-2

(a) How is personnel planning done? (b) What are the different types of team structure? (c) Explain Rayleigh curve. 3) Introduction In my previous lectures, I have discussed about project planning, in brief. In this lecture let us discuss in brief about how personnel planning can be done .Manpower is needed for the proper completion of the project. So you need to estimate manpower. The average staff size can be determined by dividing the total effort by the overall project duration. Also there should be a structure for the staff organization. Either you can follow a uniform horizontal structure or a hierarchical structure. This is known team structure where the team refers to the team working for the project. We will learn on the different types of team structures.I am not going into more details now since by the end of this lecture you will get a better understanding on the topics. In particular we will discuss on the following: (i) (ii) (iii) (iv) Staffing and Personnel Plan Rayleigh Curve Personnel plan Team structure

4) Revision/Prerequisites Please refer to pages 173 to 179 of your textbook. 5) Concepts: Staffing and Personnel Planning Once you have completed with the project schedule, and the effort and schedule of different phases and tasks are known, staff requirements can be obtained. The average staff size can be determined by dividing the total effort by the overall project duration. Now this average staff size is not detailed enough for proper personnel planning, if the variation between the actual staff requirement at different phases is large. Using the COCOMO model average staff requirement for the different phases can be determined as the effort and schedule for each phase are known. This presents staffing as a step function with time.

Module-2

For personnel planning and scheduling, it is useful to have effort and schedule estimates for the subsystems and basic modules in the system .t planning time, the planner can only expect to know about the major subsystems in the system and perhaps the major modules in these subsystems. For small systems, divide the total schedule in terms of the ratio of the sizes of different components .A more accurate method, used in COCOMO, is to start with the sizes of different components .The initial effort for the system is determined. From this normal productivity of the project is calculated by dividing the overall size by the initial effort using this, the effort required for each of the modules is determined by dividing the size by nominal productivity. This gives an initial effort estimate for the modules. For each module the rating of the different cost driver attributes is determined. From these ratings, the effort adjustment factor (EAF) for each module is determined. Using the initial estimates and the EAFs, the final effort estimate of each module is determined. The final effort estimate for the overall system is obtained by adding the final estimates for the different modules. Rayleigh Curve Putnam has proposed a time-dependent continuous function to estimate the staffing at different times throughout the project.The basis of this model is the observation that there are regular patterns of manpower buildup and phaseout,independent of the type of work being performed.The staffing pattern followed Rayleigh curve.

Module-2

if y is the staffing rate in PY/person , then this staffing pattern as a function of time t can be represented by the equation, y = 2 Kate-at2 PY/yr where K is the total manpower required or the total area under the curve from t=0 to infinity. It represents the total person-years used by the project over its entire life cycle. The constant a is the shape parameter, which is determined by the time at which the curve reaches its maximum value. The cumulative manpower used up to time t can be obtained by integrating this equation. Representing the cumulative manpower by y, we have y=K (1- e-at2 ) If y peaks at time td, a=1/2td2 Substituting for a we get, y= (K/td2) te-t2/2td2 Integrating this equation from t=0 to td we get the total development effort D D= y (td) = K (1-e.5) =.39k

Module-2

The total development cost is approximately 40% of the total lifecycle cost.

Personnel plan This plan will specify how many people will be needed for the different activities at different times for the duration of the project. A method of producing the plan is to make the calendar based representation, containing all the months in the duration of the project, by listing the months from the starting date to the ending date. Then, for each of the different tasks for which the cost and schedule estimates are prepared, list the number of people needed in each month. The total effort for each month and for each activity can be computed. Drawing a personnel plan usually requires a few iterations to ensure that the effort requirement for the different phases and activities is consistent with the estimates obtained earlier. A more detailed plan will list the requirements of people by their specialty. Team Structure A team of people is assigned to a project. For the team to work as a cohesive group and contribute the most to the project, the people in the team have to be organized in some manner .the structure of the team has a direct impact on the product quality and project productivity. There are mainly two basic philosophies for organizing the team: Egoless teams-consists of ten or fewer programmers .The goals of the group are set by consensus, and input from every member is taken for major decisions. Group leadership rotates among the group members. These teams are also known as democratic teams.

Module-2

This structure is suited for long-term research type projects. Chief Programmer It has a hierarchy .It consists of a chief programmer, who has a backup programmer, a program librarian, and some programmers. The chief programmer is responsible for all major technical decisions of the project. He does most of the design and assigns coding of the different parts of the design to the programmers. The backup programmer helps the chief programmer make technical decisions, and takes over as the chief programmer during his absence. The librarian maintains documentation and is responsible for other communication related work.

Module-2

A third tem structure called the controlled decentralized team. Tries to combine the strengths of the two team structures. It consists of a project leader who has a group of senior programmers under him, while under each senior programmer is a group of junior programmers. The group of a senior programmer and his junior programmer behaves like an egoless team, but communication among different groups occurs only through the senior programmers of the groups. The senior programmers also communicate with the project leader. Such a team has fewer communication paths than a democratic team but more paths compared to chief programmer team. This structure works best for large projects that are reasonably straightforward. It is not well suited for very simple projects or research type projects.

University Questions a. BTech Degree Examination, May 2005, New Scheme-2002 Admission onwards 1. What is a Rayleigh curve? Explain. (6marks) (BTech Degree Examination, May 2005, New Scheme-2002 Admission onwards) 6) Summary: Staff and personnel planning is one of the important phases in any project. So with proper manpower estimates you will be able to complete the project in time. Afterall our goal is to satisfy the

Module-2

customer giving him the required product, but also at the same time meet the budget and finishing the project at the targeted time. Based on the project you are working on you will choose among the team structures needed. In my next lecture I will discuss about software configuration and quality assurance. Providing high quality product should be our ultimate aim. 7) Exercise Questions i) Rayleigh-Nordon curve is used in which of the following? a. COCOMO Model b. Putnam Estimation Model c. Function Point Model d. None of the above ii) Chief Programmer Hierachy consists of which of these? Chief programmer Backup programmer Librarian All of the above

Lecture 4

Module-2

1)

Synopsis Software configuration management plans-quality assurance plans- verification and validation inspections and reviews 2) Target: At the completion of this lecture you should be able to answer questions like (a) What is SCMP? (b) Explain V&V. (c) What is the need for inspection and reviews? 3) Introduction Till now we have looked about how we will be organizing our project Here we will discuss on SCM plans. The SCM plan has to identify all the activities that must be performed, give guidelines for performing the activities, and allocate resources for them. Now we must also consider about improving the quality of our project. Just as in any filed, quality assurance is important, here also we have various quality assurance strategies. Validation and verification are needed to see if all the requirements are satisfied. So what is the difference between the two? Let us discuss them in our lecture. After a project is completed or at the end of each phase we need to review the project to see if it satisfies the standards. For that a review group need to be formed. So we will discuss about these reviews too. In particular we will discuss on the following: (i) (ii) (iii) (iv) Software configuration Management plans Quality assurance plans Verification and validation Inspections and reviews

4) Revision/Prerequisites Please refer to pages 179 to 189 of your textbook.

Module-2

5) Concepts: Software Configuration Management Plans The SCM plan has to identify all the activities that must be performed, give guidelines for performing the activities, and allocate resources for them. The SCM plan needs to specify the type of SCI s that will be selected and the stages during the project where baselines should be established. The plan has to identify the different members of the configuration control board, the forms to be used for the change requests and fault reporting, and policies, and procedures, and tolls for controlling the changes. An SCM plan should include a plan for configuration accounting and auditing. Quality Assurance Plans To ensure that the final product produced is of high quality, some quality control activities must be performed throughout the development. SQAP specifies all the work products that need to be produced during the project , activities that need to be performed for checking the quality of each of the work products, and the tools and the methods that may be used for the SQA activities. The 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 .These tasks will generally include reviews and audits. Each task should be defined with an entry and exit criterion, that is, the criterion that should be satisfied to terminate the task and the criterion that should be stated so that thy can be evaluated objectively. The documents that should be produced during software development to enhance software quality should also be specified by the SQAP. Verification and Validation (V&V) Verification is the process of determining whether or not the products of a given phase of software development fulfill the specifications established during the previous phase. -Common verification activities include proving, testing, and reviews. Validation is the process of evaluating software at the end of the software development to ensure compliance with the software requirements. -Testing is a common method of validation.

Module-2

For high reliability, we need to perform both activities. Together they are often called V & V activities. The major V & V activities for software development are inspection, reviews, and testing. The two major V&V approaches are testing and inspections. Inspection and Reviews Inspection is an informal technique in which software requirements, design, or code are examined in detail by a person or a group other than the author to detect faults, violations of development standards, and other problems. The purpose of an inspection is to perform a careful scrutiny of the product by peers. In an inspection, in contrast to a walkthrough, the meeting and the procedure are much formal. The inspection of a work product is done by a group of peers, who first inspect the product privately and then get together in a formal meeting to discuss potential defects found by individuals and to detect more defects. There are three reasons for having reviews or inspections: Defect removal Productivity increase Provide information for project monitoring An inspection is done by a group of people that usually includes : -The author or the producer of the product under review. - Reviewers or inspectors are mainly peers not directly responsible for the development concerned with the product. -A moderator guides and controls the inspection activity -A recorder records the results of the inspection Successful implementation of inspections requires a planning phase, an execution phase, and some post-inspection actions. -During planning, first the product is to be inspected to be identified, a moderator is assigned, the objective of the inspection is stated, and the entry criteria that must be satisfied by the product before it can be taken for inspection is specified. -An inspection group is then formed, and an opening meeting is organized by the moderator. In this meeting, the objective of the review is explained, the roles of the different people are specified, of the product

Inspection Process

Module-2

clarifications about the inspection process are given, and the inspection package is distributed to the inspectors. The producer can also give an overview of the product being inspected and background information relating to the construction of the product. -After this, the reviewers individually study the material thoroughly and use the checklists to identify all possible defects. An error log is prepared and submitted to the moderator, who complies the logs of the different reviewers and gives a copy to the producer so that the producer can study the issues raised by the reviewers before the inspection meeting. -Once all the preparation activities are complete, the stage is set for the inspection meeting. The moderator makes sure the preparatory activities are satisfactory. -The meeting begins with the producer discussing each of the issues raised by the reviewers. All the defects are noted. Effort should be made not to suggest methods to remove the defect; that is to be done by the author after the review. -At the conclusion of the meeting, the moderator produces a summary of the inspection , which lists all defects found that need to be addressed .The authors have to address all the issues raised. - The moderator has to ensure that all the issues listed have been satisfactorily addressed. The moderator has to state in the report whether there should be another review after the rework is complete. If no further meeting needs to be convened, then the moderator should ensure that the rework has addressed all issues mentioned in the report. Proper execution of reviews is critical to success. Reviews should be done at defined points during product development, and time must be allocated in the management plans to accommodate review-related activities, particularly the rework Reviews should not be too long.

Module-2

Go

Prepare Review Material

Yes

Distribute material to review team members Review Meeting

A Re no ne vie the ed w r ed ?

No

Resolve Issues Raised in Review

Stop

University Questions a. BTech Degree Examination, Nov 2005, New Scheme-2002 Admission onwards 1. What are the major benefits of reviews? (4marks) (BTech Degree Examination, Nov 2005, New Scheme-2002 Admission onwards) 6) Summary: Like I told you earlier, assuring quality is very important in software product development. Also I think you can differentiate between validation and verification. You must have also realized the need for reviews. Reviews help in identifying and removing errors. Also other people who are involved or not involved in the project will get a clear idea of the project. In my next lecture I will be discussing on project monitoring plans and risk management. 7) Exercise Questions i) Which of the following is a software quality factor? a. b. c. Maintainability Reliability Interoperability

Module-2

d.

All of the above e. Identify management f. Control change g. Ensure that change is being properly implemented h. All of the above

ii) Software Configuration Management activities are developed to

iii) The person who maintains and controls all elements of software configuration a. b. c. Database designer Telecommunications Expert Technical writers d. Software Librarian iv). .is a software configuration management concept that helps us to control change without seriously impeding justifiable change. a. SCI b. System specification c. SRS d. Baselines

Lecture 5
1) Synopsis Project monitoring plans-time sheets reviews-cost schedule-milestone graph-risk management 2) Target: At the completion of this lecture you should be able to answer questions like (a) Discuss the different methods for project monitoring. (b) Write briefly on risk management.

Module-2

3) Introduction In my last lecture I had discussed about reviews and inspection. In this lecture, which will be the concluding lecture to this module I will be discussing on project monitoring. We need to ensure that the project plan is properly executed, and when needed we should be able to modify plans appropriately .For this monitoring activity we make use of various methods like time sheets, reviews and cost schedule milestone graphs .I am not discussing it further now. Risk management is the process of identifying, addressing, and eliminating problems before they can damage the project. Risk management forms an important activity in software engineering. In particular we will discuss on the following: (i) (ii) (iii) (iv) (v) Project monitoring plans Time sheets Reviews Cost schedule-milestone graph Risk management

4) Revision/Prerequisites Please refer to pages 189 to 201 of your text book.

5) Concepts: Project Monitoring Plans The major management activity during the project is to ensure that the plan is properly executed, and when needed, to modify plans appropriately. The project control phase of the management activity is the longest. Proper project monitoring can play a significant role in aiding project management. The

Module-2

methods the management intends to use to monitor the project should be planned before .We will discuss some methods for monitoring a project. i) Time sheets: The management has to track the progress of the project and the expenditure incurred on the project. Progress can be monitored by using the schedule and milestones laid down in the plan. The most common method of keeping track of expenditures is by the use of a time sheet. The time sheet records how much time different project members are spending on the different identified activities in the project. It can be filed daily or weekly .the data obtained from the sheets can be used to obtain information regarding the overall expenditure and its breakup among different tasks and different phases at any given time. ii) Reviews: I have already discussed about reviews in the previous lecture in detail. For monitoring, reviews can provide a large amount of information. First, we can use review schedules can be used to determine how the project is progressing compared to its planned schedule. The review reports indicate in which parts of the project the programmers/analysts are having difficulty and also provide insight into the quality of the software being produced. iii) Cost-Schedule-Milestone Graph: The graph represents the planned cost of different milestones. It shows the actual cost of achieving the milestones gained so far. The progress of the project can be grasped easily. A cost schedule milestone graph is shown below.

Module-2

Risk Management What Is Risk? A simple definition of a "risk" is a problem that could cause some loss or threaten the success of our project, but which hasnt happened yet. These potential problems might have an adverse impact on the cost, schedule, or technical success of the project, the quality of our software products, or project team morale. Risk management is the process of identifying, addressing, and eliminating these potential problems before they can damage our project. Why Manage Risks Formally?

Module-2

A formal risk management process provides a number of benefits to the project team. First, it gives us a structured mechanism to provide visibility into threats to project success. By considering the potential impact of each risk item, we can make sure we focus on controlling the most severe risks first. A team approach allows the various project stakeholders to collaboratively address their shared risks, and to assign responsibility for risk mitigation to the most appropriate individuals. We can combine risk assessment with project estimation to quantify possible schedule slippage if certain risks materialize into problems. Without a formal approach, we cannot ensure that our risk management actions will be initiated in a timely fashion, completed as planned, and effective. The net result of these activities is to help avoid preventable surprises late in the project, and therefore improve the chance of meeting our commitments. The entire development organization also enjoys benefits from risk management. Sharing what does and does not work to control risks across multiple projects helps projects avoid repeating the mistakes of the past. Members of the organization can pool their experience and identify opportunities to control our most common risks, through education, process improvement, and application of improved software engineering and management techniques. Over time, you can build a checklist of risk items and mitigation strategies from multiple projects that can help future projects look for the vipers that might be lurking underfoot. Typical Software Risks Following are several typical risk categories and risk items that may threaten your project Table 1. Most Common Risk Factors for Various Project Types Project Sector Risk Factor Percent of Projects at Risk MIS Creeping user requirements Excessive schedule pressure Low quality Cost overruns 80% 65% 60% 55%

Module-2

Inadequate configuration control Commercial Inadequate user documentation Low user satisfaction Excessive time to market Harmful competitive actions Litigation expense

50% 70% 55% 50% 45% 30%

Dependencies Many risks arise because of dependencies our project has on outside agencies or factors. We cannot usually control these external dependencies, so mitigation strategies may involved contingency plans to acquire a necessary component from a second source, or working with the source of the dependency to maintain good visibility into status and detect any looming problems. Here are some typical dependency-related risk factors:

Customer-furnished items or information Internal and external subcontractor relationships Inter-component or inter-group dependencies Availability of trained, experienced people Reuse from one project to the next

Requirements Issues Many projects face uncertainty and turmoil around the products requirements. While some of this uncertainty is tolerable in the early stages, the threat to success increases if such issues are not resolved as

Module-2

the project progresses. If we dont control requirements-related risk factors, we might either build the wrong product, or build the right product badly. Either situation results in unpleasant surprises and unhappy customers. Become familiar with established requirements gathering and management practices, and watch out for these risk factors:

Lack of clear product vision Lack of agreement on product requirements Unprioritized requirements New market with uncertain needs New applications with uncertain requirements Rapidly changing requirements Ineffective requirements change management process Inadequate impact analysis of requirements changes

Management Issues Although management shortcomings inhibit the success of many projects, dont be surprised if your risk management plan doesnt list very many of these. After all, the project manager is usually the person who is writing the risk management plan, and most people dont wish to air their own weaknesses (assuming they even recognize them) in public. Nonetheless, issues like those listed here can make it harder for projects to succeed. If we dont confront such touchy issues, we shouldnt be surprised if they bite us at some point. Defined project tracking processes, and clear roles and responsibilities, can address some of these risk factors.

Inadequate planning and task identification Inadequate visibility into actual project status Unclear project ownership and decision making Unrealistic commitments made, sometimes for the wrong reasons Managers or customers with unrealistic expectations Staff personality conflicts

Module-2

Poor communication

Lack of Knowledge The rapid rate of change of software technologies, and the increasing shortage of skilled staff, mean that our project teams may not have the skills we need to be successful. The key is to recognize the risk areas early enough so that we can take appropriate preventive actions, such as obtaining training, hiring consultants, and bringing the right people together on the project team. These factors might apply to your team:

Inadequate training Poor understanding of methods, tools, and techniques Inadequate application domain experience New technologies or development methods Ineffective, poorly documented, or neglected processes

Other Risk Categories The list of potential risk areas is long, but were better off knowing our enemy than being surprised. Some other areas you should consider include these:

Unavailability of development or testing equipment and facilities Inability to acquire resources with critical skills Turnover of essential personnel Unachievable performance requirements Problems with language translations and product internationalization Technical approaches that may not work

Risk Management Approaches An organization can select one of five possible approaches to dealing with risks.

Module-2

Risk management is the application of appropriate tools and procedures to contain risk within acceptable limits. Risk management consists of several sub disciplines.

Risk assessment is the process of examining a project and identifying areas of potential risk. Risk identification can be facilitated with the help of a checklist of common risk areas for software projects, or by examining the contents of an organizational database of previously identified risks and mitigation strategies (both successful and unsuccessful).. Risk analysis involves examining how project outcomes might change with modification of risk input variables. Risk prioritization helps the project focus on its most severe risks by assessing the risk exposure. Exposure is the product of the probability of incurring a loss due to the risk and the potential magnitude of that loss.

Risk avoidance is one way to deal with risk: You may avoid risks by not undertaking certain projects, or by relying on proven rather than cutting edge technologies. Risk control is the process of managing risks to achieve the desired outcomes. Risk management planning produces a plan for dealing with each significant risk, including mitigation approaches, owners, and timelines. Risk resolution is execution of the plans for dealing with each risk. Finally, risk monitoring involves tracking your progress toward resolving each risk item.

Keep records of your risk management activities for future reference. 6) Summary: Now finally we have discussed about project monitoring plans and risk management. As I told you in this lecture, project monitoring helps in the management of the project plan. We have discussed various methods used for project monitoring. Risk management is the application of appropriate tools and procedures to contain risk within acceptable limits. This concludes your second module. In my next lecture, I will be introducing you to one of the important phases in the software life cycle, the system design. University Questions a. BTech Degree Examination, May 2005, New Scheme-2002 Admission onwards 1. What is cost-schedule milestone graph? (4marks)

Module-2

2. Explain Project Planning. Process. (8marks) 3. Explain risk control. (4marks) b. BTech Degree Examination, Nov 2005, New Scheme-2002 Admission onwards 1. Explain risk control. (4marks) 7) Exercise Questions i) is the process of identifying, addressing, and eliminating these potential problems before

they can damage a project. a. b. c. d. ii) Project Planning Risk management Project management Testing

is the graph that represents the planned cost of different milestones. a. Cost-Schedule-Milestone Graph b. PERT c. Gantt Chart d. None of the above

iii) a. b. c. d.

is the process of managing risks to achieve the desired outcomes. Risk assessment Risk avoidance Risk identification Risk control

Module-2