Unit3 Dev & Quality Plan
Unit3 Dev & Quality Plan
objectives
• Planning, as a process, has several objectives, each of which
is meant to prepare adequate foundations for the following:
(1) Scheduling development activities that will lead
to the successful and timely completion of the project, and
estimating the required manpower resources and budget.
(2) Recruiting team members and allocating
development resources (according to activity schedules and
manpower resource requirement estimates).
(3) Resolving development risks.
(4) Implementing required SQA activities.
(5) Providing management with data needed for
project control.
Elements of the development plan
1. Project products
2. Project interfaces
3. Project methodology and development tools
4. Software development standards and procedures
5. The Map of the development process
6. Project milestones
7. Project staff organization
8. Development facilities
9. Development risks
10. Control methods
11. Project cost estimates
1. Project products :
Design documents specifying dates of completion,
indicating those items to be delivered to the customer
(“deliverables”)
Software products (specifying completion date and
installation site)
Training tasks (specifying dates, participants and sites).
2. Project interfaces :
Interfaces with existing software packages (software
interface)
Interfaces with other software and/or hardware
development teams that are working on the same system
or project (i.e., cooperation and coordination links)
Interfaces with existing hardware (hardware interface).
3.Project methodology and development tools:
Project methodology and development tools to be applied at each
phase of the project.
4.Software development standards and procedures :
A list should be prepared of the software development standards
and procedures to be applied in the project.
5.The mapping of the development process:
Mapping of the development process involves providing detailed
definitions of each of the project’s phases. These descriptions include
definitions of inputs and outputs, and the specific activities planned.
Activity descriptions include:
(a) An estimate of the activity’s duration. These estimates are
highly dependent on the experience gained in previous projects.
(b) The logical sequence in which each activity is to be performed,
including a description of each activity’s dependence on previously
completed activities.
(c) The type of professional resources required and estimates of
how much of these resources are necessary for each activity.
6. Project milestones :
For each milestone, its completion time and project products
(documents and code) are to be defined.
7. Project staff organization :
The organization plan comprises:
■ Organizational structure:
definition of project teams and their tasks, including teams
comprised of a subcontractor’s temporary workers.
■ Professional requirements:
professional certification, experience in a specific
programming language or development tool, experience with a
specific software product and type, and so forth.
■ Number of team members required for each period of time,
according to the activities scheduled. It is expected that teams will
commence their activities at different times, and that their team
size may vary from one period to the next, depending on the
planned activities.
■ Names of team leaders and team members.
Difficulties are expected to arise with respect to the
long-term assignment of staff members to teams
because of unanticipated changes in their current
assignments. Therefore, the names of staff are
required to help keep track of their participation as
team members.
8. Development facilities :
Required development facilities include hardware,
software and hardware development tools, office
space, and other items. For each facility, the period
required for its use should be indicated on the
timetable.
9.Development risks :
Development risks are inherent in any project. A
development risk is “a state or property of a
development task or environment, which, if ignored, will
increase the likelihood of project failure”. Typical
development risks are:
Technological gaps – Lack of adequate and sufficient
professional knowledge and experience to carry out the
demands of the development contract.
Staff shortages – Unanticipated shortfalls of
professional staff.
Interdependence of organizational elements – The
likelihood that suppliers of specialized hardware or
software subcontractors, for example, will not fulfill their
obligations on schedule.
10. Control methods :
In order to control project implementation, the
project manager and the department management apply
a series of monitoring practices when preparing progress
reports and coordinating meetings.
11. Project cost estimation :
Project cost estimates are based on proposal costs
estimates, followed by a thorough review of their
continued relevance based on updated human resource
estimates, contracts negotiated with subcontractors and
suppliers, and so forth.
For instance, part of the project, planned to be
carried out by an internal development team, needs to
be performed by a subcontractor, due to unavailability of
the team. A change of this nature is usually involved in a
substantial additional budget.
Elements of the quality plan
1.Quality goals
2. Planned review activities
3. Planned software tests
4. Planned acceptance tests for externally
developed software
5. Configuration management
1.Quality goals
• The term “quality goals” refers to the developed
software system’s substantive quality
requirements.
• Quantitative measures are usually preferred to
qualitative measures when choosing quality goals
because they provide the developer with more
objective assessments of software performance
during the development process and system
testing.
• However, one type of goal is not totally
equivalent to the other.
• Example
A software system to serve the help desk operations
of an electrical appliance manufacturer is to be
developed.
The help desk system (HDS) is intended to operate
for 100 hours per week.
The software quality assurance team was requested
to prepare a list of quantitative quality goals appropriate
to certain qualitative requirements, as shown in table
The quality goals should reflect the major acceptance
criteria indicated in the customer’s requirement
document (i.e., the RFP document). As such, quality goals
serve as measures of the successful achievement of the
customer’s quality requirements.
2. Planned review activities
• The quality plan should provide a complete listing of
all planned review activities: design reviews (DRs),
design inspections, code inspections, and so on, with
the following determined for each activity:
The scope of the review activity
The type of the review activity
The schedule of review activities (as defined by its
priority and the succeeding activities of the project
process)
The specific procedures to be applied
Who is responsible for carrying out the review
activity?
3. Planned software tests
• The quality plan should provide a complete list of planned
software tests, with the following designated for each test:
The unit, integration or the complete system to be tested
The type of testing activities to be carried out, including
specification of computerized software tests to be applied
The planned test schedule (as defined by its priority and
the succeeding activities of the project process)
The specific procedures to be applied
Who is responsible for carrying out the test
4. Planned acceptance tests for
externally developed software
• A complete list of the acceptance tests planned
for externally developed software should be
provided within the quality plan. Items to be
included are
1. purchased software
2. software developed by subcontractors
3.customer-supplied software.
• The acceptance tests for externally developed
software should parallel those used for internally
developed software tests.
5.Configuration management
• The quality plan should specify configuration
management tools and procedures, including
those change-control procedures meant to be
applied throughout the project.
Development and quality plans for
small projects and for internal projects
• It is quite natural for project leaders to try to
evade the “hassle” of preparing a
development plan and a quality plan.
• This tendency is especially common in two
different situations:
1. Small projects
2. Internal projects.
Development plans and quality plans
for small projects
• It should be clear that the development and quality plan
procedures applicable to large projects cannot be automatically
applied to small projects.
• Special procedures are needed. These procedures determine
how to treat the project in question with respect to the plans:
1. Cases/situations where neither development nor quality
plans are required, e.g. projects requiring 15 man-days.
2. Cases/situations where the decision to prepare the plans
is left to the project leader’s discretion. One example could be a
project requiring less than 50 man-days where no significant
software risk item had been identified – in this case it might be
decided that no plans will be prepared
3. Cases/situations where development and quality plans
are obligatory.
Recommended elements of development and
quality plans for small projects
• The development plan:
Project products, indicating “deliverables”
Project benchmarks
Development risks
Estimates of project costs
• The quality plan:
Quality goals
• Several advantages to “planned” small projects
over “unplanned” projects can be identified, even
for “reduced” plans:
1.A more comprehensive and thorough
understanding of the task is attained.
2.Greater responsibility for meeting obligations
can be assigned.
3.It becomes easier for management and
customers to share control of the project and to
identify unexpected delays early on.
4.Better understandings with respect to the
requirements and timetable can be reached
between the developer and the customer.
Development plans and quality plans
for internal projects
• Internal projects are those projects intended for use
by other departments in the organization or by the
entire organization, as well as those projects dealing
with software package development for the software
market.
• Common to all these project types is the fact that no
external body participates as customer in their
development.
• Internal projects can be of medium or large scale. Yet
even in these cases, there is a tendency to avoid
preparation of adequate development and quality
plans.
Software development departments can enjoy the
following advantages of plan preparation:
(1) Avoiding budget overruns. This is of special
importance where the profit center system is applied.
(2) Avoiding damage to other projects caused by
delays in release of professionals occupied in an
internal project.
(3) Avoiding loss of market status, especially
regarding the firm’s reputation, caused by delayed
completion of external projects triggered by late
completion of internal projects.
Internal “customers” can enjoy the following
advantages:
(1) Smaller deviations from planned
completion dates and smaller budget overruns.
(2) Better control over the development
process, including earlier identification of
possible delays that enables the search for and
resolution of their causes.
(3) Fewer internal delay damages.
The organization can enjoy these advantages:
(1) Reduced risk of market loss (i.e., opportunity
window) due to late arrival of the product.
(2) Reduced risk of being sued for late supply
of products; hence, reduced penalties for
non-compliance with contract demands.
(3) Reduced risk of impairing the firm’s
reputation as a reliable software developer.
(4) Reduced risk of requesting a budget
supplement.