Life cycle Models: Spiral Model, Statement of Requirement, Data Item Descriptions

<< PLANNING: Elements of SDP

Organizational Systems >>

Software Project Management (CS615)

LECTURE # 26

5. ORGANIZATION

4.8.1

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

departments.

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

160

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

features.

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

efficiently.

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.

161

Software Project Management (CS615)

Process Model A

Process Model B

Figure: Customizing Process Models

4.8.2

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

162

Software Project Management (CS615)

allocated time and ensure maintenance of quality and measurability throughout the

project.

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

considered:

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

163

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

164

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

Analysis

Design

Coding

Testing

Implementation &

Design

You should use Prototyping model when:

The client is not clear about the requirements of the proposed system or

165

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

166

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.

Example:

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

167

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.

Example:

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

time.

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.

4.9

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:

168

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:

Unambiguous

Fully defined or complete

Verifiable deliverables

No conflicts

Consistent

Auditable

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

169

Software Project Management (CS615)

All major dependencies in the project development plan are examined and

evaluated.

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

expected.

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

Problem

Description

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

input

too slow.

may exceed the 5 seconds specified in the

requirements.

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

schedule.

170

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

problems

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

171

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

172

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

convenience.

Table 3: DOD Data Item Description standards

Data requirements title

Acronym

1. System segment design document

SSDD

2.Software development plan

SDP

3.Software requirements specification

SRS

4. Interface requirements specification

IRS

5. Interface design document

IDD

6. Software design document

SDD

7. Software product specification

SPS

8. Version description document

VDD

9. Software test plan

STP

10. Software test description

STD

II. Software test report

STR

12. Computer system operator's manual

CSOM

13. Software user's manual

SUM

14. Software programmer's manual

SPM

15. Software support manual

FSM

16. Computer resources integrated support document

CRISD

17. Engineering change proposal

ECP

18. Specification change notice

SCN

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

173

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

documentation

174

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.

175

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

manager.

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

flows:

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).

176

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

Resources

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

rejection)

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

Backups

177

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

produced.

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.

178

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

organization.

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

179

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?).

180

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

Resources

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

Software

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

Maintenance

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.

181

Software Project Management (CS615)

The IEEE SQAP guide recommends periodic evaluation of two aspects of the

plan:

(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

considered:

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.

182

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

into:

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:

183

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

customer.

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.

184

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

begins.

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

185

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

Training

user courses

operator training

installation training

Market research

Procurement

Supervision of subcontractors

Documentation

development documentation

user documentation

maintenance documentation