OHT 6.

• Development plan and quality plan objectives

• The elements of the development plan

• Elements of the quality plan

• Development and quality plans for small and

for internal projects

• Software development risks and software risk

management
Galin, SQA from theory to implementation © Pearson Education Limited 2004
 OHT 6.2
Introduction
• Project managers prepare
– development and
– quality plans.
• Onerous task,
– Senior level management on one end and
– Developers on the other
• Two dance to different drummers.
• These plans are vitally important to meet
contractual commitments
• Thus, we need to look at:
Galin, SQA from theory to implementation © Pearson Education Limited 2004
 OHT 6.3
• Objectives of development and quality plans
• Elements of development plans
• Elements of quality plans
• Major software risks
• Process of software risk management
• Importance of development and quality plans
for small projects
• Importance of development and quality plans
for internal projects.

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 6.4 6.1 Development Plan and Quality Plan Objectives
Planning is meant to prepare adequate foundations for successful and
timely completion of the project. The planning process includes:

1. Scheduling development activities and estimating the

required manpower resources and budget

2. Recruiting team members and allocating development resources

3. Resolving development risks

4. Implementing required SQA activities

5. Providing management with data needed for project control

Galin, SQA from theory to implementation © Pearson Education Limited 2004
 OHT 6.5 6.2 Elements of the Development Plan
Each of the following 10 components of a development plan are
appropriate to different parts of a project.

1. Project Products, specifying “deliverables”

Critically important.
Must decide on deliverables!
dates and items
installation site – local or physical install
training – customer service
dates, participants, and sites
(much is done on line
now…)

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 6.6 6.2 Elements of the Development Plan
2. Project Interfaces

• How does the new software interface with existing

software?
– (major consideration in large corporation)

• How does the software affect other parts of a larger

system or similar systems??
• Often requires ‘escalation.’

• Any hardware considerations for interfacing?

Special hardware?

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 6.7 6.2 Elements of the Development Plan
3. Project methodology and development tools for
various phases during development, maintenance.

• Heuristic: never use untested tool / methodology on a

new project with high visibility!!
• Methodology must be decided upon.
– Usually organizations have ‘established’ ways of proceeding…

4. Software Development Standards and Procedures

Must be conventions!! Standards and Integration!!
a MUST!

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 6.8 6.2 Elements of the Development Plan
5. Laying out the Development Process
Define the project’s phases

Planning: inputs/outputs/activities/activity
duration/sequence and dependencies/resources needed for
each activity/ design reviews/ testing/ training for
customer support/ more…

GANTTT Charts / CPM , PERT all include sequence

dependencies and duration.
Microsoft Project and Rational Conductor

6. Project Milestones
completion dates, products clearly define.
Must synchronize with Overall Plan.
More detailed than Overall Plan
Galin, SQA More
from theorydetailed than iteration plans
to implementation © Pearson Education Limited 2004
 OHT 6.9 6.2 Elements of the Development Plan
7. Project Staff Organization
Organizational structure – teams, tasks, sub
contractors, temporary workers. Pecking order…
much risk!

Professional requirements of teams / leadership

risk!!

Numbers for periods of time

team size varies from beginning to fully
staffed, to...

Designate team leaders and members

team composition will change throughout a
long development effort.
Galin, SQA from theory tostaff evaporation; reassignments;
implementation illness,
© Pearson …..2004
Education Limited
 OHT 6.10 6.2 Elements of the Development Plan
8. Development Facilities

Hardware, software, tools, development environments,

training on these, space

Very important.

Many very nice facilities nowadays – break rooms, ping

pong; nice coffee / beverage facilities; day care.

10. Control Methods

How to control the monitoring process / reporting process
with respect to plans, test reports, reviews, howgoesit, and more

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 6.11 6.2 Elements of the Development Plan
11. Project Cost Estimation

An art in itself based on many models and experience.

COCOMO and COCOM II Models (Barry Boehm)

human resource estimates,

contracts with suppliers,
internal development and unavailability,
budget changes,
risk considerations.
travel first go go
training second to go…

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 6.12 6.2 Elements of the Development Plan
9. Development Risks - Inherent in any project

Risk: “a state or property of a development task or

environment, which, if ignored, will
increased the likelihood of project failure.”

Technology risks – experience of team members

Personnel shortages – can arise during project

Environmental risks

Budget risks

Interdependence on others (hardware;

subcontractors, etc.)
Galin, SQA from theory to implementation © Pearson Education Limited 2004
 OHT 6.13

More on Risks
Risk Management: identification,
evaluation, planning actions,
implementation, monitoring…
Calculation of Risk
Monitoring of risk throughout development
cycle!!

The Spiral Model – specifically incorporating

risk to every cycle (next chapter)

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 6.14

1.Developing wrong software functions *

2.Unrealistic schedules and budgets *
3.Developing wrong user interface
4.Gold plating *
5.Continuing stream of requirement changes *
6.Shortfalls in externally furnished components
7.Shortfalls in externally performed tasks
8.Personnel shortfalls *
9.Real-time performance shortfalls *
10.Straining computer science capabilities
Galin, SQA from theory to implementation © Pearson Education Limited 2004
 OHT 6.15

New
project

Pre- Risk identification

project and assessment

Planning risk Planning and updating risk

management activities management activities
Ongoing
projects Implementing
risk management actions
Identifying and (risk resolution)
assessing new software
risks Monitoring software risk
management activities

Required results
achieved Evaluate Unsatisfactory results
monitoring
results

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 6.16
6.3 The Elements of a the Quality Plan
1. List of quality goals
These refer to the quality requirements in the developed
software system.

Quantitative measures usually preferred to qualitative

measures when choosing goals because they are usually easier
to assess objectively during testing.

Quality goals should reflect the major acceptance criteria

found in the requirement’s document (an RFP)
correctness, reliability, robustness, maintainability….

RFP is often used to measure successful achievement of the

customer’s quality requirements.
Galin, SQA from theory to implementation © Pearson Education Limited 2004
 OHT 6.17
6.3 The Elements of a the Quality Plan
2. Planned Review Activities
The planned reviews should include a listing of all reviews.
design reviews
technical reviews
managerial reviews
code inspections
Pros and Cons……………………

All reviews need to include:

Scope – what does it cover
Type – emphasis – managerial, technical, super detailed…
Schedule – often based on previous reviews and outcomes
Procedures – action lists; present and discuss; …
Who is to attend? Collateral interest?? *****
Responsibilities for review; documents needed, by when…
Galin, SQA from theory to implementation © Pearson Education Limited 2004
 OHT 6.18
6.3 The Elements of a the Quality Plan
3. Planned Software Tests

Must include a complete list of planned tests

Each test must include the following:

coverage of test: unit, integration, system, subsystem….

type of test: may include computer-generated tests and
their application via test suites, and more
Planned test schedule – prioritized and follow up
Exact procedures (for different types of tests…)
Who is responsible for carrying out tests
notification, time, date, materials, facilities, etc…
Different people responsible at different times!!
**
Galin, SQA from theory to implementation © Pearson Education Limited 2004
 OHT 6.19
6.3 The Elements of a the Quality Plan
4. Planned Acceptance Tests for Externally
Developed Software
A complete set of acceptance tests to be run for externally
developed software must be provided within the quality
plan!

(Complete set must be run for our own developed software!)

Especially critical for purchased software, contracted

software, customer-supplied software.

These tests can be run in parallel with internally-developed

software tests (tests that internally are developed to
supplement other tests)
Galin, SQA from theory to implementation © Pearson Education Limited 2004
 OHT 6.20
6.3 The Elements of a the Quality Plan
5. Configuration Management
The quality plan MUST include configuration
management tools and procedures for managing the
software configurations, versions, etc.

Must be an intrinsic part of the entire project!

The Quality Plan may be included within the Development Plan

or as an independent document.

The document, however compiled, must be reviewed and

approved by the organization’s standard approval
process.
Galin, SQA from theory to implementation © Pearson Education Limited 2004
 OHT 6.21
Development / Quality Plans for
Small and Internal Projects
Natural for many to try to avoid hassle of preparing all these plans.
In fact, heavy-weight methodologies are often called plan-centric;
Agile methods try to avoid much planning and documentation

The question is simply does a short, small project (likw 30-60 days;
two or three individuals) deserve the time spent on planning a
development and quality plan?
Answer: No, not exactly.

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 6.22
Development / Quality Plans for Small
Projects

Lots of issues here…

Sometimes not done due to short duration / manpower
Sometimes planning is left up to the project leader’s
discretion.
Perhaps a critically-important and high risk but short
duration effort with high-penalty shouts for a plan…
Sometimes, via contract, both development and
quality plans are simply required.
Galin, SQA from theory to implementation © Pearson Education Limited 2004
 OHT 6.23 Development / Quality Plans for Small Projects
Several advantages to planned over unplanned projects:
1.A more comprehensive / thorough understanding of
the task is likely (gained when developing the plan)
2.Greater responsibility for meeting obligations can be
assigned, as they can be ‘seen’ more clearly since
articulated (who does what)
3.Easier to share control of the project and identify
unexpected delays (any plan better than no plan at all!)
4.Better understanding of requirements and timetable
can be reached between customer and developer.
Galin, SQA from theory to implementation © Pearson Education Limited 2004
 OHT 6.24 Development / Quality Plans for Internal
Projects

Lots of projects done for the internal use of organization.

Here, normally no external body is a customer
Can be medium or large scale.
Tendency to avoid adequate development / quality plans
avoiding plans is fraught with errors.
cost overruns, finger pointing, missed dates,
internal friction among cooperating shops, …
Often put on back burner!!
Galin, SQA from theory to implementation © Pearson Education Limited 2004
 OHT 6.25
Preparing Plans provides Advantages
Internal Customers ‘can’ enjoy advantages.

smaller deviations from planned completion dates

smaller budget overruns
better control over development process – problems can
be addressed locally,
Organizationally,
reduced risk of market loss (done for internal use)
reduced risk of litigation (late arrival; non-compliance)
reduced risk of impairing a firm’s reputation
reduced risk of requesting a budget supplement.
Galin, SQA from theory to implementation © Pearson Education Limited 2004