software project planning

CHAP:6  software project planning

Software project management begins with a set of activities that are collectively   called project planning.

1.    PROJECT PLANNING OBJECTIVES

The objective of software project planning is to provide a framework that enables the manager to make reasonable estimates of resources, cost, and schedule.

These estimates are made within a limited time frame at the beginning of a software project and should be updated regularly as the project progresses.

The planning objective is achieved through a process of information   discovery that leads to reasonable estimates.

2.    SOFTWARE SCOPE

Software scope describes the data and control to be processed, function,    performance, constraints, interfaces, and reliability.

Functions described in the statement of scope are evaluated and in some cases refined to provide more detail prior to the beginning of estimation. Because both cost and schedule estimates are functionally oriented, some degree of decomposition is often useful.

Performance considerations encompass processing and response time requirements.

Constraints identify limits placed on the software by external hardware, available memory, or other existing systems.

·       Obtaining Information Necessary for Scope:

The most commonly used technique to bridge the communication gap between the customer and developer and to get the communication process started is to conduct a preliminary meeting or interview.

The first meeting between the software engineer (the analyst) and the customer can be likened to the awkwardness of a first date between two adolescents. Neither person knows what to say or ask; both are worried that what they do say will be misinterpreted; both are thinking about where it might lead (both likely have radically different expectations here); both want to get the thing over with; but at the same time, both want it to be a success.

Yet, communication must be initiated. Gause and Weinberg [GAU89] suggest that the analyst start by asking context-free questions; that is, a set of questions that will lead to a basic understanding of the problem, the people who want a solution, the nature of the solution desired, and the effectiveness of the first encounter itself.

The first set of context-free questions focuses on the customer, the overall goals and benefits.

For example, the analyst might ask:

v Who is behind the request for this work?

v Who will use the solution?

v What will be the economic benefit of a successful solution?

v Is there another source for the solution?

The next set of questions enables the analyst to gain a better understanding of the problem and the customer to voice any perceptions about a solution:

v How would you (the customer) characterize "good" output that would be generated by a successful solution?

v What problem(s) will this solution address?

v Can you show me (or describe) the environment in which the solution will be used?

v Will any special performance issues or constraints affect the way the solution is approached?

a number of independent investigators have developed a team-oriented approach to requirements gathering that can be applied to help establish the scope of a project. Called facilitated application specification techniques (FAST).

·       Feasibility:

software feasibility has four solid dimensions:

Technology:-

Is a project technically feasible?

Is it within the state of the art?

Can defects be reduced to a level matching the application’s needs?

Finance:-

Is it financially feasible?

Can development be completed at a cost the software organization, its client, or the market can afford?

Time:-

Will the project’s time-to-market beat the competition?

Resources:-

Does the organization have the resources needed to succeed?

3.    SOFTWARE PROJECT ESTIMATION

Software cost and effort estimation will never be an exact science.

Too many variables— human, technical, environmental, political—can affect the ultimate cost of software and effort applied to develop it. However, software project estimation can be transformed from a black art to a series of systematic steps that provide estimates with acceptable risk.

To achieve reliable cost and effort estimates, a number of options arise:

v Delay estimation until late in the project (obviously, we can achieve 100% accurate estimates after the project is complete!).

v Base estimates on similar projects that have already been completed.

v Use relatively simple decomposition techniques to generate project cost and effort estimates.

v Use one or more empirical models for software cost and effort estimation.

4.    AUTOMATED ESTIMATION TOOLS

Although many automated estimation tools exist, all exhibit the same general characteristics and all perform the following six generic functions [JON96]:

Sizing of project deliverables:-

The “size” of one or more software work products is estimated. Work products include the external representation of software (e.g., screen, reports), the software itself (e.g., KLOC), functionality delivered (e.g., function points), descriptive information (e.g. documents).

Selecting project activities:-

The appropriate process framework is selected and the software engineering task set is specified.

Predicting staffing levels:-

The number of people who will be available to do the work is specified. Because the relationship between people available and work (predicted effort) is highly nonlinear, this is an important input.

Predicting software effort:-

Estimation tools use one or more models that relate the size of the project deliverables to the effort required to produce them.

Predicting software cost:-

Given the results of step 4, costs can be computed by allocating labor rates to the project activities noted in step 2.

Predicting software schedules:-

When effort, staffing level, and project activities are known, a draft schedule can be produced by allocating labor across software engineering activities based on recommended models for effort distribution.

5.    SOFTWARE RISKS

Risk always involves two characteristics:

v Uncertainty—the risk may or may not happen; that is, there are no 100% probable risks.

v Loss—if the risk becomes a reality, unwanted consequences or losses will occur.

When risks are analyzed, it is important to quantify the level of uncertainty and the degree of loss associated with each risk.

Project risks threaten the project plan. That is, if project risks become real, it is likely that project schedule will slip and that costs will increase.

Project risks identify potential budgetary, schedule, personnel (staffing and organization), resource, customer, and requirements problems and their impact on a software project.

Technical risks threaten the quality and timeliness of the software to be produced.

If a technical risk becomes a reality, implementation may become difficult or impossible.

Technical risks identify potential design, implementation, interface, verification, and maintenance problems.

Business risks threaten the viability of the software to be built. Business risks often jeopardize the project or the product.

Candidates for the top five business risks are

v building a excellent product or system that no one really wants (market risk)

v building a product that no longer fits into the overall business strategy for the company (strategic risk)

v building a product that the sales force doesn't understand how to sell

v losing the support of senior management due to a change in focus or

a change in people (management risk)

v losing budgetary or personnel commitment (budget risks).

6.    RISK IDENTIFICATION

Risk identification is a systematic attempt to specify threats to the project plan (estimates, schedule, resource loading, etc.).

There are two distinct types of risks for each of the categories that have been presented in Section software risk: generic risks and product-specific risks.

Generic risks are a potential threat to every software project.

Product-specific risks can be identified only by those with a clear under-standing of the technology, the people, and the environment that is specific to the project at hand.

One method for identifying risks is to create a risk item checklist. The checklist can be used for risk identification and focuses on some subset of known and predictable risks in the following generic subcategories:

v Product size—risks associated with the overall size of the software to be built or modified.

v Business impact—risks associated with constraints imposed by management or the marketplace.

v Customer characteristics—risks associated with the sophistication of the customer and the developer's ability to communicate with the customer in a timely manner.

v Process definition—risks associated with the degree to which the software process has been defined and is followed by the development organization.

v Development environment—risks associated with the availability and quality of the tools to be used to build the product.

v Technology to be built—risks associated with the complexity of the system to be built and the "newness" of the technology that is packaged by the system.

v Staff size and experience—risks associated with the overall technical and project experience of the software engineers who will do the work.

7.    Risk Assessment

At this point in the risk management process, we have established a set of triplets of the form :

[ri, li, xi]

Where ri is risk, li is the likelihood (probability) of the risk, and xi is the impact of the risk.

During risk assessment, we further examine the accuracy of the estimates that were made during risk projection, attempt to rank the risks that have been uncovered, and begin thinking about ways to control and/or avert risks that are likely to occur.

For most software projects, the risk components discussed earlier performance, cost, support, and schedule also represent risk referent levels.

That is, there is a level for performance degradation, cost overrun, support difficulty, or schedule slippage (or any combination of the four) that will cause the project to be terminated.

If a combination of risks create problems that cause one or more of these referent levels to be exceeded, work will stop.

Fig: Risk Reference level

Therefore, during risk assessment, we perform the following steps:

v Define the risk referent levels for the project.

v Attempt to develop a relationship between each (ri, li, xi) and each of the referent levels.

v Predict the set of referent points that define a region of termination, bounded by a curve or areas of uncertainty.

v Try to predict how compound combinations of risks will affect a referent level.

8.    RISK MITIGATION, MONITORING, AND MANAGEMENT

All of the risk analysis activities presented to this point have a single goal to assist the project team in developing a strategy for dealing with risk. An effective strategy must consider three issues:

v risk avoidance

v risk monitoring

v risk management and contingency planning

If a software team adopts a proactive approach to risk, avoidance is always the best strategy. This is achieved by developing a plan for risk mitigation.

For example, assume that high staff turnover is noted as a project risk, r1. Based on past history and management intuition, the likelihood, l1, of high turnover is estimated to be 0.70 and the impact, x1, is projected at level 2.

That is, high turnover will have a critical impact on project cost and schedule.

To mitigate this risk, project management must develop a strategy for reducing turnover.

Among the possible steps to be taken are

v Meet with current staff to determine causes for turnover (e.g., poor working conditions, low pay, competitive job market).

v Mitigate those causes that are under our control before the project starts.

v Once the project commences, assume turnover will occur and develop techniques to ensure continuity when people leave.

v Organize project teams so that information about each development activity is widely dispersed.

v Define documentation standards and establish mechanisms to be sure that documents are developed in a timely manner.

v Conduct peer reviews of all work

v Assign a backup staff member for every critical technologist.  

risk monitoring activities commence. The project manager monitors factors that may provide an indication of whether the risk is becoming more or less likely. In the case of high staff turnover,

the following factors can be monitored:

v General attitude of team members based on project pressures.

v The degree to which the team has jelled.

v Interpersonal relationships among team members.

v Potential problems with compensation and benefits.

v The availability of jobs within the company and outside it.

Risk management and contingency planning assumes that mitigation efforts have failed and that the risk has become a reality.

Continuing the example, the project is well underway and a number of people announce that they will be leaving.

If the mitigation strategy has been followed, backup is available, information is documented, and knowledge has been dispersed across the team.

It is important to note that RMMM steps incur additional project cost.

For example,

spending the time to "backup" every critical technologist costs money. Part of

risk management, therefore, is to evaluate when the benefits accrued by the RMMM steps are outweighed by the costs associated with implementing them.

In essence, the project planner performs a classic cost/benefit analysis. If risk aversion steps for high turnover will increase both project cost and duration by an estimated 15 percent, but the predominant cost factor is "backup," management may decide not to implement this step.

On the other hand, if the risk aversion steps are projected to increase costs by 5 percent and duration by only 3 percent management will likely put all into place.

9.    THE RMMM PLAN

A risk management strategy can be included in the software project plan or the risk management steps can be organized into a separate Risk Mitigation, Monitoring and Management Plan.

The RMMM plan documents all work performed as part of risk analysis and is used by the project manager as part of the overall project plan.

Some software teams do not develop a formal RMMM document. Rather, each risk is documented individually using a risk information sheet (RIS).

In most cases, the RIS is maintained using a database system, so that creation and information entry, priority ordering, searches, and other analysis may be accomplished easily.

Once RMMM has been documented and the project has begun, risk mitigation and monitoring steps commence. As we have already discussed, risk mitigation is a problem avoidance activity.

Risk monitoring is a project tracking activity with three primary objectives:

v To assess whether predicted risks do, in fact, occur

v To ensure that risk aversion steps defined for the risk are being properly applied

v To collect information that can be used for future risk analysis. In many cases, the problems that occur during a project can be traced to more than one risk.

Another job of risk monitoring is to attempt to allocate origin.