Software

Software Project Planning

4 Project Planning NOTES

Chapter Includes :
• Introduction
• Software Project Planning
• Other Planning Activities
• Organisation of the Software Project Management Plan
(SPMP) Document

INTRODUCTION
Effective software project management is crucial for the success of any software
project. There are numerous instances of software projects ending up as failures not
for lack of competent technical professionals or resources but due to the use of faulty
software project management practices. Therefore, it is important to know the latest
techniques in the field of software project management. The main goal of software
project management is to enable a group of software engineers to work efficiently
towards successful completion of a project.
The Project Management Institute defines project management as; “The applications
of knowledge, skills, tools and techniques to project activities in order to meet or
exceed stakeholders’ needs and expectations from a project”. Project management is an
integrative endeavor - an action, or failure to take action, in one area will usually
affect other areas. The interactions may be straightforward and well understood, or
they may be subtle and uncertain. For example, a scope change will almost always
affect project costs, but it may not affect team morale or product quality. These
interactions often require trade-offs among project objectives -performance in one
area may be enhanced only by sacrificing performance in another. Successful project
management requires actively managing these interactions. Many techniques of gen-
eral project management are applicable to software project management, but Brooks
pointed out that the processes and products of software projects have certain char-
acteristics that make them different. One way of perceiving software project manage- 69
ment is to think of it as the process of making something visible, which is invisible.
Software ➤ Invisibility : when a physical artifact such as a road is being built, the progress
Engineering can actually be seen. With software, progress is not immediately visible.
➤ Complexity : Per dollar, pound or euro spent, software products contain
more complexity than other engineering artifacts.
NOTES
➤ Flexibility : The ease with which software can be changed is usually seen as
one of its strengths. However this means that when the software system
interfaces with a physical or organizational system, it is expected that the
software will change to accommodate other components when necessary,
rather than vice versa. This means the software systems are likely to be
subject to a high degree of change.
➤ Standard Process : In other engineering disciplines with a long history, the
processes are tried and tested. Our understanding of software processes has
developed significantly over the past few years. Hence, we still cannot predict
with complete certainty when a particular software process is likely to cause
developmental problems. Software project managers are responsible for plan-
ning and scheduling software development. They supervise the work to ensure
that it is carried out to the required standards and monitor progress to check
the development is on time and within budget.

SOFTWARE PROJECT PLANNING

Software project planning is an integral part of the software project management
activity. Once a project is found to be feasible, software project managers undertake
project planning. Project planning consists of the following important activities:

Defining the problem

➤ Develop a definitive statement of the problem to be solved. Include a de-
scription of the present situation, problem constraints, and a statement of
the goals to be achieved. The problem statement should be phrased in the
customer’s terminology.
➤ Justify a computerized solution strategy for the problem.
➤ Identify the functions to be provided by, and the constraints on, the hard-
ware subsystem, and the people subsystem.
➤ Determine system level goals and requirements for the development process
and the work products.
➤ Establish high-level acceptance criteria for the system.

Developing a Solution strategy

➤ Outline several solution strategies, without regarding for constraints.
➤ Conduct a feasibility study for each strategy.
➤ Recommend a solution strategy, indicating why other strategies were re-
jected.
➤ Develop a list of priorities for product characteristics.

Planning a development processing

70 ➤ Define a life-cycle model and an organizational structure for the project.
➤ Plan the configuration management, quality assurance, and validation activities.
 ➤ Determine phase-dependent tools, techniques, and notations to be used. Software
➤ Establish preliminary cost-estimates for system development. Project Planning
➤ Establish a preliminary development schedule.
➤ Establish preliminary staffing estimates. NOTES
➤ Develop preliminary estimates of the computing resources required to oper-
ate and maintain the system.
➤ Prepare a glossary of terms.
➤ Identify sources of information, and refer to them throughout the project plan.
Effective management of a software project requires thorough planning of its progress.
The project manager must anticipate problems which may arise and prepare tenta-
tive solutions to those problems. A plan drawn up at the start of a project should
be used as a driver for the project. The initial plan is not static but must be modified
as the project progresses and new information becomes available. Project planning is
probably the activity that takes most management time. The planning process starts
with an assessment of the constraints affecting the project. The progress milestones
and deliverables are then defined and a schedule is drawn up. Project managers revise
their assumptions about the project, as more information becomes available. Each
activity is discussed in detail in the following sections.

Defining the Problem

Every man-made entity is first a concept in someone’s mind. Computing systems,
like other products of technology, are developed in response to perceived needs.
Sources of software product ideas include externally generated customer require-
ments, internal organizational requirements, marketing plans, and organizational
mission plans. Most software development organizations are very selective in deciding
which products to develop; not all targets of opportunity are exploited.
The first step in planning a software project is to prepare, in the customer’s -
terminology a concise statement of the problem to be solved and the constraints that
exist for its solution. The definitive problem statement should include a description
of the present situation and the goals to be achieved by the new system.
Note that the customer’s problem, from the customer’s point of view, is perhaps a
payroll problem, an inventory problem, or an air traffic control problem, and not a
problem of DMA channels, sorting algorithms, or relational data bases.
Problem definition requires a thorough understanding of the problem domain and
the problem environment. Techniques for gaining this knowledge include customer
interviews, observation of problem tasks, and actual performance of the tasks by the
planner. The planner must be highly skilled in the techniques of problem definition
because different customer representatives will have different viewpoints, biases, and
prejudices that will influence their perception of the problem area. In addition, Check Your Progress
customer representatives may not be familiar with the capabilities that a computer 1. What is importace
can offer in their situation, and customer representatives are seldom able to formulate effective software
their problems in a manner that yields to logical algorithmic analysis. project management?
2. What is to be consid-
Sometimes, computing systems are built to provide a remedy a symptom rather than ered about start of
for the root cause of a problem. This occurs when the true problem is understood planning process?
but cannot be solved due to economic, political, or social circumstances, or when the
customer is unable to communicate the actual problem, or when the planner fails 71
to understand the customer’s explanation of the problem.
Software The second step in planning a software project is to determine the appropriateness
Engineering of a computerized solution. In addition to being cost-effective, a computerized sys-
tem must be socially and politically acceptable. To be cost effective, a new software
product must provide the same services and information as the old system using less
NOTES time and personnel or it must provide the same services and information that were
impractical without a new system. A system that displaces numerous workers may
be economically and technically feasible, but it may not be socially or politically
acceptable to the customer.
Having determined, at least in preliminary fashion, that a computerized solution to
the problem is appropriate, attention is focused on the roles to be played by the
major subsystems of the computing system. A computing system consists of people
subsystems, hardware subsystems, and software subsystems and the interconnections
among these subsystems. People subsystems include operators for, maintenance per-
sonnel, and end users. Hardware subsystems include the computing hardware and
peripheral devices, and may include other devices such as process control sensors and
actuators or tracking antennas and radars. Software subsystems include the software
to be developed and existing software that may be used “as it is” or in modified form.
The functions to be performed by each major subsystem must be identified, the
interactions among subsystems must be established, and developmental and opera-
tional constraints must be determined for each major subsystem. Constraints specify
numbers and types of equipment, numbers and skill levels of personnel, and software
characteristics such as performance, accuracy, and level of reliability. Precise alloca-
tion of functions among hardware, software, and people may be difficult during
preliminary planning; it may be necessary to first perform some detailed analysis.
Nevertheless, preliminary definition of major subsystem functions should be at-
tempted.

Goals and Requirements

Given a concise statement of the problem and an indication of the constraints that
exist for its solution, preliminary goals and requirements can be formulated. Goals
are targets for achievement, and serve to establish the framework for a software
development project. Goals apply to both the development process and the work
products, and goals can be either qualitative or quantitative.

➤ A qualitative process goal : The development process should enhance the

professional skills of quality assurance personnel.
➤ A quantitative process goal : The system should be delivered within 12
months.
➤ A qualitative product goal : The system should make users’ jobs more
interesting.
➤ A quantitative product goal : The system should reduce the cost of a
transaction by 25 percent.
Some goals apply to every project and every product. For instance, every software
product should be useful, reliable, understandable, and cost-effective. Every develop-
ment process should deliver work products on time and within cost skills. Other
goals, such as transportability, early delivery of subset capabilities, and ease of use by
nonprogrammers, depend on the particular situation.

72 Requirements specify capabilities that a system must provide in order to solve a

problem. Requirements include functional requirements, performance requirements,
and requirements for the hardware, firmware, software, and user interfaces. Require- Software
ments may also specify development standards and quality assurance standards for Project Planning
both project and product. Requirements should be quantified whenever possible.
Quantified requirements such as:
NOTES
➤ Phase accuracy shall be within 0.5 degrees.
➤ Response to external interrupts shall be 0.25 second maximum.
➤ System shall reside in 50K bytes of primary memory, excluding file buffers.
➤ System shall be fully operational 95 percent of each 24 hour period.

can be used as the basis for acceptance testing of the delivered system. Qualitative
requirements such as :
➤ Accuracy shall be sufficient to support mission.
➤ System shall provide real-time response.
➤ System shall make efficient use of primary memory.
➤ System shall be 99 percent reliable.

are often meaningless and can result in misunderstandings and disagreements be-
tween developers and customers. It is difficult to quantify requirements in the plan-
ning phase because usually it is not clear what is needed to solve the problem, or
what can be achieved within the solution constraints. Nevertheless, every effort
should be made to formulate meaningful requirements, and to state the methods
that will be used to verify each requirement.
High-level goals and requirements can often be expressed in terms of quality at-
tributes that the system should posses. These high-level quality attributes can in turn
be expressed in terms of attributes that can be built into the work products. For
example, reliability can be expressed in terms of source-code accuracy, robustness,
completeness, and consistency. Each of these terms can be carefully defined in terms
of more specific attributes of the source code. For instance, accuracy can be defined
as the extent to which the results produced by the code are sufficiently precise to
satisfy their intended usage. This can be translated into specific requirements for any
particular problem. For example, “phase accuracy shall be 0.5 degrees” is an accuracy
requirement that can be used to assess the quality of software in a navigation system.
It is important that high-level acceptance criteria for the system be established
during the planning phase. Lack of clearly stated, quantified acceptance criteria can
lead to serious misunderstandings between customer and developer. Acceptance cri-
teria must be stated in terms that can be verified by well-defined methods such as
inspection, analysis, or tests to be performed on the resulting work products. Each
requirement should include the method that will be used to verify it.
Plans describe the mechanisms to be used in achieving goals and requirements. For
instance, the goal of delivering work products on time can be expressed in terms of
reaching each project milestone on time. A milestone is a significant event in the
software product life cycle; examples of milestones include completion of require-
ments analysis, completion of design, and integration and successful testing of all
system components.
In order to plan for reaching each milestone on schedule, questions such as the
following must be answered:

➤ How many milestones are appropriate? 73

➤ When do they occur?

Software ➤ What resources are required to reach each milestone?
Engineering ➤ Who will be responsible for achieving the milestone?
➤ What must be true to permit achievement of each milestone?
➤ Exactly what will constitute achievement of each milestone?
NOTES
Consideration of these questions will lead into issues such as life-cycle models, cost
estimation, and project staffing levels.

Developing a Solution Strategy

The tendency to adopt the first solution that occurs to us is a major problem in
software engineering. One way of avoiding this problem is to first develop a solution
strategy. A solution strategy is not a detailed solution plan, but rather a general
statement concerning the nature of possible solutions. Strategy factors include con-
siderations such as batch or time-sharing; database or file system; graphics or text;
and real-time or off-line processing. A solution strategy should account for all exter-
nal factors that are visible to the product users, and a strategy should be phrased to
permit alternative approaches to product design.
Several strategies should be considered before one of them is adopted; however, one
or more solution strategies must be chosen by the planners in order to perform
feasibility studies and prepare preliminary cost estimates. The selected strategy pro-
vided a framework for design and implementation of the software product.
Solution strategies should be generated without regard for feasibility because it is not
possible for humans to be both creative and critical at the same time. Typically, an
unreasonable idea will lead to other ideas, some of which may be very reasonable.
Often, the best strategy is a composite of ideas from several different approaches, and
the best solution strategy may become apparent only after all the obvious solutions
have been enumerated. Idea generation is best done by a group of people who have
been trained in the techniques of brainstorming.
The feasibility of each proposed solution strategy can be established by examining
solution constraints. Constraints prescribe the boundaries of the solution space;
feasibility analysis determines whether a proposed strategy is possible within those
boundaries. A solution strategy is feasible if the project goals and requirements can
be satisfied within the constraints if available time, resources, and technology using
that strategy. Some iteration and trade-off decisions may be required to bring feasi-
bility and constraints into balance.
Techniques for determining the feasibility of a solution strategy include case studies,
worst-case analysis, simulation, and construction of prototypes. A prototype differs
from a simulation model in that a prototype incorporates some components of the
actual system. Prototype implementations usually have limited functionality, low
reliability, and poor performance characteristics. Prototypes are constructed during
the planning phase to examine technical issues and to simulate user displays, report
formats, and dialogues. The latter mechanism is particularly valuable for obtaining
a better understanding of the customer’s needs.
When recommending a solution strategy, it is extremely important to document the
reasons for rejecting other strategies. This provides justification for the recommended
strategy, and may prevent ill-considered revisions at some later date.
74 A solution strategy should include a priority list of product features. There are several
important reasons for stating product priorities. At some later time in the develop-
ment cycle it may be necessary to postpone or eliminate some system capabilities due Software
to inconsistencies in the requirements, technical bottlenecks, or time and cost over- Project Planning
runs. At that time, it is essential that high-level guidance be available to indicate the
priorities of essential features, less important features, and “nice if features. Without
this guidance, a designer or programmer may make serious mistakes in judgement, NOTES
resulting in customer dissatisfaction with the delivered product. Product priorities
are also useful to indicate the manner in which capabilities can be developed and
phased into an evolving system. Many software engineers advocate development of
systems as a series of successive enhancements to a kernel system. Product priorities
are useful in planning the successive versions to be built.

Planning development processing

It involves several activities. These are:

➤ Define a life-cycle model and an organizational structure for the project.

➤ Plan the configuration management, quality assurance, and validation activi-
ties.

➤ Determine phase-dependent tools, techniques, and notations to be used.

➤ Establish preliminary cost-estimates for system development.
➤ Establish a preliminary development schedule.
➤ Establish preliminary staffing estimates.
➤ Develop preliminary estimates of the computing resources required to oper-
ate and maintain the system.

➤ Prepare a glossary of terms.

OTHER PALNNING ACTIVITIES

Some of the activities listed above can be considered as other planning activities.

i. Planning for configuration management

It is concerned with controlling changes in work products, accounting for status

of work products, and maintaining the program support library which is central
repository for all project information.

ii. Planning for Quality assurance procedures

These procedures to be used are specified. These are used in requirements phase,
design phase and testing phase. During planning phase these activities should
be planned and adequate resources should be budgeted to permit successful Check Your Progress
quality assurance. 3. What are possible
constituents of com-
iii. Planning for independent verification and validation puting system?
4. What are feasibility
On some critical software projects, an independent organization may provide determining tech-
verification and validation of work products. Verification ensures that various niques?
work products are complete and consistent with respect to other products cus-
tomer needs. Validation is concerned with assessing the quality of the software 75
in its actual quality of software. Validation typically involves planning and
execution of test cases.
Software iv. Project Management Plan
Engineering
After project planning is complete, project managers document the results of the
planning phase in a Software Project Management Plan (SPMP) document
whose general structure is shown below. In addition to recording the software
NOTES
project plan in the SPMP document, project managers usually record a clear
statement of the goals and major decisions taken at this point. Any ambiguity
in the SPMP document may raise several questions in the minds of the team
members who join the group later. For instance, a project, rather than using a
graphical user interface, may implement a command language-based textual
user interface. This enables the software to run on low-cost terminals based on
explicit user request. However, this fact must be explicitly recorded in the SPMP
document. We list below the important items that the SPMP document should
discuss and a possible organization of the SPMP document.

ORGANISATION OF THE SOFTWARE PROJECT MANAGE-

MENT PLAN (SPMP) DOCUMENT
➤ Introduction
(a) Objectives
(b) Major Functions
(c) Performance Issues
(d) Management and Technical Constraint

➤ Project Estimates
(a) Historical Data Used
(b) Estimation Techniques Used
(c) Effort, Resource, Cost, and Project Duration Estimates

➤ Risk Management Plan

(a) Risk Analysis
(b) Risk Identification
(c) Risk Estimation
(d) Risk Abatement Procedures

➤ Schedule
(a) Work Breakdown Structure
(b) Task Network Representation
(c) Gantt Chart Representation
(d) PERT Chart Representation

➤ Project Resources
76 (a) People
 (b) Hardware and Software Software
(c) Special Resources Project Planning

➤ Staff Organization
NOTES
(a) Team Structure
(b) Management Reporting

➤ Project Tracking and Control Plan

➤ Miscellaneous Plans
(a) Process Tailoring
(b) Quality Assurance
(c) Configuration Management
(d) Validation and Verification
(e) System Testing
(f ) Delivery, Installation, and Maintenance

SUMMARY
❑ Effective software project management is crucial for the success of any software
project.
❑ The applications of knowledge, skills, tools and techniques to project activities
in order to meet or exceed stakeholders’ needs and expectations from a project.
❑ Software project planning is an integral part of the software project management
activity. Once a project is found to be feasible, software project managers
undertake project planning.
❑ The planning process starts with an assessment of the constraints affecting the
project.
❑ The second step in planning a software project is to determine the appropriate-
ness of a computerized solution.
❑ A computing system consists of people subsystems, hardware subsystems, and
software subsystems plus the interconnections among subsystems. People sub-
systems include operators for, maintenance personnel, and end users. Hardware
subsystems include the computing hardware and peripheral devices.
❑ Software subsystems include the software to be developed plus existing software
that may be used “as is” or in modified form.
❑ A solution strategy is not a detailed solution plan, but rather a general statement
concerning the nature of possible solutions.
❑ Techniques for determining the feasibility of a solution strategy include case
studies, worst-case analysis, simulation, and construction of prototypes.
77
Software ANSWERS TO "CHECK YOUR PROGRESS"
Engineering
1. Effective software project management is crucial for the success of any software
project.
NOTES 2. The planning process starts with an assessment of the constraints affecting
the project.
3. A computing system consists of people subsystems, hardware subsystems,
and software subsystems plus the interconnections among subsystems. People
subsystems include operators for, maintenance personnel, and end users.
Hardware subsystems include the computing hardware and peripheral de-
vices.
4. Techniques for determining the feasibility of a solution strategy include case
studies, worst-case analysis, simulation, and construction of prototypes.

EXERCISE

1. What do you mean by project management ?

2. What is the role of project management ?
3. What is project planning ?
4. Explain the activities of planning.
5. Write a note on defining the problem.
6. What are the things to be considered while defining the problem ?
7. Explain the activities in developing solution strategy.
8. Explain the activities of planning development processing.
9. Explain other planning activities.

78