<- previous index next ->
Almost all software producing organizations have some form
of software quality assurance.
Software Quality Assurance, SQA, consists of a means of monitoring
the software engineering processes and methods used to ensure
software quality. The means and methods can vary from a small
amount of monitoring to almost microscopic observation of every
detail in every step of the software development process..
Some Software Quality Assurance Organizations, SQAO, are guided
by ensuring conformance to one or more standards, such as
ISO 9000 series or CMU developed Capability Maturity Model
Integration, CMMI. Some software development requires
conformance to specific standards.
The SQAO has management, professionals with various expertise,
staff, tools, and Software Quality Plan. For the CMSC 345
Project, we will cover and support some of the CMMI.
Management has a standard statement:
"If you can not measure it, you can not manage it."
An example of a tool my section wrote, for computing
cyclomatic complexity, the testing aspects to be
covered later, is STEST.
stest.shtml
Our Software Quality Assurance Organization has the
following task, for which they must keep records:
A new project is started, record its name and date
and any other available information.
The System Requirements Specification, SRS, must be
reviewed and the date of the review recorded.
There may be corrections required, these must
be recorded and the final SQA approval date recorded.
SQA keeps a copy of all documents and checks previous
documents for possible change when additional
documents are reviewed.
The System Design Document, SDD, must be reviewed
and the date recorded. There may be corrections required,
these must be recorded and the final SQA approval
date recorded. Rapid prototypes are shown to SQA, yet
not kept by SQA.
The User Interface Design Document, UI, must be
reviewed and the date recorded. There may be corrections
required and these must be recorded and the final SQA
approval date recorded.
At any time, any level of management may want a summary
of the projects SQA approvals and dates.
Now code is being produced that will be submitted as it
is coded, to the SQA approved configuration tool.
e.g. SVN, CVS, etc. covered in lecture 7.
Code Inspections are performed and some are by just the
development team, some may have a SQA person attend the
review, the final review prior to commit may be conducted
and recorded by SQA. There may be a style guide required
by SQA and checked by SQA. Style guides are covered
in lecture 4.
The development team submits the Code Inspection Report
Document, CIR, to SQA for approval. The approval date
and possible corrective action are recorded. There may be
quality defects that are counted and recorded.
Final testing of the product will be performed by the
development team and when they are satisfied, SQA will
witness the test procedure and possibly require
additional tests. Defects are counted and recorded.
The Testing Report Document, TR, is submitted for review
and the date recorded. As a part of the testing process,
SQA may have required metrics that must be measured.
Software Metrics are covered in lecture 5.
The product installation and use manual, Administrator
Manual, AM, is submitted to SQA for review and the
date of final approval is recorded. The product may
now be delivered to customers. A competitive product
may require benchmarks.
There may be a "ticket" system for customers to submit
defect reports. This would be maintained by SQA in order
to gather defect statistics. Acknowledged problems go
to the part of the team that will do the software maintenance.
The Software Quality Assurance Organization will provide
quality and time data to the marketing and proposal
organizations when when they are bidding new projects.
More information on the companies organization chart
will be covered later.
<- previous index next ->