INFRASTRACTURE AND SUPPORT ACTIVITIES

2020
SOFTWARE INFRASTRACTURE
COMPONENTS
 Infrastructure components are the main tools

employed to prevent software errors and

support the quality level of the entire

organization.

 Goal of infrastructure are the avoidance of

software faults , lowering faults rates and

improving the productivity.

SOFTWARE INFRASTRACTURE
COMPONENTS
are:
1. Procedures and Work instruction
2. Staff training and certification activities

3. Corrective and preventive actions

4. Software configuration management
5. Documentation and quality records
control.
1. Procedures and Work
instruction
Definitions: A conceptual hierarchy of
procedures and work instructions:

A. Procedures, as transmitted in
documents, are the detailed
activities or processes to be
performed according to a given
method for the purpose of
accomplishing a task
B. Work instructions are used mainly
in cases where a uniform method
of performing the task throughout
the organization is either
A. Procedures
Need for SQA procedures: Five W’s: issues resolved by procedures

• Performance of tasks, processes or activ • What activities have to be performed?

ities in the most effective and efficien
• How should each activity be performed?
t way without deviating from quality req
• When should the activity be performed?
uirements.
• Where should the activity be performed?
• Effective and efficient communication be
tween the separate staffs involved in th • Who should perform the activity?
e development and maintenance of softwar
e systems.

• Simplified coordination between tasks an

d activities performed by the various bo
dies of the organization.
A. Procedures
Table of contents for procedures Content of procedure manual:

• Introduction
• Types of software development and mainten
• Purpose
ance activities.
• Terms and abbreviations
• Range of activities belonging to each act
• Applicable documents
• Method ivity type.

• Quality records and documentation • Range of customers and suppliers.

• Reporting and follow-up
• Responsibility for implementation
• List of appendices
( sections included only if applicable)
B. Work Instructions
• Work instructions deal SQA work instructions subjects -
with the application of example:
procedures, adopted to
Departmental work instruction: Project management work
the requirements of a s
instruction:
pecific project team, c  Audit process for new s/w deve
ustomer, or other relev lopment subcontractors  Coordination and cooperation
ant party.  Priorities for handling correc with the customer.
• One can add, change or tive maintenance task  Weekly progress reporting by
cancel work instruction  Annual evaluation s/w developm team leaders.
s without altering the
ent subcontractors  Special design report
respective procedures.
templates and their
 On-the-job instruction and fol
application in the project.
low-up for new team members
 Follow-up of beta site
 Design documentation templates
reporting.
and their applications
 Monthly progress reporting to
 C++(or other language) program
the customer.
ming instructions.
 Coordination of installation
and customer team
instructions.
Supporting Quality Devices
TEMPLATES:
• a format (especially tables of contents)
created by units or organizations, to be
applied when compiling a report or some
other type of document.
Advantages:
1. Facilitates the process of preparing doc
uments
2. Facilitates review of documents
3. Ensures that documents prepared by the d
eveloper are more complete
4. Provides for easier integration of new t
eam members
5. Enables easier location of the informati
on
CHECKLIST:
• the list of items specially constructed
for each type of document, or a menu
of preparations to be completed prior to
performing an activity (e.g., installing a
software package at the customer site).
Advantages:
1. Helps developers carrying out self-
checks of documents or software code
2. Assists developers in their preparations
for tasks
3. Assures completeness of document
reviews by review team members
4. Provides for easier integration of new
team members
5. Facilitates improves efficiency of review
2. Staff Training and
Certification
Objectives:

• To develop the knowledge and skills to new staff

• To assure conformity to the organization's standards for software
products (documents and code)
• To update the knowledge and skills of veteran staff in response to
developments in the organization
• To transmit knowledge of SQA procedures
• To assure that candidates for key software development and
maintenance positions are adequately qualified
2. Staff Training and Certification
Process
2. Staff Training and
Certification
Determining training and updating
n e e d s:
 Training and updating needs are dete
rmined by comparison of the staff’s
current knowledge with the updated k
nowledge requirements.
 The type of training is adapted to t
he needs of three different groups o
f staff:
 Training: for new employees, acco
rding to their designated assignm
ent
 Retraining: for employees assigne
d to new positions or receiving n
ew assignments
 Updating: for staff members as de
manded by their position.
Defining positions requiring
certifications:
 Assignment of personnel to key
positions in software development
and maintenance organizations
requires extreme care.
 Examples of positions requiring
certification of their Expertise are:
 Software development team
leader,
 Programming team leader,
 Software testing team leader,
 Software maintenance technician
 Quality inspector
2. Staff Training and
Certification
Planning the certification processes:
 A certification committee defines th
e list of positions that require cer
tification.
 The list of positions that require c
ertification differs by firm or orga
nization.
 The details of the certification pro
cess reflect the organization specia
l uniqueness, areas of specializatio
n, software development and maintena
nce tools, customers and so on..
Typical Certification Requirements:
 A certification process requires
meeting some or even all of the
following requirements:
 Professional education
 Internal training courses
 Professional experience in the
organization (may be replaced by
experience in other
organizations)
 Assessment of achievements
and abilities
 Evaluation by the candidate’s
direct superior (often by
completion of a special
questionnaire)
3. Corrective and Preventive
Actions
Definition:
• Defect correction is a limited acti
vity directed toward immediate solu
tion of defects detected in a proje
ctor a software system.
• Corrective and preventive actions a
re wider in scope; they are meant t
o initiate and guide performance of
organization-wide actions that will
eliminate the causes of known or po
tential faults.
• The main objective is the completio
n of functional and managerial requ
irements while reducing the costs o
f carrying out software development
, maintenance and quality assurance
activities.
5 main approaches for introduction of CAPA:
 Updating relevant procedures
 Changing software development or
maintenance practices and updating
work instructions
 Changing current to more effective
software development tools that are
less prone to faults
 Improving reporting methods by
revising task content and reporting
frequencies. This approach is meant
to achieve earilier detection of faults
and thus reduce damages
 Initiating training, retraining and
updating of staff
 3. Corrective and Preventive
Actions
Activities of CAPA:

A. Information B. Analysis of collected D. Follow-up of activities

collection information
- Four main internal sources of • Screening the information and • Follow-up of the flow of
information are the identifying development and
(1)Software development • potential improvements. maintenance CAPA records
process • Analysis of potential • Follow-up of implementation.
(2) Software maintenance improvements. • Follow-up of outcomes.
(3) SQA infrastructure and C. Development
• Generating of
feedback
solutions and their
(4) Software quality implementation
management procedures. • Solutions are required to:

- External sources of information • Eliminate return of the

are mainly customers’ types of faults detected

application statistics and • Contribute to improved

customer complaints. efficiency by enabling

3. Corrective and Preventive
Actions Process
4. Software Configuration
Management
Definition:
• An approved unit of software code,
a documentor piece of hardware that
is designed for configuration manag
ement and treated as a distinct ent
ity in the software configuration m
anagement process.
Tasks of Software Configuration Manage
ment:
Control software change
Release of SCI and software configura
tion versions
Provision of SCM information services
Verification of compliance to SCM pro
cedures
 Software Configuration Item (SCI) -
an approved unit of software code, a
document or piece of hardware that
is designed for configuration
management and treated as a
distinct entity in the software
configuration management process.
 Software Configuration Item Version
(SCI version) - the approved state of
an SCI at any given point of time
during the development or
maintenance process
 Software Configuration Version - an
approved selected set of
documented SCI versions, that
constitute a software system or
document at a given point of time,
4. Software Configuration
Management
Types of Software Configuration Item (SCI):
1. Design Documents
2. Software Code
i . Source code
i i . Object code
i i i . Prototype software
3. Data Files
i . Test cases and test scripts
i i . Parameters, codes, etc.
4. Software Development Toolss (the ve
rsions applied in the development a
nd maintenance stages)
i . Compilers and debuggers
i i . Application generators
i i i . CASE tools
Design Documents:
 Software development plan (SDP)
 System requirement document
 Software requirement document
(SRD)
 Interface design specifications
 Preliminary design document (PDD)
 Critical design document (CDD)
 Database description
 Software test plan (STP)
 Software test procedure (STPR)
 Software test report (STR)
 Software user manual
 Software maintenance manual
 Software installation plan (SIP)
 Software maintenance request
(including problem reports)
 Software change request (SCRs) and
software change order

4. Software Configuration
Management
Configuration Management Version:
A software configuration version is an
approved set of the SCI versions that
constitute a documented software syste
m at a given point of time. The respec
tive activities are controlled by soft
ware configuration management procedur
es.
The need to release a new software con
figuration version:
1. Defective SCIs
2. Special features demanded by new cu
stomers
3. Team’s initiatives to introduce SC
I improvements
Design Documents:
 Software development plan (SDP)
 System requirement document
 Software requirement document
(SRD)
 Interface design specifications
 Preliminary design document (PDD)
 Critical design document (CDD)
 Database description
 Software test plan (STP)
 Software test procedure (STPR)
 Software test report (STR)
 Software user manual
 Software maintenance manual
 Software installation plan (SIP)
 Software maintenance request
(including problem reports)
 Software change request (SCRs) and
software change order

4. Software Configuration
Management
Software Configuration Managment Plan (SCMP)

The plan includes:

A list of scheduled baseline version releases.
A list of SCIs (documents, code, etc.) to be included in each version.
A table identifying the relationship of software development project plans and
maintenance plans to scheduled releases of new SCIs or SCI versions.
A list of assumptions about the resources required to perform the SCMP.
Estimates of the human resources and budget needed to perform the SCMP.
4. Software Configuration
Management
Software Configuration Evolution Models:

Linear Evolution Tree Evolution

Model Model
4. Software Configuration
Management
Software Configuration Release Documentation:

a. Identification and installations c. Changes in the new version

• Release version and revision number, includi • Previous software configuration version
ng date
• List of SCIs that have been changed, new
• List of installations where the release was
SCIs, and deleted SCIs
installed
• Short description of introduced changes.
b. Configuration of the released version
List of SCIs (including SCI’s version) in the relea • Operational and other implications of
sed software version changes in the release.
List of hardware configuration items required for op
d. Further development issues
erating the specified version
List of interfacing software and hardware systems • List of software system problems that have
Installation instructions for the new release not been solved in the new version.
• List of delayed SCRs and proposals for
development of the software system
5. Documentation Control
Definitions:

Controlled document
A document that is currently vital or may become vital for the development and m
aintenance of software systems as well as for the management of current and futu
re relationships with the customer. Hence, its preparation, storage, retrieval a
nd disposal are controlled by documentation procedures.
Quality record
A quality record is a special type of controlled document. It is a customer-targ
eted document that may be required to demonstrate full compliance with customer
requirements and effective operation of the software quality assurance system th
roughout the development and maintenance processes
5. Documentation Control
Objectives for managing controlled documents:

To assure the quality of the document.

To assure its technical completeness and compliance with document structure p
rocedures nand instructions
To assure the future availability of documents that may be required for softw
are system maintenance, or responses to the customer’s future complaints.
To support investigation of software failure causes as part of corrective and
other actions
5. Documentation Control
Typical Components of Documentation Control Procedures:

Definition of the list of the document types and updates to be controlled (so
me classified as quality records).
Document preparation requirements.
Document approval requirements.
Document storage and retrieval requirements, including controlled storageof d
ocument versions, revisions and disposal, document security.
5. Documentation Control
Decision issues regarding controlled documents list

Deciding which document type be categorized as a controlled document and whic

h controlled document types be classified as quality record.
Deciding about the adequate level of control for each controlled document typ
e.
Following up of compliance with the controlled document types list.
Analyzing follow-up findings and initiating the required updates, changes, re
movals and additions to the controlled documents types list
https://www.slideshare.net/LuthfiaUlinnuha/software-quality-infrastructure

https://www.uopmoodle.com/moodle/mod/resource/view.php?id=1927&forceview=1

https://slideplayer.com/slide/10434669/