Fault Generation Tool
Software Qualification Plan
1. Purpose
This plan
is a proposal for the Software Quality Assurance (SQA) System of the fault
generation tool project, an organizational structure and series of activities
that must help ensure a persistent high quality for the software
developed.
This plan
defines the activities performed to provide assurance that the fault generation
tool software-related items delivered to users conform to the established and
technical requirements. This plan also
identifies the SQA responsibilities of the project developer; describes how the
project will be audited to ensure that the policies, standards, practices,
procedures, and processes applicable to the project are followed; and identify
the SQA work products.
This plan
applies to all the software and associated documents used in the production of
fault generation tool project. This plan
applies to all the passes of software development life cycle, up to and
including the time of delivery of the software.
2.
Reference Documents, Definitions, Acronyms
Pressman, Roger S. "Software
Engineering: A Practitioner's Approach". Fifth Edition, Mc
IEEE Std
829-1983, "IEEE Standard for Software Test Documentation". 1983
Edition, IEEE, 1983.
IEEE Std
828-1998, "IEEE Standard for Software Configuration Management
Plans". 1998 Edition, IEEE, 1998.
IEEE Std
730-1998, "IEEE Standard for Software Quality Assurance Plans". 1998
Edition, IEEE, 1998.
IEEE Std
730.1-1995, "IEEE Guide for Software Quality Assurance Planning".
1995 Edition, IEEE, 1995.
2.2.
Glossary of Terms
Refer to Appendix A to a detail
list of common terms
3.
Project Management
Committee: Dr. David A, Gustafson, Dr. Maria, Dr. Scott A, DeLoach.
Major Professor: Dr. David A, Gustafson
Developer: Hong Zhang
3.2.
Roles and Responsibilities
3.2.1.
Developer
The developer will be responsible
for project specification, design and implementation under the supervision of
the major professor and report to all the committee members in the form of
three presentations with one at end of each phase.
3.2.2.
Major Professor
The major professor suggests the
topic of the project and general requirements,
supervises and audits the whole development process of the project.
3.2.3.
Committee
The committee will oversee and
review the work performed by the developer, provide feedback and advice, and
audit the whole development process during the three presentations of the
project.
The developer should finish all
detail tasks described in project plan which are divided into three major phases:
project requirement, project design, project implementation and testing.
In phase 1, the developer should
conclude project overview, cost estimate, and project plan. In phase 2, the developer should conclude
designs which include object model and sequence diagram, compose SQA plan and
test plan, complete formal specification.
In phase 3, the developer should complete source code, perform testing
on source code, project evaluation, and complete all documentation.
4.
Documentation
The documentation will be created
during the development of the fault generation tool project. Purpose of the documentation is to support a
number of activities which embrace management, design, development, and testing
during the development of
the fault generation tool.
4.1.1.
Project Overview
This is a vision document which includes
an overview of the fault generation tool project, its purpose, goals
risks, constraints, and direction. It
also discusses the main program features, quality attributes.
4.1.2.
Engineering Notebook
Content of the engineering book
are:
·
Project Plan and Gant Chart
·
Cost Analysis
·
Time Log
·
Overview of project progress against schedule for
each phase described in Project Plan
4.2.
Functional Specifications Documentation
4.2.1.
Purpose
The purpose of this document is to
specify the functions and requirements for the fault generation tool. This will be used as a basic resource to know
what is expected from the project and how the components cooperate with each
other in the project.
4.2.2.
Content
·
Software Requirements Specification
·
Use cases
·
Object model
4.3.
Architecture Design Documentation
4.3.1.
Purpose
Purpose of this document is to
describe the overall structure of fault generation tool components
and to be used by developer to plan the architecture of the project before and
while the software is being developed.
4.3.2.
Content
UML Object
Model.
4.4.
Software Verification and Validation
Documentation
4.4.1.
Purpose
The purpose of this document is to
develop and report formal procedures for the verification and validation of all
fault generation tool project work products (documentation and
software). Implementation of these
procedures will deal with requirements specification.
4.4.2.
Content
·
Formal Requirements Specification (in OCL)
·
Test Plan
·
Project Evaluation
4.5.
User and Operations Documentation
User and Operations documentation
content of:
·
Source code, testing code
·
User Manual
5.
Standards, Practices, Conventions, and Metrics
The Software Requirements
Specifications (SRS) and SQA Plan (SQA) will be based upon IEEE Software
Engineering Standards.
Source code will be commented and
will follow the guidelines in the C++ Coding Standards and Style Guide.
All design artifacts will be in the
form of standard UML or Unified Process diagrams. The model will be kept in a Rational Rose
model and will be posted on the project web site.
Formal Specifications will be
expressed using Object Constraint Language (OCL)
The size of the software is
measured by Source Line of Code (SLOC).
Cocomo model are
used to predict the Programmer-month (PM) and total development time
(TDEV). Both are PM and TDEV are used to
estimate the developer productivity in fault generation tool project.
IEEE 730,
Standard for Software Quality Assurance Plans
IEEE 828,
Standard for Software Configuration Management Plans
IEEE 829,
Standard for Software Test Documentation
IEEE 830,
Recommended Practice for Software Requirement Specification
IEEE 1028,
Standard for Software Review and Audit
IEEE 1042,
Guide to Software Configuration Management Plans
There will be three formal
presentations prepared by developer and evaluated by the committees at the end
of each phase of development as described in project plan.
The developer will develop a
software test plan which will outline the test activities, schedules and
resources required for testing and how the tests will be implemented.
8.
Problem Reporting and Corrective Action
Errors, defects and issues that are
encountered during the process of development should be documented, tracked to
closure, corrected, and used for process improvement.
·
C++ is used as the development language for the
fault generation tool project
·
Unix is used
for its high speed and accuracy.
·
Rational Rose serves as tool for UML model design
N/A
11. Risk
Management
N/A
Appendix A - Glossary of Terms
A
Acceptance Criteria The list of requirements that
must be satisfied prior to the delivery of the product.
Acceptance Test Formal user performed testing
performed prior to accepting the system (sometimes called client acceptance
test or user acceptance test).
Action Plan - A plan that describes what needs
to be done and when it needs to be completed. Project plans are action plans.
Activity - A specific project task, or
group of tasks, that require resources and time to complete.
Application Generic term for a program, or
system, that handles a specific business function.
Application Software A
complete, self-contained program that can perform work for a user. This is in
contrast to system software such as an operating system, server processes, and
libraries that exist in support of application software.
Architecture Imposes order and makes
interconnections possible. Generally defined as an intermediate step between
initial requirements and business functional specifications during which the
entire complex of hardware, software, and design considerations are viewed as a
whole. Refers to a blueprint for evolving a technical
infrastructure.
Assessment A general term for the formal
management review of a process.
Audit - A formal and detailed examination of the
progress, costs, operations, results, or some other aspect of a project or
system performed by an independent party.
Availability The portion of time that a system that is scheduled to operate actually
can be used as expected.
B
Budget A
planned sequence of expenditures over time with costs assigned to specific
tasks and activities.
C
Checkpoint A point
in the development process at which project state, status, and results are
checked, recorded, and measured.
Client/Server System Primarily a relationship between
processes running on separate machines. A client initiates the
dialog by sending requests to the server asking for information or action.
Configuration
Management Methodical storage and recording of all software
components and deliverables during development.
Control - A process
for assuring that reality, or actual performance, meets expectations or plans.
Cost / Benefit Analysis A formal
study in which the development, execution, and maintenance costs for a project
are matched against the anticipated value of the product.
Critical Activity - A task,
activity, or event that, if delayed, will delay another important event -
probably the completion of the project or a major milestone in the project.
D
Data
Describes the numbers, text, graphics, images, and voice stored in a form that
can be used by a computer.
Deliverable A tangible, physical object that
is the output of a software development task.
Design The
tasks associated with specifying and sketching the features and functions of a
new application prior to coding.
Document of
Understanding A formal agreement between two parties. A contract which is sometimes referred to as a Statement of Work
(SOW).
Documentation The
printed and displayed materials which explain an application to a user.
Duration - The
period of time over which a task takes place. Duration establishes the schedule
for a project.
E
Effectiveness - A measure
of the quality of attainment in meeting objectives.
Efficiency - A measure
of the volume of output received for the input used.
Effort - The
amount of work or labor (in hours or workdays) required to complete a task.
Environment The set
of tools and physical surroundings in which software is developed.
Estimate A
predicted total of expenditures required to complete a task, activity, or
project.
G
Gantt Chart A method
of displaying overlapped and partially concurrent activities by using
horizontal lines to reflect the time required by each activity. The chart,
named for Henry Lawrence Gantt, consists of a table of project task information
and a bar chart that graphically displays the project schedule to be used in
planning and tracking.
Graphical User
Interface (GUI) A manner of presentation that makes use of
windows, icons, menus, pointers, and scroll bards.
H
Hardware Physical
equipment used to process, store, or transmit computer program data.
I
Independent Review A formal
examination of a project conducted by an organization other than the
development organization.
Information The
meaningful interpretation of data.
Integration Describes
the work, or device, required to connect two different systems that were not
originally designed to work together.
Integration Test Testing
in which software components, hardware components, or both are combined and
tested to evaluate the interaction between them.
Interface A
connection between two devices or systems.
Issue A
problem to be solved or a decision that has not been made.
M
Maintenance Refers
to the ongoing activity that keeps software functioning in a technical and
business environment (production).
Methodology A set of
formal protocols followed when performing a task.
Middleware Software
that hides the complexity of the networked computing environment from the users
and application programmers.
Milestone A major
checkpoint in the activities involved in a project. A clearly
defined point in a project that summarizes the completion of a related set of
tasks.
Model - A way of
looking at reality, usually for the purpose of abstracting and simplifying it
to make it understandable in a particular context.
N
Network
Describes the physical hardware and software connections between computers
allowing information to be shared and electronic communications to take place.
N-tier Architecture
Describes a method for dividing an application into a series of distinct layers
to provide for ease of maintenance and flexibility.
O
Operating System System
software that controls data storage, input and output to and from the keyboard,
and the execution of applications written for it. It performs base services:
prioritizing work, scheduling, memory management, etc.
P
Path - A
sequence of lines and nodes in a project network.
PERT Project Evaluation and Review Technique - The PERT method
uses the concepts of milestones, activities, and slack time to calculate the
critical path. The chart, which resembles a flow chart, depicts a box to
represent each project task and a line connecting two boxes to represent the
relationship between tasks.
Phases The
divisions of a software development life cycle into discrete stages (e.g.,
requirements, design, code, test, etc.).
Planning Project A
project intended to gather, or predict, the sequence of activities and
resources needed to complete a work effort.
Platform The
hardware and support software with which a program is intended to operate.
Precedence - When one
task must be completed before another task can be started, the first task is
said to have precedence over the other.
Process The step
by step sequence of activities (systematic approach) that must be carried out
to complete a project.
Programming The art
of writing, in a computer understandable language, a set of instructions that
produces software.
Project The
combined resources (people, machines, materials), processes, and activities
that are dedicated to building and delivering a product to a customer.
Project Duration - The time
it takes to complete the entire project.
Project Management - The
combination of systems, techniques, and people required to successfully
complete a project on time and within budget.
Project Plan A formal
document that describes the technical and management approach to be followed
for a project.
Protocol A set of
rules and specifications that describes how a piece of software will behave and
how other pieces of software must behave in order to work with the first piece
of software.
Q
Quality (Product) -
Conformance to business functional requirements with defect-free products.
Quality reflects both the completeness of software or system features and
functions, and error-free operation.
Quality (Process)
Verification and validation to established policies, standards, procedures and
guidelines for software development.
Quality Assurance Within
the State of
R
Regression Test
Selective re-testing to detect errors or faults introduced during modification
of a system.
Relational Database A
collection of data that is organized into tables so that relationships between
and among data can be established.
Requirements The
statement of needs by a user that triggers the development of a program,
system, or project. May be called business functional
requirements or requirement specifications.
Risk The
probability that a project will experience undesirable events, which may
create, cost overruns, schedule delays, or project cancellation. The identification, mitigation, tracking, and management of those
elements creating the risk situation.
Risk Analysis - An evaluation of the feasibility or
probability that the outcome of a project will be the desired outcome.
S
Scalable A term describing an architecture
or software that can handle expansion in the use as the need arises without
adversely impacting systems management and operations.
Scope - The
magnitude of the effort required to complete a project.
Server A
computer on a network that makes applications, print services, data, and
communications available.
Software Computer
programs, systems, and the associated documentation that describes them.
SDLC - Software
Development Life Cycle The period of time that begins with the
decision to develop a software product and ends when the software is delivered.
Software Development Process The process by which user needs
are translated into a software product.
Specifications General
term for the wide variety of paper-based descriptions of a program or system.
Standalone
Describes a computer workstation where the computer is not connected to any
other computer on a network.
System A linked
collection of programs, or components, that perform a
generic business or technical function.
System Test The final stage of testing on a completed project
(prior to client acceptance test) when all hardware and software components are
put together and tested as a whole.
T
Task - A
cohesive unit of work on a project (usually 40 to 80 hours of effort).
Task Description - A
description that defines all the work required to complete a project task or
activity including input, output, expected results, and quality specifications.
Test Plan A document that describes the
scope, approach, resources, and schedule of intended test activities.
Testing The set
of defect removal tasks that include execution of all, or part, of an
application on a computer.
U
Unit Test - The testing carried out personally by
individual programmers on their own code.
V W
Work Breakdown
Structure (WBS) A formal analysis of the activities, tasks, and
sub-tasks that must be accomplished to build a software project. A product or
activity oriented hierarchy tree depicting the elements of work that need to be
accomplished in order to deliver a product.
Workstation Any
machine with all of its installed storage, processing, and communications that
can be either standalone or networked.