ZeePedia buy college essays online

Software Project Management

<<< Previous Life cycle Models: Spiral Model, Statement of Requirement, Data Item Descriptions Next >>>
Software Project Management (CS615)
Life cycle Models
To ensure the successful execution of a project, it is necessary to break down the
project into: multiple manageable tasks.
Each task is performed in a series using processes. To understand what a process
is, consider an example of a non software-related project. You are planning the
market launch of an office management product. To create an effective plan, you
need to perform certain tasks.
First, you schedule a meeting of all managers and the Finance, Marketing,
Production, and Systems personnel. You can follow a process to complete
this 'task. You may send email messages or call them up personally.
Next, you decide some feasible marketing and advertising strategies.
Again there are processes that help you select the strategies.
Fina1ly, you determine the territory where the product should be launched.
This is done in consultation with the Production and Marketing
Just like a non software-related project plan consists of multiple processes, a
software development activity also consists of multiple tasks. A process or a
combination of multiple processes is required to complete each task. A typical
SDLC follows a consistent sequence of processes or a process model.
A process is defined as a collection of related tasks with specific milestones. To
ensure smooth progress of a software project, relevant processes are arranged and
executed in a sequence. Every software project is discrete with respect to its
complexity, size, and goals. Therefore, different process models are designed for
different software projects. These process models provide approaches that decide
the path of software development from the conceptualization of a project to its
formal termination.
1. The Waterfall model: This is the traditional life cycle model. It assumes that
all phases in a software project are carried out sequentially and that each
phase is completed before the next is taken up.
2. The Prototyping Model: A model that works on an iterative cycle of
gathering customer requirements, producing a prototype based on the
requirement specifications, and getting the prototype validated by the
Software Project Management (CS615)
customer. Each iteration of the life cycle builds on the prototype produced in
the previous iteration.
3. The Incremental Model: The Incremental model is an example of an
evolutionary life cycle model. It combines the linear nature of the Waterfall
model and the iterative nature of the Prototyping model. The Incremental
model divided the development life cycle into multiple linear sequences, each
of which produces an increment of the final software product. In this model,
the software product is developed in builds. A build is defined as a self-
contained unit of the development activity. The entire development cycle is
planned for a specific number of logical builds, each having a specific set of
4. The Spiral model: Another evolutionary life cycle model that combines the
linear nature of the Waterfall model and the iterative nature of the Prototyping
model. The project life cycle is divided into phases, and each phase is
executed in all of the iteration of the Spiral Model.
5. The RAD Model:
A Process defines the overall processes that an organization needs to follow to
manage a project efficiently. It defines a structured approach to sequence the
phases and identify the requirements of each phase in the SDLC. The definition of
the phases in a process model helps organize, monitor, and execute a project
A process model is flexible and does not follow any rigid rules of implementation.
An organization can deploy a totally new process model for its overall software
development effort. It can also customize an existing process model to merge with
its implemented process model. For example, figure 1, shows two process models,
A and B. Process model A was used by an organization that manufactures
confidential defense applications. The management used the model to plan
extensively for unexpected project risks. However, after discussing with the
project managers and system analysts, the organization wants to merge its current
process model with a model lat has simple and consistent SDLC phases. This
leads to the evolution of the process model B.
Software Project Management (CS615)
Process Model A
Process Model B
Figure: Customizing Process Models
Choosing the lifecycle model
In choosing a lifecycle model for your project, you should examine:
1. How well requirements are understood at the beginning? Is it going to
change when moving through the project?
2. Is system architecture understood? Any changes on the way?
3. Level of reliability?
4. Level of re-design for future versions?
5. Risk Level?
6. Stuck With Predefined Schedule?
7. Need For Midcourse Correction?
8. Customer Informed through the Project?
9. Visible Management through the Project?
10. If a Model is chosen, how much it needs Modification?
Selecting an appropriate process model is crucial because it can provide a basic
framework to initiate and carry out a project to its conclusion. It also defines the path for
various project- related activities.
For example, if you select a process model, you know for sure that you need to carry out
certain activities, such as planning, scheduling, resource allocation, risk management, and
cost and effort estimation. These activities ensure smooth progress of a project within the
Software Project Management (CS615)
allocated time and ensure maintenance of quality and measurability throughout the
With so many process models available, a project manager is likely to face the dilemma
of selecting the right process model for managing a software project efficiently.
To select a process model that is suitable to a project, the following criteria can be
Business goals of the organization
Expected size of the project
Client and project requirements
Availability of funds and development staff
Risks perceived in the project
Business Goals of the Organization
This criterion indicates the overall approach and mindset of an organization. If the
organization has a past history of developiI;1g projects in accordance with well-defined
plans and other job aids in every phase, the suitable process model can be the Waterfall
model. However, if the organization is well equipped with the resources to deal with
financial, technological, and personnel risks, it can choose the Spiral model. The
organization can choose the Prototyping model if it is used to working in an experimental
and a constant feedback mode.
Expected Size of the Project
If the size of a project is extensive and the client prefers all the features of the proposed
project at the first delivery, you can select the Waterfall model. When you want the entire
product to be developed and delivered in piecemeal so that the clieI;1t can immediately
begin the unit testing of each module, you would select the Incremental model. In
contrast, if the size of the project is doubtful, you can go for the Prototyping or Spiral
model. These models help to develop projects that have a vague and uncertain estimate of
the project size.
Client and Project Requirements
The Waterfall model or the Incremental model is chosen if the client needs and the
project requirements are defined and approved. In addition, no changes or negligible
changes are 1 expected in the future regarding design requirements. In contrast, you
would choose the Spiral j and Prototyping models when the client needs and system
requirements are uncertain and is likely to change in the future.
Availability of Funds and Development Staff
The Waterfall and Prototyping models require predetermined and adequate resources at
the start of a project. However, if you expect additional funds and human resources as
you progress through the different phases, you should go in for the Incremental or Spiral
models. This is because the Incremental model operates on the assumption of developing
a project into several builds due to lack of human resources. Similarly, the funds and
Software Project Management (CS615)
staffing requirements in the Spiral model may increase or decrease depending on the
changes in requirements arid feasibility of the proposed project in the future.
Risks Perceived in a Project
This is yet another important criterion for the selection of a process model. You choose
the Waterfall or Incremental model if the occurrence of risks and their impact perceived
is minimum. However, you should go in for the Spiral model if the risks and their
perceived impact are very high.
You should use the waterfall model if:
The project is large yet it is clearly divided into discrete phases and each phase
has defined number of days, personnel, and resources allocated. The Waterfall
model requires the presence of defined phases and processes in each phase.
The development also perceives that it can have defined set of input and certified
output. This is because each phase would lead to another and the next phase
would not begin until the previous phase is certified as closed. This way baselines
and milestones for each phase can be identified. The Waterfall model assumes the
closure of a previous phase before the successive phase begins. This ensures
linear progression of a project where developers do not need to revert to an earlier
phase or a process.
The development team is not likely to face any bumps in the development process
because of clear cut project requirements as well documentation provided to them
by the client. Clarity of project vision and project requirements are the essential
features of the Waterfall model, which are fulfilled in the preceding scenario.
Therefore, if the requirements are defined and a project is large enough to be divided into
defined phases, you can go for the Waterfall model.
However Waterfall model has the following drawbacks:
There cannot be a sudden crossover from one phase to the next. Real-time projects
require sudden crossover between phases because such projects are subjected to
change in every phase of the development cycle. For example, real-time projects such
as embedded software development where the phases and the requirements for every
phase cannot be determined at the analysis phase cannot deploy the Waterfall model.
Another reason for the unpopularity of the Waterfall model is that it requires too
much effort for stringent documentation-in every phase. Every phase is closed with
formal documentation. Projects with predictable final product, such as banking
software or an airline reservation project, usually have formal documentation. This is
because the phases of these projects are defined. However, it is difficult for research
and development (R&D) related projects to complete all project documentation.
The Waterfall model does not support the development of a working model of a
Software Project Management (CS615)
project first and then further development based on client feedback. Absence of a
working model prevents you from detecting an issue in an early phase. As a result,
you incur higher expenditure in rectifying the issue in a later phase. This in turn has
an adverse effect on the effort, cost, and time spent on rework.
Finally, the Waterfall model causes, as a "blocking state". When a blocking state
occurs, some team members wait for other team members to finish a dependent task.
For example, in the following figure, the team member assigned to do the design task
cannot begin work until the analysis is complete. This delays the turnaround of the
software project. Many times, the blocking state wastes a lot of developers' time that
could have been spent on productive project -related work.
Figure: Idle Team Members in the Phases of the Waterfall Model
Implementation &
You should use Prototyping model when:
The client is not clear about the requirements of the proposed system or
Software Project Management (CS615)
When there is a conflict in client requirements.
To resolve the conflict, the development team develops a working model so that the
requirements of the client become defined. Defined client requirements enable the
physical development of the actual product.
The Prototyping model enables an analysis team to first construct a working model with
their prior software experience combined with the vague needs of the client.
The Prototyping model can be as simple as a drawing on a paper or as complex as the real
working software. The closer your prototype is to the actual product, the more precise is
your evaluation.
There are different types of prototyping methods that an organization can implement:
Rapid prototyping
Reusable prototyping
Modular prototyping
Rapid prototyping
This model is suitable when:
The cost and time required to create a prototype is minimal.
The project has a substantially long cycle
Development team wants the design to be strong.
Reusable prototyping
This model is used when:
The old design needs major changes but the supplementary components of the old
design do not need major changes.
Modular prototyping
This model is used when:
Considerable cost, time and effort are deployed to create a prototype.
Client feedback for enhancements is not major
Minor improvisations are needed to obtain client approval.
Using the Prototyping model saves cost and time involved in the build-it-twice approach.
The experience of developing the prototype is useful for developers while developing the
final product. It reduces the risks of an unfeasible project design because the developers
gain a fair idea of the resources and the probable time taken to create the [mal product.
They also get a feel of the implementation tool to be used in the project.
Incremental Model
Software Project Management (CS615)
You can use the Incremental model approach in software projects:
Where human resource is scarce.
In such cases, the management can decide to divide and develop a product in individual
builds. When the resources are available, the subsequent builds are planned and executed.
This process model is useful in real life because normally all the resources required to
complete the project are not available at the same time.
Consider a situation in which you might need to use the Incremental model of SDLC.
Supersoft2000 requires a software product that automates the employee and their salary
details. It has assigned this project to Blue Valley Consulting (BVC) that specializes in
developing Human Resources (HR)-related applications. The project requirements are
defined to start the project. However, the client wants to roll out the new system for the
benefit of its employees as early as possible. The analysis team in BVC has been able to
divide the entire project into seven independent modules. On the basis of their prior
experience, it feels each module can be executed and deployed independently by the
client. After all the modules are completed, the maintenance team in BVC can assemble
and implement the system at the client site. Currently, the development personnel in BVC
are hired on contract and BVC faces shortage of skilled personnel.
In such a case, you use the Incremental model because of the following reasons:
Time and lack of skilled personnel are the main hindrances in this project.
Therefore, by using the Incremental model, you can design, develop, and deliver
independent modules. This way by using a few skilled personnel you are able to develop
a system with basic features and provide it to the client immediately. The most important
and the least dependent module are developed first. While the client is using the module,
BVC can arrange for additional skilled personnel to complete the rest of the modules and
deliver them to the client.
The Incremental model enables you to revert to an earlier phase and refine the product
based on client feedback. After all the modules have been developed, the development
personnel can be released. BVC can then hire or retain a few experienced personnel to
create a maintenance team. This team would assemble and implement the entire
employee salary details product at the client site. This flexibility of personnel can be
exercised because you use the Incremental model. Using the Incremental model enables:
Division of skilled labor
Division of a complex project into modules
Development of those modules within a short time frame
Software Project Management (CS615)
Therefore, if time and skilled personnel are constraints of a Project, you can effectively
use the Incremental model.
Spiral Model
The basic goal of using the Spiral model is to define ways of eliminating risks in the
design phase. Consequently, minimum and manageable risks percolate into the
development phase.
LMN Inc. has acquired a project to develop a telecommunications project using the
Voice-over Internet telephony (VOIP) technology. The company does not have any prior
experience or the required level of expertise to develop such a project. There is a team of
three analysts and the company does not propose to dedicate a team to complete this
project. This is because it anticipates many risks and a large amount of rework that may
add to the cost of project execution. The company has determined multiple models and
designs to execute the project. After presenting the models to the client, the client is itself
confused. However, it assures LMN Inc. of continued feedback and support. The client
fully understands the ambitiousness of the project and does not consider time and budget
as constraints for the project. Consequently, LMN Inc. decides to use the client feedback
and risk analysis effectively until the end of the project.
In this situation, you would use the Spiral model because of the following reasons:
LMN Inc. has no prior experience or expertise in executing such a project.
Therefore, it expects a lot of rework in reverting to an earlier phase and
incorporating client feedback therein. Using the Spiral model, you can to revert to
an earlier phase to incorporate client feedback and compete that phase.
It needs to perform risk analysis effectively to eliminate losses arising due to
uncertain development models, resource requirements, project constraints, and
It is also preferable to create a prototype for every deliverable that LMN Inc.
might deem necessary to receive client feedback.
Spiraling cumulative project costs can be covered up by the liberal budget
provided by the client.
Planning Documents
You (the PM) need to choose which documents are appropriate. Documents do not have
to be lengthy.
The requirements phase produces one main product document:
The software requirements specification document
And two Project Planning Documents:
Software Project Management (CS615)
1. The Project Development Plan
·  The Software Test Plan
The requirements phase formally concludes with the project's first major review: the
software requirements review (SRR). It is this review that signs off the requirements
specification and formally declares the requirements document as the first approved
project baseline.
2. The Statement of Requirement (SOR)
The project manager (or the advising consultant adopting this role) must ensure
that the project sponsor has produced a written statement of requirements (SOR).
This must be a thorough document which is:
Fully defined or complete
Verifiable deliverables
No conflicts
The SOR will be the document against which change control will be exercised.
The SOR should be closely matched to the contract and there should be no
conflict of interests between the two. Where consultants are involved, the client or
sponsor SOR will normally form the basis of the proposal. All of these documents
must carefully align and there should be no scope for misinterpretation, confusion
or lack of understanding. This will be the cornerstone of the project.
3. System Specification
If a System Specification has been properly developed, nearly all information
required for a description of software scope is available and documented before
software project planning begins. In cases where a specification has not been
developed, the planner must take on the role of system analyst to determine
attributes and bounds that will influence estimation tasks.
4. Design Specification
The first stage of risk analysis requires a review of all, project technical and
administrative plans in order to identity potential problems. It includes:
The project development plan
The requirements specification
The design specification
Software Project Management (CS615)
All major dependencies in the project development plan are examined and
Examples may be the dependence on external sources such as subcontractors,
vendors and suppliers, and service providers. Problems will arise if external
components or services are not provided on time, or if they do not function as
The project design specification is a detailed plan of how the requirements are to
be implemented.
The implementation decisions involved may contain potential problems, For
example, problems will arise if the selected hardware turns out to be inadequate,
such as if the CPU is too slow, the LAN is not sufficiently reliable, or the
maximum available memory is insufficient.
A list of all anticipated problems is then compiled, identifying each problem and
describing the potential effect on the project. Following table presents an example
of an anticipated problem list.
Table 1: Example of an anticipated problem list
1. Late delivery of the
If the computer is not delivered by June 1, as
Development computer
planned the integration phase will be delayed.
2. Insufficient memory
The size of the memory resident part of the
System may exceed 8 megabytes (the maximum
memory size supported by the computer).
3. No operating system
The system requires changes to the standard expert
operating system. John Adams is the only OS
Expert in the company, and he may not be available
for this project.
4. System response time
The required system response time to the
too slow.
may exceed the 5 seconds specified in the
5. High staff turnover
The schedule is tight with only minimal slack
time. If there is more than average staff
Replacement during development, we will slip the
Software Project Management (CS615)
6. Communication
The standard communications package is too
too slow
slow. The design is based on the new binary
Communication package. This package has never
Been used with this system and may not be suitable.
7. Late delivery of the
The data based subsystem is subcontracted to
Data base subsystem
Software Developer Inc. (SDI), who have
Committed to delivery by April 15, SDI may not
Deliver on time, thus delaying the final integration
and test phase.
The anticipated problem list should be compiled with the participation of the
principle members of the project development team. Other people may also be
invited to contribute to the list, based on their experience and technical or
administrative knowledge. This might include people from other project teams,
support groups, the company's legal department or the purchasing department.
While the objective is not to list every conceivable problem that any project may
experience, it is necessary to identify those problems that should reasonably be
considered in relation to the project. In any event, the following analysis stage is
designed to isolate only those problems that could have significant impact on the
project, and that can reasonably be expected to appear.
5. The Data Item Descriptions (DID s)
Standard 2168 (DOD 1988b) contains the requirements for the development,
documentation and implementation of a software quality program. The software
quality program includes planning for and conducting:
Evaluations of the quality of software
Associated documentation and related activities
Follow-up activities necessary to assure timely and effective resolution of
The DID s are a comprehensive set of documentation standards that cover all
phases of software development, maintenance and the production of user
reference manuals. The DID s include a section called preparation instructions
that provide a large degree of freedom by permitting tailoring of the document
format and the use of alternate presentation styles. The full set of DID s is
described in Table 2.
Standard 2167 states that it is not intended to specify or discourage the use of any
particular software development method (DOD 1988a). However, as mentioned
previously, the standard is heavily inclined toward phased development
methodologies, such as the Waterfall paradigm. The phased approach is inherent
Software Project Management (CS615)
in the required development stages and reviews, requiring system design to be
followed by software requirements, software design, implementation and testing.
The Data Item Descriptions define the formal documentation standards for all
required documents generated during the development of software according to
standard 2167. DID s apply to the development of one or more computer system
configuration items (CSCI s), a term used throughout the 2167 standard to
identify high level decomposition components of a computer system.
Table 2: DOD Data Item Descriptions (DID s)
Development documentation
·  Software development plan
System documentation
·  System/segment specification
·  System/segment design document
Software design and requirements
·  Software requirements specification
·  Software design document
Interface design and requirements
·  Interface requirements, specification
·  Interface design document
Version description
·  Version description document
Test documentation
·  Software test plan
·  Software test description
·  Test report
Release manuals
·  Computer system operator's manual
·  Software user's manual
·  Software programmer's manual
·  Firmware support manual
Maintenance documentation and source code
·  Computer resources integrated support document
·  Software product specification
Software Project Management (CS615)
A CSCI, as applied to software; is a component of the system that can be
individually controlled, configured, tested and documented. CSCI s are often
reviewed and approved as separate development items, and though a single
review or audit can consider more than one CSCI, each is usually addressed
separately during the review process. There are no clear-cut guidelines for the
division of a software system into CSCI s as the division is essentially one of
Table 3: DOD Data Item Description standards
Data requirements title
1. System segment design document
2.Software development plan
3.Software requirements specification
4. Interface requirements specification
5. Interface design document
6. Software design document
7. Software product specification
8. Version description document
9. Software test plan
10. Software test description
II. Software test report
12. Computer system operator's manual
13. Software user's manual
14. Software programmer's manual
15. Software support manual
16. Computer resources integrated support document
17. Engineering change proposal
18. Specification change notice
Table 3 contains a list of the DID s referenced by standard 2167A. The software
quality DID is referenced separately in the DOD software quality program
standard 2168. All DID document formats follow a similar pattern. Several of the
sections are common to most, if not all of the documents, such as:
Title page format
Table of contents
Scope (including identification, overview, references etc.)
Other applicable documents
Notes and appendices
Software Project Management (CS615)
phasis is on the required content and not on the required format. This is
specifically addressed in the preparation instructions accompanying each DIn
addition, the page format, page numbering scheme, section numbering scheme
and various other preparation instructions are common. This clearly suggests the
use of an automatic tool to assist in the preparation of the documents, a practice
greatly encouraged by the 2167 standard. Many such tools have been developed
to support 2167, and Polack, in a paper analyzing the use of CASE tools for DOD
projects (Polack 1990), concludes that these tools do indeed save time, and result
in a higher quality software system.
Each DID describe the requirements for the preparation of a specific document,
but the main emID, which state that other presentation styles, including charts,
tables or matrices, are acceptable (e.g. Hatley and Pirbhai (1988) or Ward and
Mellor (1986). There is also substantial flexibility in the requirements regarding
the content of the documents. The standard provides for considerable tailoring to
adapt the standard to the type of project being developed.
Tailoring the standard
Tailoring of standard 2167 is not only encouraged, it is required. The foreword to
2167 states that the standard must be appropriately tailored by the Program
Manager to ensure that only cost-effective requirements are cited in defense
solicitations and contracts.
The DOD has issued a guide for tailoring that can be used as a reference source
for adapting the standards to the type of project being developed. Two basic
principles apply to tailoring:
The tailoring process is the deletion of non-applicable requirements.
Tailoring of the standard should be carried out by the contracting agency.
The first principle means that these modifications can only include the deletion of
requirements from the standard (and not changes to the requirements in the
standard). The second principle means that the contractor (i.e. the developer)
cannot tailor the standard without receiving permission from the contracting
agency (i.e. the DOD).
Tailoring of the 2167 standard must be completed as early as possible. This is best
performed either during contract negotiations or as one of the initial activities as
soon as the project begins. The following is a description of the basic procedure
for tailoring standard 2167:
1. Review all standard 2167 requirements, including;
reviews and audits
Software Project Management (CS615)
testing activities
quality assurance activities
configuration control activities
other required development activities
2. Identify the requirements that are not applicable, justifiable or reasonable for
the project being developed. For example, the Firmware Support Manual will
not be required if no firmware is being developed: or two design reviews
(POR and COR) may not be necessary for a small project.
3. Prepare a list of requests for deletions from the standard. This may include:
exclusion of documents
exclusion of sections in documents
exclusion of activities.
exclusion of parts of activities
4. Prepare a written description of the justifications for each item that is
requested to be tailored out.
5. Submit the tailoring request, together with the justification, as early as
possible (preferably before the project begins).
In order to be able to differentiate between forgotten items and tailored items, all
tailored items must be clearly referenced. When submitting a list of documents for
a formal review or milestone, all documents tailored out should be listed together
with a statement to that effect. Within a document, when a paragraph is tailored
out a statement to that effect will appear directly after the paragraph number. If a
paragraph and all of its subparagraphs are tailored out, only the highest level
paragraph number need be included.
The list of the DID s together with the list of tailoring approvals are an integral
part of the project deliverables. Until tailoring approval has been granted, the
developer is obligated to provide the full list of Dills, with all their inclusions.
This is the reason why tailoring should be concluded as early as possible.
6. The software configuration management plan (SCMP)
The software configuration management plan (SCMP) is part of the project's
software development plan. The SCMP may appear as a separate document or as
a section within the project development plan.
The SCMP documents the resources that are needed, how they are to be used, and
which standards and procedures will be applied during the project.
Software Project Management (CS615)
The SCMP then becomes the mandate for the configuration control group during
project development. The issuance of this plan is the responsibility of the project
manager, though in large projects it may be delegated to the configuration Control
Table 4 contains a list of the main subjects covered in the SCMP. When any of
these subjects is covered elsewhere (e.g. in the software quality assurance plan), it
can be omitted from the SCMP and replaced by a pointer to the document in
which it is covered. Though most of the subjects in Table 1 are self-descriptive,
the following are some guidelines:
Configuration status accounting describes the way in which status information
From the developers to the configuration management organization (audits
and reviews)
From the configuration management organization to project management
(status reporting procedures)
Configuration identification describes the method for designating development
items as SCCI s. This is part of the high level decomposition of the system into
major development components.
The section on identification methods describes the way in which each component
generated by the project is marked for unique identification. Security, restricted
access and classification refer to the secure development of sensitive products
(such as documents, software, patents, military classified information etc.). It is
often convenient to assign many of these tasks to configuration control because of
the need to be involved in the review and classification of documents and other
related activities that are associated with security.
Subcontractors, vendors and suppliers mayor may not implement their own
configuration management plan. It is the project manager's responsibility to assure
that either subcontractors or external developers submit a CMP for review, or that
the project's configuration manager assumes responsibility for their work.
The SCMP may also include diagrams and flow charts to describe procedures for
submitting change requests, or for reporting problems.
7. Statistical software process improvement (SSPI)
As an organization becomes more comfortable with the collection and use or
process metrics, the derivation of simple indicators gives way to a more rigorous
approach called statistical software process improvement (SSPI).
Software Project Management (CS615)
In essence, SSPI uses software failure analysis to collect information about all
errors and defects encountered as an application, system, or product is developed
and used. Failure analysis works in the following manner:
1. All errors and defects are categorized by origin (e.g., flaw in specification, flaw in
logic, non conformance to standards).
2. The cost to correct each error and defect is recorded.
3. The number of errors and defects in each category is counted and ranked in
descending order.
4. The overall cost of errors and defects in each category is computed.
5. Resultant data are analyzed to uncover the categories that result in highest cost to
the organization.
6. Plans are developed to modify the process with the intent of eliminating or
reducing the frequency of the class of errors and defects that is most costly.
Table 4: Example of the contents of a software configuration management plan
1. Software configuration management organization and resources
Organization structure
Personnel skill level and qualifications
2. Standards, procedures, policies and guidelines
3. Configuration identification
Method for defining SCCI s Description of the SCCI s for this project
4. Identification methods (naming and marking of documents, software components,
revisions. releases, etc.)
5. Submission of configuration items
Approval/rejection procedure
6. Change control
Change control procedures (method of submission, review. approval and
Reporting documentation (change requests, problem reports)
Change review procedures and review board
7. Version control
Preparation of software and documentation versions
Release approval procedure
8. Storage, handling and delivery of project media
Storage requirements
Software Project Management (CS615)
9. Configuration control of subcontractors, vendors and suppliers
10. Additional control
Miscellaneous control procedures
Project specific control (security etc)
11. Configuration status accounting
Configuration audits and reviews
Configuration structure reporting procedures
12. Configuration management major milestones
13. Tools, techniques and methodologies
8. Communications management plan
A communications management plan is a document that provides:
A collection and filing structure that details what methods will be used to gather
and store various types of information. Procedures should also cover collecting
and disseminating updates and corrections to previously distributed material.
A distribution structure that, details to whom information (status reports, data,
schedule, technical documentation, etc.) will flow, and what methods (written
reports, meetings, etc.) will be used to distribute various types of information.
This structure must be compatible with the responsibilities and reporting
relationships described by the project organization chart.
A description of the information to be distributed, including format, content, level
of detail, and conventions/definitions to be used.
Production schedules showing when each type of communication will be
Methods for accessing information between scheduled communications.
A method for updating and refining the communications management plan as the
project progresses and develops. The communications management plan may be
formal or informal, highly detailed or broadly framed, based on the needs of the
project. It is a subsidiary component of the overall project plan.
9. The software quality assurance plan
Every project must have a quality plan. The quality plan will be presented as a
section in the project plan.
Software Project Management (CS615)
It is drawn up by the project manager at the start of the project and should be
agreed with the project sponsor.
You would expect the quality plan to contain the following elements:
Statement of the quality control organisation
Identification of specific standards and methods that will be used
Definition of the quality control procedures; this is aligned to the Work
Breakdown Structure
Specification of quality milestones
Detail of unusual features
Change control and configuration management
Detail of acceptance procedures
Specification of quality assurance procedures
The software quality assurance plan (SQAP), like the software configuration plan,
is also part of the overall software project development plan.
The SQAP documents which resources are needed, how they should be used and
which standards and procedures will be applied during the project.
The SQAP then becomes the mandate for the quality assurance group during
project development. The issuance of this plan is the responsibility of the project
manager, though in large projects it will usually be delegated to the quality
assurance manager.
The SQAP may appear as a separate document or as a section within the project
development plan, and may include the configuration management plan (if this
has not been documented separately).
Table 5 contains a list of the main subjects covered in the SQAP. When any of
these subjects is covered elsewhere, such as in the software configuration
management plan (SCMP), it can be omitted from the SQAP and replaced by a
pointer to the document in which it is covered.
However, the SCMP and the SQAP are concerned with different aspects of the
controlled items. The SCMP is primarily concerned with the format of controlled
items while the SQAP is more involved with the contents of controlled items.
The SQAP must cover subcontractors, vendors and suppliers, irrespective of
whether or not these external entities have their own quality assurance
In any project, the quality of external components is ultimately the concern of the
project manager and the SQA organization. When a system fails, it usually makes
Software Project Management (CS615)
little difference whether the failure is due to an externally developed component
or an in-house developed component.
The plans for supervising these external groups must be adapted to the type of
external components being provided (off the shelf or new development) and the
type of organization (do they have their own quality assurance organization?).
Software Project Management (CS615)
Table 5: Example of the contents of a software quality assurance plan
1. Software quality assurance organization and resources
Organizational structure
Personnel skill level and qualifications
2. SQA standards. Procedures, policies and guidelines
3. SQA documentation requirements
List of all documentation subject to quality control
Description of method of evaluation and approval
4. SQA software requirements
Evaluation and approval of software
Description of method of evaluation
Evaluation of the software development process
Evaluation of reused software
Evaluation of non-deliverable software
5. Evaluation of storage handling and delivery
Project documents
Data files
6. Reviews and audits
7. Software configuration management (when not addressed in a separate document)
8. Problem reporting and corrective action
9. Evaluation of test procedures
10. Tools techniques and methodologies
11. Quality control of subcontractors, vendors and suppliers
12. Additional control
Miscellaneous control procedures
Project specific control
13. SQA reporting, records and documentation.
Status reporting procedures
Storage and security
Retention period
The SQAP, as part of the project development plan, should be reviewed and
updated periodically and whenever any requirements, project development
procedures, methodologies or other relevant activities are changed.
Software Project Management (CS615)
The IEEE SQAP guide recommends periodic evaluation of two aspects of the
(1) The plan's content and
(2) The plan's implementation
The plan's content should be evaluated with regard to the specific SQAP standard
used, to assure the plan's continuing compliance with the standard even when the
characteristics of the software project change.
The plan's implementation should be evaluated in terms of the changing scope of
the project, including the tasks and responsibilities referenced in the plan, and
other new or changed characteristics of the project.
When updating the SQAP the following project activities and events should be
New or changed contractual requirements
Additional standards and policies
Additional project documents
Changes in the project's organizational structure
New tools and utilities
Additional subcontractors and vendors
10. The RMMM Plan
A collection of risk information sheets developed for all risks that lie above the
cut off. 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 are 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) [WIL97]. 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.
Software Project Management (CS615)
As we have already discussed, risk mitigation is a problem avoidance activity.
Risk monitoring is a project tracking activity with three primary objectives:
1. To assess whether predicted risks do, in fact, occur;
2. To ensure that risk aversion steps defined for the risk are being properly
applied; and
3. 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 (what risk(s)
caused which problems throughout. the project).
11. Project Development Budget
Good estimates are important, as they form the foundations of a good project
development plan. This plan, prepared by the project manager, is produced during
the initial stages of the project and includes estimates related to:
The project development budget
The project development schedule
The required development resources (development staff, development
equipment etc.)
In parallel with integration and testing, the following managerial and activities
take place:
Final budgeting of the project; the cost of changes is determined, risk
contingency activities are evaluated, and the budget is updated.
Training is conducted for users, operators, customers, installers, maintenance
engineers, and marketing engineers.
Installation sites are prepared, and the infrastructure for hardware and special
equipment is planned and installed.
The development team size is reduced.
12. Maintenance Documents
The phased approach to software development divides the development life cycle
The development of the software code
Preparation for integration and test of the system (the next phase)
The development of the maintenance plan
Apart from the actual code being written (and hopefully being well commented),
some of the other documents that are developed during this phase include:
Software Project Management (CS615)
The programmer's notebook, documenting coding decisions, unit tests, and
resolution of implementation problems.
Maintenance plan and documentation, including all necessary documentation
needed for system maintenance.
Initial versions of the user documentation, including reference manuals and
operator guides.
At the conclusion of the integration and test phase all documentation must be
complete and ready for delivery, including:
Maintenance documentation
Final user documentation
All updated development documentation
Test documentation and test reports
Maintenance requires a much smaller team, and a different type of management. In
fact, a single maintenance group can be established to maintain several products, with
common management, configuration control, installation and field engineers, and
maintenance of documentation.
The documents that need to be updated during this phase include:
Version release documentation
Problem reports
All development documentation
All user documentation
Maintenance logs and customer service reports
13. The statement of work (SOW)
The statement of work is the basis of the contract between the pro-poser and the
customer, and is often incorporated into the contract. The SOW contains a
detailed list of all work to be performed by the pro-poser for the benefit of the
It is a narrative description of products or services to be supplied by the project.
For internal projects, the project initiator or sponsor provides the statement of
work based on business needs, or product or service requirements. For external
projects, the statement of work can be received from the customer as part of a bid
document, for example, request for proposal, request for information, request for
bid, or as part of a contract. The SOW indicates a:
Business need - an organization's business need, can be based on needed
training, market demand, technological advance, legal requirement, or
governmental standard.
Software Project Management (CS615)
Product scope description - documents the product requirements and
characteristics of the product or service that the project will be undertaken to
create. The product requirements will generally have less detail during the
initiation process and more detail during later processes, as the product
characteristics are progressively elaborated. These requirements should also
document the relationship among the products or services being created and
the business need or other stimulus that causes the need. While the form and
substance of the product requirements document will vary, it should always be
detailed enough to support later project planning.
Strategic plan - all projects support the organization's strategic goals--the
strategic plan of the performing organization should be considered as a factor
in project selection decisions.
The SOW starts as a general list of required deliverables in the RFP. A more
detailed version t of the SOW is submitted as part of the proposal, and is still
considered only an initial description of the work to be performed. The blinding
version of the SOW is finalized during contract negotiations, or after the detailed
project requirements have been completed.
Table 6 presents an example of an SOW outline for a software project. The list of
items varies considerably, depending on the type of project being developed; for
example not all projects include the delivery of hardware components, and not all
projects require training or installation.
The basic guideline for the preparation of the SOW is that any activity, service or
product required by the customer, and agreed to by the developer, must be
included. This means that there can be no binding work items that were
informally understood or agreed to verbally, which do not appear in the SOW.
The formal SOW must include all and only the work to be performed. This
condition prevents misunderstandings and disagreements later, after the project
The statement of work (SOW) describes the procurement item in sufficient detail
to allow prospective sellers to determine if they are capable of providing the item.
"Sufficient detail" may vary, based on the nature of the item, the needs of the
buyer, or the expected contract form.
Some application areas recognize different types of SOW. For example, in some
government jurisdictions, the term SOW is reserved for a procurement item that is
a clearly specified product or service, and the term Statement of Objectives (SOO)
is used for a procurement item that is presented as a problem to be solved.
The statement of work may be revised and refined as it moves through the
procurement process. For example, a prospective seller may suggest a more
Software Project Management (CS615)
efficient approach or a less costly product than that originally specified. Each
individual procurement item requires a separate statement of work. However,
multiple products or services may be grouped as one procurement item with a
single SOW.
Table 6: A sample SOW outline for a software project
Referenced documents
requirements specification
existing system description
customer's RFP
developer's proposal
vendor's and developer's technical literature
Software deliverables
functionality (as documented in the requirements specification)
list of major software components
Equipment and hardware deliverables
functionality (as documented in the requirements specification)
list of major hardware components
user courses
operator training
installation training
Market research
Supervision of subcontractors
development documentation
user documentation
maintenance documentation
other technical documentation
alpha testing
beta testing
acceptance tests (ATP)
Maintenance services
Other services and deliverable items
Method of delivery
Software Project Management (CS615)
The statement of work should be as clear, as complete, and as concise as possible.
It should include a description of any collateral services required, such as
performance reporting or post-project operational support for the procured item.
In some application areas, there are specific content and format requirements for a
14. Responsibility Assignment Matrix (RAM)
Project roles (who do what) and responsibilities (who decide what) must be
assigned to the appropriate project stakeholders.
Roles and responsibilities may vary over time. Most roles and responsibilities will
be assigned to stakeholders who are actively involved in the work of the project,
such as the project manager, other members of the project management team, and
the individual contributors.
The roles and responsibilities of the project manager are generally critical on most
projects, but vary significantly by application area. Project roles and
responsibilities should be closely linked to the project scope definition.
A Responsibility Assignment Matrix (RAM) is often used for this purpose. On
larger projects, RAM s may be developed at various levels.
For example, a high-level RAM may define which group or unit is responsible for
each component of the work breakdown structure, while lower-level RAM s are
used within the group to assign roles and responsibilities for specific activities to
particular individuals.
A structure that relates the project organization structure to the work breakdown
structure, to help ensure, that each element of the project's scope of work is
assigned to a responsible individual.
Shows who does what (x=person, y=phase). The most important feature of the
RAM is the participatory development process involving all stakeholders.
Show who is participant, who is accountable, who handles reviews, who
provides input and who must sign off on specific work packages or project
15. Project Charter
Software Project Management (CS615)
A document issued by senior management that formally authorizes the existence
of a project. And it provides the project manager with the authority to apply
organizational resources to project activities.
16. Risk management plan
The risk management plan describes how risk identification, qualitative and
quantitative analysis, response planning, monitoring, and control will be
structured and performed during the project life cycle. The risk management plan
may include the following.
­ Methodology. Defines the approaches, tools, and data sources that may be
used to perform risk management on this project. Different types of
assessments may be appropriate, depending upon the project stage, amount of
information available, and flexibility remaining in risk management.
­ Roles and responsibilities. Defines the lead, support, and risk management
team membership for each type of action in the risk management plan. Risk
management teams organized outside of the project office may be able to
perform more independent, unbiased risk analyses of project than those from
the sponsoring project team.
­ Budgeting. Establishes a budget for risk management for the project.
­ Timing. Defines how often the risk management process will be performed
throughout the project life cycle. Results should be developed early enough to
affect decisions. The decisions should be revisited periodically during project
­ Scoring and interpretation. The scoring and interpretation methods
appropriate for the type and timing of the qualitative and quantitative risk
analysis being performed. Methods and scoring must be determined in
advance to ensure consistency.
­ Thresholds. The threshold criteria for risks that will be acted upon, by whom,
and in what manner. The project owner, customer, or sponsor may have a
different risk threshold. The acceptable threshold forms the target against
which the project team will measure the effectiveness of the risk response plan
­ Reporting formats. Describes the content and format of the risk response
plan. Defines how the results of the risk management processes will be
documented, analyzed, and communicated to the project team, internal and
external stakeholders, sponsors, and others.
Software Project Management (CS615)
­ Tracking. Documents how all facets of risk activities will be recorded for the
benefit of the current project, future needs, and lessons learned. Documents if
and how risk processes will be audited.
Any project can be completed, given an infinite amount of time and resources.
Realistically, the amount of time available for project development is always
In fact, in most cases it is less than the project manager considers sufficient.
Few projects are completed ahead of time; many projects overrun their schedule.
The project schedule is one of the most important parts of the project
development plan.
The plan includes:
Scheduling of development activities and
Scheduling of project resources, particularly people
The project development plan describes in detail:
how the project manager plans to develop the project
what resources will be required and
how these resources will be applied
No matter how well the project schedule is prepared, that schedule is useless
unless it is adhered to. It is the project manager's responsibility to withstand
pressure and to assure that the project is developed in an orderly fashion,
according to the schedule. Whenever circumstances change, the project schedule
should then be updated to reflect the new situation.
A schedule is a list of:
­  Activities and
­  Anticipated time of implementation of these activities
There are many ways of representing a schedule:
­  Lists of activities,
­  Diagrams,
­  Graphs etc.
Software Project Management (CS615)
The most common methods of schedule representation are :
­  precedence network diagrams (such as PERT),
­  Gantt charts and
­  lists of milestones
Guidelines for successful Planning
A common failure in many kinds of planning is that the plan is never really
implemented. Instead, all focus is on writing a plan document.
Most of the following guidelines help to ensure that the planning process is
carried out completely and is implemented completely or, deviations from the
intended plan are recognized and managed accordingly.
Involve the Right People in the Planning Process
It's critical that all parts of the system continue to exchange feedback in order to
function effectively. This is true no matter what type of system.
When planning, get input from everyone who will be responsible to carry out
parts of the plan, along with representative from groups who will be affected by
the plan.
Of course, people involved should be responsible to review and authorize the
Write Down the Planning Information and Communicate it Widely
New managers, in particular, often forget that others don't know what these
managers know.
Even if managers do communicate their intentions and plans verbally, chances are
that others won't completely hear or understand what the manager wants done.
Also, as plans change, it's extremely difficult to remember who is supposed to be
doing what and according to which version of the plan.
Key stakeholders (employees, management, board members, sponsors, customers,
clients, etc.) may request copies of various types of plans.
Therefore, it's critical to write plans down and communicate them widely.
Goals and Objectives Should Be SMARTER
Software Project Management (CS615)
Time frame
Build in Accountability (Regularly Review Who's Doing What and By
Plans should specify who is responsible for achieving each result, including goals
and objectives.
Dates should be set for completion of each result, as well.
Responsible parties should regularly review status of the plan.
Be sure to have someone of authority "sign off" on the plan, including putting
their signature on the plan to indicate they agree with and support its contents.
Include responsibilities in policies, procedures, job descriptions, performance
review processes, etc.
Note Deviations from the Plan and Re-plan Accordingly
It's OK to deviate from the plan. The plan is not a set of rules. It's an overall
guideline. It is equally important to notice deviations and adjust the plan
Evaluate Planning Process and the Plan
During the planning process, regularly collect feedback from participants. Do they
agree with the planning process? If not, what don't they like and how could it be
done better?
In large, ongoing planning processes (such as strategic planning, business
planning, project planning, etc.), it's critical to collect this kind of feedback
During regular reviews of implementation of the plan, assess if goals are being
achieved or not. If not, were goals realistic? Do responsible parties have the
resources necessary to achieve the goals and objectives?
Should goals be changed? Should more priority be placed on achieving the goals?
What needs to be done?
Write down how the planning process could have been done better. File it away
and read it the next time you conduct the planning process.
Software Project Management (CS615)
Recurring Planning Process is at Least as Important as Plan Document
Far too often, primary emphasis is placed on the plan document.
This is extremely unfortunate because the real treasure of planning is the planning
process itself.
During planning, planners learn a great deal from ongoing analysis, reflection,
discussion, debates and dialogue around issues and goals in the system.
The ongoing communications are what sensitize people to understanding and
following the values and behaviors described
Nature of the Process Should Be Compatible to Nature of Planners
A prominent example of this type of potential problem is when planners don't
prefer the "top down" or "bottom up", "linear" type of planning
For example, going from general to specific along the process of an
environmental scan, SWOT analysis, mission/vision/values, issues and goals,
strategies, objectives, timelines, etc.
Table of Contents:
  1. Introduction & Fundamentals
  2. Goals of Project management
  3. Project Dimensions, Software Development Lifecycle
  4. Cost Management, Project vs. Program Management, Project Success
  5. Project Management’s nine Knowledge Areas
  6. Team leader, Project Organization, Organizational structure
  7. Project Execution Fundamentals Tracking
  8. Organizational Issues and Project Management
  9. Managing Processes: Project Plan, Managing Quality, Project Execution, Project Initiation
  10. Project Execution: Product Implementation, Project Closedown
  11. Problems in Software Projects, Process- related Problems
  12. Product-related Problems, Technology-related problems
  13. Requirements Management, Requirements analysis
  14. Requirements Elicitation for Software
  15. The Software Requirements Specification
  16. Attributes of Software Design, Key Features of Design
  17. Software Configuration Management Vs Software Maintenance
  18. Quality Assurance Management, Quality Factors
  19. Software Quality Assurance Activities
  20. Software Process, PM Process Groups, Links, PM Phase interactions
  21. Initiating Process: Inputs, Outputs, Tools and Techniques
  22. Planning Process Tasks, Executing Process Tasks, Controlling Process Tasks
  23. Project Planning Objectives, Primary Planning Steps
  24. Tools and Techniques for SDP, Outputs from SDP, SDP Execution
  25. PLANNING: Elements of SDP
  26. Life cycle Models: Spiral Model, Statement of Requirement, Data Item Descriptions
  27. Organizational Systems
  28. ORGANIZATIONAL PLANNING, Organizational Management Tools
  29. Estimation - Concepts
  30. Decomposition Techniques, Estimation – Tools
  31. Estimation – Tools
  32. Work Breakdown Structure
  33. WBS- A Mandatory Management Tool
  34. Characteristics of a High-Quality WBS
  35. Work Breakdown Structure (WBS)
  36. WBS- Major Steps, WBS Implementation, high level WBS tasks
  37. Schedule: Scheduling Fundamentals
  38. Scheduling Tools: GANTT CHARTS, PERT, CPM
  39. Risk and Change Management: Risk Management Concepts
  40. Risk & Change Management Concepts
  41. Risk Management Process
  42. Quality Concept, Producing quality software, Quality Control
  43. Managing Tasks in Microsoft Project 2000
  44. Commissioning & Migration