chapter 5 infrastructure components part ii. 2 esgd5125 sem ii 2009/2010 dr. samy abu naser...

1

CHAPTER 5

Infrastructure Components

PART II

2ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

Procedures and work instruction. Quality support devices like templates and

checklists. Staff SQA training and certification

activities. Preventive and corrective actions. Software configuration management. Documentation and quality records

control.


Corrective and Preventive Actions (CAPA) - Definition

Corrective actions:A regularly applied feedback process that

includes collection of information on quality non-conformities, identification and analysis of sources or irregularities as well as development and assimilation of improved practices and procedures, together with control of their implementation and measurement of their outcome.



Preventive actions:A regularly applied feedback process that

includes collection of information on potential quality problems, identification and analysis of departures from quality standards, development and assimilation of improved practices and procedures, together with control of their implementation and measurement of their outcome.



Sources of CAPA information:Quality records, service reports, internal

quality audits, project risk reviews, software risk management reports, etc.


Corrective and Preventive Actions (CAPA) - Process

Successful operation of a CAPA process includes the following process: Information collection (CAPA sources)Analysis of informationDevelopment of solutions and improved

methods Implementation of improved methodsFollow-up.


Feedback on content and regularity of supply of process information

Feedback on outcomes of improved methods

Feedback on implementation of improved methods

Development process informationExamples:Design review reportsInspection reportsTest reportsSpecial reports of development failures and successes

Product and infrastructure information. Examples:Customer complaintsSoftware quality metrics and quality costs Internal quality audits Special reports of current operations failures and successes

Development of solutions and improved methods

Implementation of improved methods

Follow-up of implementation and outcomes of corrective and

preventive actions

Corrective actions

Preventive actions

Feedback on content and regularity of supply of product information

Analysis of collected information


Sources of CAPA information

Internal information sources

Software development process Software risk management reports Design review reports Inspection reports Walkthrough reports Experts’ opinion reports Test reviews Special reports on development failures

and successes Proposal suggested by staff members.

Software maintenance Customer applications statistics Software change requests initiated by

customer applications Software change requests initiated by

maintenance staff Special reports on maintenance failures

and successes Proposals suggested by staff members.

SQA infrastructure class of sources Internal quality audit reports External quality audit reports Performance follow-up of trained and

certified staff Proposals suggested by staff members.

Software quality management procedures class of sources

Project progress reports Software quality metrics reports Software quality cost reports Proposals of staff members.

External information sources Customer complaints Customer service statistics Customer-suggested proposals.


Analysis of collected information

Analysis involves: Screening the information and identifying potential

improvements. Analysis of potential improvements, to determine:

Expected types and levels of damage Causes of faults Estimate total damage expected and determine the priority

of each fault case.

Generating feedback on the content and regularity of information received from the designated information sources.


Development of solutions

Solutions to identified causes of recurrent software systems faults are required to:Eliminate recurrence of the types of faults

detectedContribute to improved efficiency by

enabling higher productivity and shorter schedules.


Development of solutions

Several directions for solutions are commonly taken: Updating relevant procedures. Ex: changes of the

maximum and minimum number of participants in a DR session, etc.

Changes in practices, including updating of relevant work instructions.

Shifting to a development tool that is more effective and less prone to the detected faults.

Improvement of reporting methods, including changes in report content, frequency of reporting and reporting tasks.

Initiatives for training, retraining or updating staff.


Implementation of the solutions

Relies on proper instructions and often training but most of all on the cooperation of the relevant units and individuals.


Follow-up of activities

Follow-up of the flow of development and maintenance CAPA records from various sources of information. enables feedback that reveals cases of no

reporting, low quality reporting – important details are incorrect/missing.

Follow-up of implementation. Indicate whether the designated actions have been

performed in practice. Follow-up of outcomes.

Assessment of how much CAPA actions have achieved the expected results.


Organizing for CAPA

Collecting CAPA records from the various sources.

Screening the collected information. Nominating ad hoc CAPA teams to tend to

given subjects or head the teams. Promoting implementation of CAPA Following up information collection, data

analysis, progress made by ad hoc teams, implementation as well as outcomes of improved CAPA methods.


Ad hoc CAPA teams

They regularly focus on: Analysis of the information related to the team’s

topic. Initiation of additional observations and inquiries. Identification of the causes for the faults. Development of solutions and the relevant CAPA. Preparation of proposed implementation revisions. Analysis of the CAPA implementation outcomes

and CAPA revision if necessary.


Configuration Management

Questions:What is the correct version of the software

module that I have to continue its coding?Who can provide me with an accurate copy

of last year’s version 4.1 of the TMY software system?

What version of the software system is installed at ABC Industries?

Etc..


Software configuration – Items and management

Software configuration item (SCI) or configuration item (CI):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 – Items and management

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, where the activities to be performed are controlled by software configuration management procedures. The software configuration versions are released according to the cited procedures.


Common types of SCI

Design documents SDP, SRD, PDD, CDD, STP, STPR, STR, etc.

Software code Source code, object code, prototype software.

Data file Test cases and test scripts, parameters, codes, etc.

Software development tools (the versions applied in the development and maintenance stages) Compilers and debuggers, application generators,

CASE tools.


SCI Version

PMT Version 6.0 January 6, 2002

SCI Version in the Release

PMT Version 7.0 January 22, 2003

SCI Version in the Release

SRD Ver. 1 Ver. 1

CDD Ver. 3 Ver. 4

STP Ver. 3 Ver. 4

SIP Ver. 2 Ver. 2

VDD Ver. 6 Ver. 7

Code Module 1 Ver. 3 Ver. 5



Test cases file Ver. 3 Ver. 4

CL compiler Ver. 5 Ver. 7

Software user manual Ver. 6 Ver. 7

Release and release date


Software configuration management (SCM) - Definition

SCM:An SQA component responsible for

applying (computerized and non-computerized) technical tools and administrative procedures that enable completion of the tasks required to maintain SCIs and software configuration versions.


Tasks of the SCM

Control software changeRelease of SCI and software

configuration versionsProvision of SCM information servicesVerification of compliance to SCM

procedures.


The software configuration authority

SCM procedures specify who is responsible for SCM issues.

This responsible usually assigned to a senior professional or a committee that been set-up to handle the SCM issues – software change control authority (SCCA) or software change control board (SCCB).

During the development phase, the project manager may be charged with the authority to carry out SCM responsibilities.


Software control change

Software change management controls the process of introducing changes mainly by doing the following:Examining change requests and approving

implementation of appropriate requests.Assuring the quality of each new version of

software configuration before it becomes operational.


Factors affecting approval of proposed changes

Expected contribution of the proposed change Urgency of the change Effect of the proposed change on project

timetables, level of service, etc. Efforts required in making the change

operational Required software quality assurance efforts Estimated required professional resources and

cost of performing the change.


Software change request (SCR) document - a template

1. Change principles• The initiator• The date the SCR was presented• The character of the change• The goals• The expected contribution to the project/system• The urgency of performance

2. Change details• Description of the proposed change• A list of the SCIs to be changed• Expected effects on other SCIs• Expected effect on interfaces with other software systems and hardware firmware• Expected delays in development completion schedules and expected disturbances

to services to customers3. Change timetable and resources estimates

• Timetable for implementation• Estimated required professional resources• Other resources required• Estimated total cost of the requested change.


Quality assurance of software changes

Quality assurance efforts are required at two levels:Quality assurance of each of the changed

SCIsQuality assurance of the entire new

software system version (that includes changed SCIs).


Quality assurance of the changes SCIs

Require preparation of a reviews and testing plan at a magnitude appropriate to the character of the change.

It is important that reviews and testing be carried out by professional testers and not by the SCI’s developer.

The process of reviews and testing, corrections and re-testing (regression testing) the change SCIs is expected to conclude with their approval.


Quality assurance of the entire new software system version

A new version of the software is considered to have been completed once the changed SCIs replace the former SCIs.

Many new versions, especially of complex software systems, actually fail.

The failures generally occur as a result of damage done to interfaces between the changed SCIs and other SCIs left unchanged and not retested because they were not expected to be affected by the changes performed.


Release of software configuration versions

The need to release a new software configuration control:Defective SCIsSpecial features demanded by new

customersThe team’s initiatives to introduce SCI

improvements.


Types of software configuration releases

Baseline versions Planned early, during a system’s development or operating stage. As part of the process, they are reviewed, tested and approved,

as their SCIs. They serve as milestones in the SDLC, and represent the

foundations for further system development. Intermediate versions

When problem arise that require immediate attention – an intermediate version of the software is often prepared.

Usually, serve only a portion of a firm’s customers, limited period, until replaced by a new baseline versions.

Can serve as a “pilot” to the next baseline version. Revisions

Introduce minor changes and corrections to a given SC version. In some cases, revisions are released before a new baseline

version is released.


Numeration conventions for identification of SCI and software versions

Decimal numeration Indicates the successive version and

revision numbers.Example: DD7 Ver.1.0, DD7 Ver.1.1, etc.


Software configuration management plans (SCMPs)

Objective: to plan ahead the schedule of baseline version

releases and the required resources to carry out all the activities required for the software configuration releases.

To enable one to follow up the progress of activities involved in software version release.

SCMPs are required during the development stage as well as the operation (maintenance) stage.


SCMP – the content

An overview of the software development project or existing software system.

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.


SCMP for the development stage

SCMP sets the release dates of baseline versions, which usually coincide with the conclusion of one or more of the following three events: the design stage, the coding stage and the system test stage – represent a segment of the entire system’s development plans, prepared at a project’s initiation.

Development process must be comply with the SCMP. All instructions and procedures necessary for

performing the SCM tasks are documented in the SCMP.

Responsibility – the project manager.


SCMP for the operation (maintenance) stage

Further releases of software baseline versions are required.

SCMP usually schedules new baseline releases periodically – annual/semiannual, which include corrected/new versions of SCIs.

Only SCIs for which changes have been completed and approved by the targeted release date can be included in new SC versions.


Software configuration evolution models

The linear evolution model Only one unique SC version serves all customer at

any given time. For system that is developed to serve a single

organization. Applied to popular software packages Uniform in structure.

The tree evolution model Several parallel versions are developed to serve the

needs of different customers. Applied in firmware configuration versions, where

each branch serves a different product or product line.

Ver 2.1 IN

Ver 2.0 BL

Ver 1.0 BL

Ver 2.2 IN

Ver 3.0 BL

Ver 4.0 BL

Ver 4.1 IN

Linear evolution model

Ver a1.0 BL

Ver e1.1 BL Ver c2.0 BL

Ver c1.1 BL

Ver d1.1 IN

Ver d1.0 BL Ver e1.0 BL

Ver b1.0 BL Ver c1.0 BL

Ver b1.1 IN

Tree evolution model

General

Printer

Black printer

Color printer

Printer- fax


Identification and installations Release version and revision number, including date List of installations where the release was installed

Configuration of the released version List of SCIs (including SCI’s version) in the released

software version List of hardware configuration items required for operating the

specified version List of interfacing software and hardware systems Installation instructions for the new release

Software configuration release documentation – VDD template


Changes in the new version Previous software configuration version List of SCIs that have been changed, new SCIs, and deleted

SCIs Short description of introduced changes. Operational and other implications of changes in the release.

Further development issues List of software system problems that have not been solved in

the new version. List of delayed SCRs and proposals for development of the

software system.

Software configuration release documentation – VDD template (cont..)


Provision of SCM information services

The SCM is required to provide information to professionals, mainly developers, maintenance teams and customer representatives, who have requested that changes be introduced in a software system.

The information provided may be classified into information related to software change control and information dealing with SCI and software configuration versions: Information related to software change control Information about SCIs and software configuration

versions.


Information related to software control change

Change request status information – based on records for every submission of an SCR and the decisions made.

Change order progress information – based on records for every approved SCO, its schedule, implementation progress and test results, including the information about delays in performance.


Information about SCIs and software configuration versions

Accurate copies of SCI versions (code SCIs, document SCIs, etc.) and entire software configuration versions.

Full reports of changes between successive releases (versions and/or revisions) of code SCIs and between successive releases of other types of SCIs.

Copies of SCI version documentation and software configuration version documentation (VDDs).

Detailed version and revision history for SCIs and software configurations.

Progress information about planned versions and releases

Information correlated about versions installed at a given site and about the site itself.

List where a given software configuration version is installed.


Software configuration management audits – report on:

Percentage of unapproved changes introduced in the system during development or operation.

Percentage of SCOs not carried out according to instructions and not fully complying with procedures.

Percentage of design reviews and software tests of changed SCIs that have not been performed according to the relevant procedures.

Percentage of SCOs that have been completed on schedule. Percentages of cases where SCIs affected by changes have not been

checked, with some necessary changes not implemented. Percentages of properly documented new SCIs and software

configuration versions. Percentage of properly documented installations of new software

configuration versions. Percentage of cases of failure to transmit all versions-related information

to the customer. Number of cases recorded annually where the SCI work coordination

mechanism failed (i.e., did not prevent different teams from simultaneously introducing changes in the same SCI).


Computerized tools for managing software configuration

Application of tools in SC differs in their level of comprehensiveness, flexibility of application and ease of use.

Benefit of using computerized tools: Able to comply with the required level of accuracy and

completeness of information, and with the required level of availability.

Operate the mechanisms coordinating the work on an SCI’s changes and prevent different teams from simultaneously introducing changes in the same SCI.

Secures the code version and documentation files versions by protecting them from any changes, deletions and other damages.

Activates back-up procedures required for safe SCM file storage.


Documentation Control

Controlled document:A document that is currently vital or may

become vital for the development and maintenance of software systems as well as for the management of current and future relationships with the customer.

Its preparation, storage, retrieval and disposal are controlled documentation procedures.


Documentation Control

Quality record:A special type of controlled document.Customer-targeted document that may be

required to demonstrate full compliance with customer requirements and effective operation of the software quality assurance system throughout the development and maintenance processes.


Documentation control - objectives

To assure the quality of the document. To assure its technical completeness and compliance

with document structure procedures and instructions (use of template, proper signing, etc).

To assure the future availability of documents that may be required for software system maintenance, further development, or responses to the customer’s (tentative) future complaints.

To support investigation of software failure causes and to assign responsibility as part of corrective and other actions.


Typical controlled documents (including quality records)

Pre-project documents Contract review report, negotiation meeting minutes, development

contract, subcontracting contract, software development plan, etc. Project life cycle documents

SRD, preliminary design document, critical design document, database description, DR report, STP, etc.

SQA infrastructure documents SQA procedures, template library, SQA form library, etc.

Software quality management documents Progress report, software metrics reports, etc.

SQA audit documents Management review report, internal quality audit report, etc.

Customer documents Software project tender documents, customer’s software change

requests, etc.


Typical component of documentation control procedures

Definition of the list of the document typesand updates to be controlled (some classified as quality records).

Document preparation requirements. Document approval requirements. Document storage and retrieval requirements,

including controlled storage of document versions, revisions and disposal, document security.


Authority for controlled document and quality record list

Deciding which document type is to be categorized as a controlled document and which controlled document types are to be classified as quality records.

Deciding whether the level of control is adequate for each document type categorized as a controlled document.

Following up of compliance with the controlled document types lists. This can be incorporated in the internal quality plan.

Analyzing follow-up findings and initiating the required updates, changes, removals and additions to the controlled documents types list.


Controlled document preparation

Creation of new document or revision of an existing document focus on completeness, improved readability and availability.

This relies in the document: Structure – may be free or defined by a template. Identification method – unique identity based on

version/revision code/number. Standard orientation and reference information –

support future access.


Content for orientation and reference information

The author Date of completion Person(s) who approved the document, including

position Date of approval Signature of the author and approver Descriptions of the changes introduced in the new

release List of former versions and revisions Circulation list Confidentiality restrictions.


Issues of controlled document approval

Position of the person(s) who can approve a document or document type Can be granted by a person, several persons, or

committees. Have sufficient experience and technical expertise.

The approval process Aim at detecting and preventing professional

inadequacies together with deviations from the document template.


Issues of controlled document storage and retrieval

Document storage Number of copies, unit responsible, storage

medium. Circulation and retrieval of documents

Instruction for circulating a new document, recipients, efficient and accurate retrieval of copies.

Document security, including document disposal requirement Provide restricted access, prevent unauthorized

changes to stored documents, provide back-up, determine storage period.

chapter 5 infrastructure components part ii. 2 esgd5125 sem ii 2009/2010 dr. samy abu naser...

Documents