STQA

147
CSE526 STQA From Lec 1 to Lec 16 Manpreet Kaur UID-15387 Astt. Prof CSE/IT

description

Software quality

Transcript of STQA

Page 1: STQA

CSE526 STQAFrom Lec 1 to Lec 16

Manpreet Kaur UID-15387

Astt Prof CSEIT

2

The uniqueness of software quality assurance

DO you think that there is a bug-free software

Can software developers warrant their software applications and their documentation from any bugs or defects

What are the essential elemental differences between software and other industrial products such as automobiles washing machines etc

3

The essential differences between software and other industrial products can be categorized as follows

1 Product complexity of operational modes the product permit

2 Product visibility SW products are invisible

3 Product development and production process

4

What is Software IEEE Definition

Software Is

Set of Computer programs procedures and possibly associated documentation and data pertaining to the operation of a computer system

5

IEEE Definition is almost identical to the ISO def ( ISOIEC 9000-3 ) Computer programs (ldquoCoderdquo) Procedures Documentation Data necessary for operation the SW system

6

So we can saySoftware quality assurance always includes Code quality The quality of the documentation And the quality of the necessary SW data

7

SW errors faults and failures

An error can be a grammatical error in one or more of the code lines or a logical error in carrying out one or more of the clientrsquos requirements

Faults Most of time Caused by error SW failures that disrupt our use of the software

8

The relationship between SW faults amp SW failures

Do all SW faults end with SW failures The answer is not necessarily The SW fault becomes a SW failure only when it is

activated

9

Classification of the causes of SW errors SW errors are the cause of poor SW quality SW errors can be

Code error Documentation error SW data error

The cause of all these errors are human

10

The nine causes of software errors1 Faulty requirement definition2 Client-developer communication failures3 Deliberate deviation from SW requirements4 Logical design errors5 Coding errors6 Non-compliance with documentation and coding

instructions7 Shortcomings of the testing process8 Procedure errors9 Documentation errors

11

Faulty requirement definition

1 Erroneous definition of requirements

2 Absence of vital requirements

3 Incomplete definition of requirements

4 Inclusion of unnecessary requirements

12

Client-developer communication failures Misunderstandings resulting from defective

client-developer communications Misunderstanding of the clientrsquos requirements

changes presented to the developer In written forms Orally Responses to the design problems others

13

Deliberate deviation from SW requirements

The developer reuse SW modules taken from the earlier project

Due to the time budget pressure Due to the unapproved improvements

14

Logical design errors This is come from systems architects system

analysts SW engineers such as Erroneous algorithms Erroneous definition of boundary conditions

15

Coding errors Misunderstanding the design documentation errors in the prog Lang Errors in the application of CASE and other

dev Tools

16

Non-compliance with documentation and coding

Team members who need to coordinate their own codes with code modules developed by non-complying team members

Individuals replacing the non-complying team member will find it difficult to fully understand his work

17

Shortcomings of the testing process Incomplete testing plans Failures to document and report errors and faults Incomplete correction of detected errors

5

QUALITYQUALITY

Quality refers to any measurable characteristics such as correctness maintainability portability testability usability reliability efficiency integrity reusability and interoperability

19

Software quality - Definition IEEE1 The degree to which a system component or

process meets specified requirements

2 The degree to which a system component or process meets customer or user needs or expectations

20

Software Quality Pressmanrsquos def

Conformance to explicitly stated functional and performance requirements explicitly documented standards and implicit characteristics that are expected of all professionally developed software

21

Software Quality Assurance The IEEE Definition

SQA is

1 A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements

SQA What is SQA

SQA is the process of assuring people that

every effort has been made to ensure that

software products have the desired level of

reliability maintainability usability

SQA What is Software (System) Quality

Absence of defects

Fitness for use

Meets specifications

Adherence to CMM or ISO quality standards

Reliable Maintainable Useable

SQA An SQA Program

Minimizing number of defects in delivered sw

Creating mechanisms for controlling software

development and maintenance so that costs and

schedules can be met

Making certain that the delivered product can be

used in its intended marketplace

Improving the quality of future products

25

Software Quality Assurance Vs Software Quality Control

Quality Control a set of activities designed to evaluate the quality of a developed or manufactured product It take place before the product is shipped to the client

Quality Assurance the main objective is to minimize the cost of guaranteeing quality by a variety of activities performed throughout the causes of errors and detect and correct them early in the dev Process

6

Quality ConceptsQuality Concepts

Quality of Design refers to the characteristics that designerrsquos specify for an item

Quality Control is the series of inspections reviews and tests used throughout the development cycle to ensure that each work product meets the requirements placed upon it

Quality of Conformance is the degree to which the design specifications are followed during manufacturing

7

(contd)(contd)

Quality policy refers to the basic aims and objectives of an organization regarding quality as stipulated by the management

Quality assurance consists of the auditing and reporting functions of management

Cost of Quality includes all costs incurred in the pursuit of quality or in performing quality related activities such as appraisal costs failure costs and external failure costs

8

(contd)(contd)

Quality planning is the process of assessing the requirements of the procedure and of the product and the context in which these must be observed

Quality testing is assessment of the extent to which a test object meets given requirements

Quality assurance plan is the central aid for planning and checking the quality assurance

Quality assurance system is the organizational structure responsibilities procedures processes and resources for implementing quality management

29

SQ Factors

The requirements document is one of the most important elements for achieving SQ

What is a ldquoGoodrdquo SQ requirements document

Software quality factors

Product operation factors

Product revision factors

Product transition factors

31

Classification of SW requirements into SW quality factors

McCallrsquos Factor Model This model classifies all SW requirements into 11 SW

quality factors grouped into 3 categories Product operation Correctness Reliability Efficiency

Integrity Usability Product revision Maintainability Flexibility Testability Product transition Portability Reusability

Interoperability

McCallrsquos Quality Factors and Criteria

Table 171 McCallrsquos quality factors [10]

Product operation factors

Correctness extent to which a program fulfills its specification

Reliability ability not to fail Efficiency use of resources execution

and storage Integrity protection of the program from

unauthorized access Usability ease of use of the software

33

Product revision factors

Maintainability effort required to locate and fix a fault in a program

Flexibility ease of making changes required by changes in operating environment

Testability ease of testing the program to ensure that it is error-free and meets its specification

34

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 2: STQA

2

The uniqueness of software quality assurance

DO you think that there is a bug-free software

Can software developers warrant their software applications and their documentation from any bugs or defects

What are the essential elemental differences between software and other industrial products such as automobiles washing machines etc

3

The essential differences between software and other industrial products can be categorized as follows

1 Product complexity of operational modes the product permit

2 Product visibility SW products are invisible

3 Product development and production process

4

What is Software IEEE Definition

Software Is

Set of Computer programs procedures and possibly associated documentation and data pertaining to the operation of a computer system

5

IEEE Definition is almost identical to the ISO def ( ISOIEC 9000-3 ) Computer programs (ldquoCoderdquo) Procedures Documentation Data necessary for operation the SW system

6

So we can saySoftware quality assurance always includes Code quality The quality of the documentation And the quality of the necessary SW data

7

SW errors faults and failures

An error can be a grammatical error in one or more of the code lines or a logical error in carrying out one or more of the clientrsquos requirements

Faults Most of time Caused by error SW failures that disrupt our use of the software

8

The relationship between SW faults amp SW failures

Do all SW faults end with SW failures The answer is not necessarily The SW fault becomes a SW failure only when it is

activated

9

Classification of the causes of SW errors SW errors are the cause of poor SW quality SW errors can be

Code error Documentation error SW data error

The cause of all these errors are human

10

The nine causes of software errors1 Faulty requirement definition2 Client-developer communication failures3 Deliberate deviation from SW requirements4 Logical design errors5 Coding errors6 Non-compliance with documentation and coding

instructions7 Shortcomings of the testing process8 Procedure errors9 Documentation errors

11

Faulty requirement definition

1 Erroneous definition of requirements

2 Absence of vital requirements

3 Incomplete definition of requirements

4 Inclusion of unnecessary requirements

12

Client-developer communication failures Misunderstandings resulting from defective

client-developer communications Misunderstanding of the clientrsquos requirements

changes presented to the developer In written forms Orally Responses to the design problems others

13

Deliberate deviation from SW requirements

The developer reuse SW modules taken from the earlier project

Due to the time budget pressure Due to the unapproved improvements

14

Logical design errors This is come from systems architects system

analysts SW engineers such as Erroneous algorithms Erroneous definition of boundary conditions

15

Coding errors Misunderstanding the design documentation errors in the prog Lang Errors in the application of CASE and other

dev Tools

16

Non-compliance with documentation and coding

Team members who need to coordinate their own codes with code modules developed by non-complying team members

Individuals replacing the non-complying team member will find it difficult to fully understand his work

17

Shortcomings of the testing process Incomplete testing plans Failures to document and report errors and faults Incomplete correction of detected errors

5

QUALITYQUALITY

Quality refers to any measurable characteristics such as correctness maintainability portability testability usability reliability efficiency integrity reusability and interoperability

19

Software quality - Definition IEEE1 The degree to which a system component or

process meets specified requirements

2 The degree to which a system component or process meets customer or user needs or expectations

20

Software Quality Pressmanrsquos def

Conformance to explicitly stated functional and performance requirements explicitly documented standards and implicit characteristics that are expected of all professionally developed software

21

Software Quality Assurance The IEEE Definition

SQA is

1 A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements

SQA What is SQA

SQA is the process of assuring people that

every effort has been made to ensure that

software products have the desired level of

reliability maintainability usability

SQA What is Software (System) Quality

Absence of defects

Fitness for use

Meets specifications

Adherence to CMM or ISO quality standards

Reliable Maintainable Useable

SQA An SQA Program

Minimizing number of defects in delivered sw

Creating mechanisms for controlling software

development and maintenance so that costs and

schedules can be met

Making certain that the delivered product can be

used in its intended marketplace

Improving the quality of future products

25

Software Quality Assurance Vs Software Quality Control

Quality Control a set of activities designed to evaluate the quality of a developed or manufactured product It take place before the product is shipped to the client

Quality Assurance the main objective is to minimize the cost of guaranteeing quality by a variety of activities performed throughout the causes of errors and detect and correct them early in the dev Process

6

Quality ConceptsQuality Concepts

Quality of Design refers to the characteristics that designerrsquos specify for an item

Quality Control is the series of inspections reviews and tests used throughout the development cycle to ensure that each work product meets the requirements placed upon it

Quality of Conformance is the degree to which the design specifications are followed during manufacturing

7

(contd)(contd)

Quality policy refers to the basic aims and objectives of an organization regarding quality as stipulated by the management

Quality assurance consists of the auditing and reporting functions of management

Cost of Quality includes all costs incurred in the pursuit of quality or in performing quality related activities such as appraisal costs failure costs and external failure costs

8

(contd)(contd)

Quality planning is the process of assessing the requirements of the procedure and of the product and the context in which these must be observed

Quality testing is assessment of the extent to which a test object meets given requirements

Quality assurance plan is the central aid for planning and checking the quality assurance

Quality assurance system is the organizational structure responsibilities procedures processes and resources for implementing quality management

29

SQ Factors

The requirements document is one of the most important elements for achieving SQ

What is a ldquoGoodrdquo SQ requirements document

Software quality factors

Product operation factors

Product revision factors

Product transition factors

31

Classification of SW requirements into SW quality factors

McCallrsquos Factor Model This model classifies all SW requirements into 11 SW

quality factors grouped into 3 categories Product operation Correctness Reliability Efficiency

Integrity Usability Product revision Maintainability Flexibility Testability Product transition Portability Reusability

Interoperability

McCallrsquos Quality Factors and Criteria

Table 171 McCallrsquos quality factors [10]

Product operation factors

Correctness extent to which a program fulfills its specification

Reliability ability not to fail Efficiency use of resources execution

and storage Integrity protection of the program from

unauthorized access Usability ease of use of the software

33

Product revision factors

Maintainability effort required to locate and fix a fault in a program

Flexibility ease of making changes required by changes in operating environment

Testability ease of testing the program to ensure that it is error-free and meets its specification

34

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 3: STQA

3

The essential differences between software and other industrial products can be categorized as follows

1 Product complexity of operational modes the product permit

2 Product visibility SW products are invisible

3 Product development and production process

4

What is Software IEEE Definition

Software Is

Set of Computer programs procedures and possibly associated documentation and data pertaining to the operation of a computer system

5

IEEE Definition is almost identical to the ISO def ( ISOIEC 9000-3 ) Computer programs (ldquoCoderdquo) Procedures Documentation Data necessary for operation the SW system

6

So we can saySoftware quality assurance always includes Code quality The quality of the documentation And the quality of the necessary SW data

7

SW errors faults and failures

An error can be a grammatical error in one or more of the code lines or a logical error in carrying out one or more of the clientrsquos requirements

Faults Most of time Caused by error SW failures that disrupt our use of the software

8

The relationship between SW faults amp SW failures

Do all SW faults end with SW failures The answer is not necessarily The SW fault becomes a SW failure only when it is

activated

9

Classification of the causes of SW errors SW errors are the cause of poor SW quality SW errors can be

Code error Documentation error SW data error

The cause of all these errors are human

10

The nine causes of software errors1 Faulty requirement definition2 Client-developer communication failures3 Deliberate deviation from SW requirements4 Logical design errors5 Coding errors6 Non-compliance with documentation and coding

instructions7 Shortcomings of the testing process8 Procedure errors9 Documentation errors

11

Faulty requirement definition

1 Erroneous definition of requirements

2 Absence of vital requirements

3 Incomplete definition of requirements

4 Inclusion of unnecessary requirements

12

Client-developer communication failures Misunderstandings resulting from defective

client-developer communications Misunderstanding of the clientrsquos requirements

changes presented to the developer In written forms Orally Responses to the design problems others

13

Deliberate deviation from SW requirements

The developer reuse SW modules taken from the earlier project

Due to the time budget pressure Due to the unapproved improvements

14

Logical design errors This is come from systems architects system

analysts SW engineers such as Erroneous algorithms Erroneous definition of boundary conditions

15

Coding errors Misunderstanding the design documentation errors in the prog Lang Errors in the application of CASE and other

dev Tools

16

Non-compliance with documentation and coding

Team members who need to coordinate their own codes with code modules developed by non-complying team members

Individuals replacing the non-complying team member will find it difficult to fully understand his work

17

Shortcomings of the testing process Incomplete testing plans Failures to document and report errors and faults Incomplete correction of detected errors

5

QUALITYQUALITY

Quality refers to any measurable characteristics such as correctness maintainability portability testability usability reliability efficiency integrity reusability and interoperability

19

Software quality - Definition IEEE1 The degree to which a system component or

process meets specified requirements

2 The degree to which a system component or process meets customer or user needs or expectations

20

Software Quality Pressmanrsquos def

Conformance to explicitly stated functional and performance requirements explicitly documented standards and implicit characteristics that are expected of all professionally developed software

21

Software Quality Assurance The IEEE Definition

SQA is

1 A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements

SQA What is SQA

SQA is the process of assuring people that

every effort has been made to ensure that

software products have the desired level of

reliability maintainability usability

SQA What is Software (System) Quality

Absence of defects

Fitness for use

Meets specifications

Adherence to CMM or ISO quality standards

Reliable Maintainable Useable

SQA An SQA Program

Minimizing number of defects in delivered sw

Creating mechanisms for controlling software

development and maintenance so that costs and

schedules can be met

Making certain that the delivered product can be

used in its intended marketplace

Improving the quality of future products

25

Software Quality Assurance Vs Software Quality Control

Quality Control a set of activities designed to evaluate the quality of a developed or manufactured product It take place before the product is shipped to the client

Quality Assurance the main objective is to minimize the cost of guaranteeing quality by a variety of activities performed throughout the causes of errors and detect and correct them early in the dev Process

6

Quality ConceptsQuality Concepts

Quality of Design refers to the characteristics that designerrsquos specify for an item

Quality Control is the series of inspections reviews and tests used throughout the development cycle to ensure that each work product meets the requirements placed upon it

Quality of Conformance is the degree to which the design specifications are followed during manufacturing

7

(contd)(contd)

Quality policy refers to the basic aims and objectives of an organization regarding quality as stipulated by the management

Quality assurance consists of the auditing and reporting functions of management

Cost of Quality includes all costs incurred in the pursuit of quality or in performing quality related activities such as appraisal costs failure costs and external failure costs

8

(contd)(contd)

Quality planning is the process of assessing the requirements of the procedure and of the product and the context in which these must be observed

Quality testing is assessment of the extent to which a test object meets given requirements

Quality assurance plan is the central aid for planning and checking the quality assurance

Quality assurance system is the organizational structure responsibilities procedures processes and resources for implementing quality management

29

SQ Factors

The requirements document is one of the most important elements for achieving SQ

What is a ldquoGoodrdquo SQ requirements document

Software quality factors

Product operation factors

Product revision factors

Product transition factors

31

Classification of SW requirements into SW quality factors

McCallrsquos Factor Model This model classifies all SW requirements into 11 SW

quality factors grouped into 3 categories Product operation Correctness Reliability Efficiency

Integrity Usability Product revision Maintainability Flexibility Testability Product transition Portability Reusability

Interoperability

McCallrsquos Quality Factors and Criteria

Table 171 McCallrsquos quality factors [10]

Product operation factors

Correctness extent to which a program fulfills its specification

Reliability ability not to fail Efficiency use of resources execution

and storage Integrity protection of the program from

unauthorized access Usability ease of use of the software

33

Product revision factors

Maintainability effort required to locate and fix a fault in a program

Flexibility ease of making changes required by changes in operating environment

Testability ease of testing the program to ensure that it is error-free and meets its specification

34

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 4: STQA

4

What is Software IEEE Definition

Software Is

Set of Computer programs procedures and possibly associated documentation and data pertaining to the operation of a computer system

5

IEEE Definition is almost identical to the ISO def ( ISOIEC 9000-3 ) Computer programs (ldquoCoderdquo) Procedures Documentation Data necessary for operation the SW system

6

So we can saySoftware quality assurance always includes Code quality The quality of the documentation And the quality of the necessary SW data

7

SW errors faults and failures

An error can be a grammatical error in one or more of the code lines or a logical error in carrying out one or more of the clientrsquos requirements

Faults Most of time Caused by error SW failures that disrupt our use of the software

8

The relationship between SW faults amp SW failures

Do all SW faults end with SW failures The answer is not necessarily The SW fault becomes a SW failure only when it is

activated

9

Classification of the causes of SW errors SW errors are the cause of poor SW quality SW errors can be

Code error Documentation error SW data error

The cause of all these errors are human

10

The nine causes of software errors1 Faulty requirement definition2 Client-developer communication failures3 Deliberate deviation from SW requirements4 Logical design errors5 Coding errors6 Non-compliance with documentation and coding

instructions7 Shortcomings of the testing process8 Procedure errors9 Documentation errors

11

Faulty requirement definition

1 Erroneous definition of requirements

2 Absence of vital requirements

3 Incomplete definition of requirements

4 Inclusion of unnecessary requirements

12

Client-developer communication failures Misunderstandings resulting from defective

client-developer communications Misunderstanding of the clientrsquos requirements

changes presented to the developer In written forms Orally Responses to the design problems others

13

Deliberate deviation from SW requirements

The developer reuse SW modules taken from the earlier project

Due to the time budget pressure Due to the unapproved improvements

14

Logical design errors This is come from systems architects system

analysts SW engineers such as Erroneous algorithms Erroneous definition of boundary conditions

15

Coding errors Misunderstanding the design documentation errors in the prog Lang Errors in the application of CASE and other

dev Tools

16

Non-compliance with documentation and coding

Team members who need to coordinate their own codes with code modules developed by non-complying team members

Individuals replacing the non-complying team member will find it difficult to fully understand his work

17

Shortcomings of the testing process Incomplete testing plans Failures to document and report errors and faults Incomplete correction of detected errors

5

QUALITYQUALITY

Quality refers to any measurable characteristics such as correctness maintainability portability testability usability reliability efficiency integrity reusability and interoperability

19

Software quality - Definition IEEE1 The degree to which a system component or

process meets specified requirements

2 The degree to which a system component or process meets customer or user needs or expectations

20

Software Quality Pressmanrsquos def

Conformance to explicitly stated functional and performance requirements explicitly documented standards and implicit characteristics that are expected of all professionally developed software

21

Software Quality Assurance The IEEE Definition

SQA is

1 A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements

SQA What is SQA

SQA is the process of assuring people that

every effort has been made to ensure that

software products have the desired level of

reliability maintainability usability

SQA What is Software (System) Quality

Absence of defects

Fitness for use

Meets specifications

Adherence to CMM or ISO quality standards

Reliable Maintainable Useable

SQA An SQA Program

Minimizing number of defects in delivered sw

Creating mechanisms for controlling software

development and maintenance so that costs and

schedules can be met

Making certain that the delivered product can be

used in its intended marketplace

Improving the quality of future products

25

Software Quality Assurance Vs Software Quality Control

Quality Control a set of activities designed to evaluate the quality of a developed or manufactured product It take place before the product is shipped to the client

Quality Assurance the main objective is to minimize the cost of guaranteeing quality by a variety of activities performed throughout the causes of errors and detect and correct them early in the dev Process

6

Quality ConceptsQuality Concepts

Quality of Design refers to the characteristics that designerrsquos specify for an item

Quality Control is the series of inspections reviews and tests used throughout the development cycle to ensure that each work product meets the requirements placed upon it

Quality of Conformance is the degree to which the design specifications are followed during manufacturing

7

(contd)(contd)

Quality policy refers to the basic aims and objectives of an organization regarding quality as stipulated by the management

Quality assurance consists of the auditing and reporting functions of management

Cost of Quality includes all costs incurred in the pursuit of quality or in performing quality related activities such as appraisal costs failure costs and external failure costs

8

(contd)(contd)

Quality planning is the process of assessing the requirements of the procedure and of the product and the context in which these must be observed

Quality testing is assessment of the extent to which a test object meets given requirements

Quality assurance plan is the central aid for planning and checking the quality assurance

Quality assurance system is the organizational structure responsibilities procedures processes and resources for implementing quality management

29

SQ Factors

The requirements document is one of the most important elements for achieving SQ

What is a ldquoGoodrdquo SQ requirements document

Software quality factors

Product operation factors

Product revision factors

Product transition factors

31

Classification of SW requirements into SW quality factors

McCallrsquos Factor Model This model classifies all SW requirements into 11 SW

quality factors grouped into 3 categories Product operation Correctness Reliability Efficiency

Integrity Usability Product revision Maintainability Flexibility Testability Product transition Portability Reusability

Interoperability

McCallrsquos Quality Factors and Criteria

Table 171 McCallrsquos quality factors [10]

Product operation factors

Correctness extent to which a program fulfills its specification

Reliability ability not to fail Efficiency use of resources execution

and storage Integrity protection of the program from

unauthorized access Usability ease of use of the software

33

Product revision factors

Maintainability effort required to locate and fix a fault in a program

Flexibility ease of making changes required by changes in operating environment

Testability ease of testing the program to ensure that it is error-free and meets its specification

34

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 5: STQA

5

IEEE Definition is almost identical to the ISO def ( ISOIEC 9000-3 ) Computer programs (ldquoCoderdquo) Procedures Documentation Data necessary for operation the SW system

6

So we can saySoftware quality assurance always includes Code quality The quality of the documentation And the quality of the necessary SW data

7

SW errors faults and failures

An error can be a grammatical error in one or more of the code lines or a logical error in carrying out one or more of the clientrsquos requirements

Faults Most of time Caused by error SW failures that disrupt our use of the software

8

The relationship between SW faults amp SW failures

Do all SW faults end with SW failures The answer is not necessarily The SW fault becomes a SW failure only when it is

activated

9

Classification of the causes of SW errors SW errors are the cause of poor SW quality SW errors can be

Code error Documentation error SW data error

The cause of all these errors are human

10

The nine causes of software errors1 Faulty requirement definition2 Client-developer communication failures3 Deliberate deviation from SW requirements4 Logical design errors5 Coding errors6 Non-compliance with documentation and coding

instructions7 Shortcomings of the testing process8 Procedure errors9 Documentation errors

11

Faulty requirement definition

1 Erroneous definition of requirements

2 Absence of vital requirements

3 Incomplete definition of requirements

4 Inclusion of unnecessary requirements

12

Client-developer communication failures Misunderstandings resulting from defective

client-developer communications Misunderstanding of the clientrsquos requirements

changes presented to the developer In written forms Orally Responses to the design problems others

13

Deliberate deviation from SW requirements

The developer reuse SW modules taken from the earlier project

Due to the time budget pressure Due to the unapproved improvements

14

Logical design errors This is come from systems architects system

analysts SW engineers such as Erroneous algorithms Erroneous definition of boundary conditions

15

Coding errors Misunderstanding the design documentation errors in the prog Lang Errors in the application of CASE and other

dev Tools

16

Non-compliance with documentation and coding

Team members who need to coordinate their own codes with code modules developed by non-complying team members

Individuals replacing the non-complying team member will find it difficult to fully understand his work

17

Shortcomings of the testing process Incomplete testing plans Failures to document and report errors and faults Incomplete correction of detected errors

5

QUALITYQUALITY

Quality refers to any measurable characteristics such as correctness maintainability portability testability usability reliability efficiency integrity reusability and interoperability

19

Software quality - Definition IEEE1 The degree to which a system component or

process meets specified requirements

2 The degree to which a system component or process meets customer or user needs or expectations

20

Software Quality Pressmanrsquos def

Conformance to explicitly stated functional and performance requirements explicitly documented standards and implicit characteristics that are expected of all professionally developed software

21

Software Quality Assurance The IEEE Definition

SQA is

1 A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements

SQA What is SQA

SQA is the process of assuring people that

every effort has been made to ensure that

software products have the desired level of

reliability maintainability usability

SQA What is Software (System) Quality

Absence of defects

Fitness for use

Meets specifications

Adherence to CMM or ISO quality standards

Reliable Maintainable Useable

SQA An SQA Program

Minimizing number of defects in delivered sw

Creating mechanisms for controlling software

development and maintenance so that costs and

schedules can be met

Making certain that the delivered product can be

used in its intended marketplace

Improving the quality of future products

25

Software Quality Assurance Vs Software Quality Control

Quality Control a set of activities designed to evaluate the quality of a developed or manufactured product It take place before the product is shipped to the client

Quality Assurance the main objective is to minimize the cost of guaranteeing quality by a variety of activities performed throughout the causes of errors and detect and correct them early in the dev Process

6

Quality ConceptsQuality Concepts

Quality of Design refers to the characteristics that designerrsquos specify for an item

Quality Control is the series of inspections reviews and tests used throughout the development cycle to ensure that each work product meets the requirements placed upon it

Quality of Conformance is the degree to which the design specifications are followed during manufacturing

7

(contd)(contd)

Quality policy refers to the basic aims and objectives of an organization regarding quality as stipulated by the management

Quality assurance consists of the auditing and reporting functions of management

Cost of Quality includes all costs incurred in the pursuit of quality or in performing quality related activities such as appraisal costs failure costs and external failure costs

8

(contd)(contd)

Quality planning is the process of assessing the requirements of the procedure and of the product and the context in which these must be observed

Quality testing is assessment of the extent to which a test object meets given requirements

Quality assurance plan is the central aid for planning and checking the quality assurance

Quality assurance system is the organizational structure responsibilities procedures processes and resources for implementing quality management

29

SQ Factors

The requirements document is one of the most important elements for achieving SQ

What is a ldquoGoodrdquo SQ requirements document

Software quality factors

Product operation factors

Product revision factors

Product transition factors

31

Classification of SW requirements into SW quality factors

McCallrsquos Factor Model This model classifies all SW requirements into 11 SW

quality factors grouped into 3 categories Product operation Correctness Reliability Efficiency

Integrity Usability Product revision Maintainability Flexibility Testability Product transition Portability Reusability

Interoperability

McCallrsquos Quality Factors and Criteria

Table 171 McCallrsquos quality factors [10]

Product operation factors

Correctness extent to which a program fulfills its specification

Reliability ability not to fail Efficiency use of resources execution

and storage Integrity protection of the program from

unauthorized access Usability ease of use of the software

33

Product revision factors

Maintainability effort required to locate and fix a fault in a program

Flexibility ease of making changes required by changes in operating environment

Testability ease of testing the program to ensure that it is error-free and meets its specification

34

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 6: STQA

6

So we can saySoftware quality assurance always includes Code quality The quality of the documentation And the quality of the necessary SW data

7

SW errors faults and failures

An error can be a grammatical error in one or more of the code lines or a logical error in carrying out one or more of the clientrsquos requirements

Faults Most of time Caused by error SW failures that disrupt our use of the software

8

The relationship between SW faults amp SW failures

Do all SW faults end with SW failures The answer is not necessarily The SW fault becomes a SW failure only when it is

activated

9

Classification of the causes of SW errors SW errors are the cause of poor SW quality SW errors can be

Code error Documentation error SW data error

The cause of all these errors are human

10

The nine causes of software errors1 Faulty requirement definition2 Client-developer communication failures3 Deliberate deviation from SW requirements4 Logical design errors5 Coding errors6 Non-compliance with documentation and coding

instructions7 Shortcomings of the testing process8 Procedure errors9 Documentation errors

11

Faulty requirement definition

1 Erroneous definition of requirements

2 Absence of vital requirements

3 Incomplete definition of requirements

4 Inclusion of unnecessary requirements

12

Client-developer communication failures Misunderstandings resulting from defective

client-developer communications Misunderstanding of the clientrsquos requirements

changes presented to the developer In written forms Orally Responses to the design problems others

13

Deliberate deviation from SW requirements

The developer reuse SW modules taken from the earlier project

Due to the time budget pressure Due to the unapproved improvements

14

Logical design errors This is come from systems architects system

analysts SW engineers such as Erroneous algorithms Erroneous definition of boundary conditions

15

Coding errors Misunderstanding the design documentation errors in the prog Lang Errors in the application of CASE and other

dev Tools

16

Non-compliance with documentation and coding

Team members who need to coordinate their own codes with code modules developed by non-complying team members

Individuals replacing the non-complying team member will find it difficult to fully understand his work

17

Shortcomings of the testing process Incomplete testing plans Failures to document and report errors and faults Incomplete correction of detected errors

5

QUALITYQUALITY

Quality refers to any measurable characteristics such as correctness maintainability portability testability usability reliability efficiency integrity reusability and interoperability

19

Software quality - Definition IEEE1 The degree to which a system component or

process meets specified requirements

2 The degree to which a system component or process meets customer or user needs or expectations

20

Software Quality Pressmanrsquos def

Conformance to explicitly stated functional and performance requirements explicitly documented standards and implicit characteristics that are expected of all professionally developed software

21

Software Quality Assurance The IEEE Definition

SQA is

1 A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements

SQA What is SQA

SQA is the process of assuring people that

every effort has been made to ensure that

software products have the desired level of

reliability maintainability usability

SQA What is Software (System) Quality

Absence of defects

Fitness for use

Meets specifications

Adherence to CMM or ISO quality standards

Reliable Maintainable Useable

SQA An SQA Program

Minimizing number of defects in delivered sw

Creating mechanisms for controlling software

development and maintenance so that costs and

schedules can be met

Making certain that the delivered product can be

used in its intended marketplace

Improving the quality of future products

25

Software Quality Assurance Vs Software Quality Control

Quality Control a set of activities designed to evaluate the quality of a developed or manufactured product It take place before the product is shipped to the client

Quality Assurance the main objective is to minimize the cost of guaranteeing quality by a variety of activities performed throughout the causes of errors and detect and correct them early in the dev Process

6

Quality ConceptsQuality Concepts

Quality of Design refers to the characteristics that designerrsquos specify for an item

Quality Control is the series of inspections reviews and tests used throughout the development cycle to ensure that each work product meets the requirements placed upon it

Quality of Conformance is the degree to which the design specifications are followed during manufacturing

7

(contd)(contd)

Quality policy refers to the basic aims and objectives of an organization regarding quality as stipulated by the management

Quality assurance consists of the auditing and reporting functions of management

Cost of Quality includes all costs incurred in the pursuit of quality or in performing quality related activities such as appraisal costs failure costs and external failure costs

8

(contd)(contd)

Quality planning is the process of assessing the requirements of the procedure and of the product and the context in which these must be observed

Quality testing is assessment of the extent to which a test object meets given requirements

Quality assurance plan is the central aid for planning and checking the quality assurance

Quality assurance system is the organizational structure responsibilities procedures processes and resources for implementing quality management

29

SQ Factors

The requirements document is one of the most important elements for achieving SQ

What is a ldquoGoodrdquo SQ requirements document

Software quality factors

Product operation factors

Product revision factors

Product transition factors

31

Classification of SW requirements into SW quality factors

McCallrsquos Factor Model This model classifies all SW requirements into 11 SW

quality factors grouped into 3 categories Product operation Correctness Reliability Efficiency

Integrity Usability Product revision Maintainability Flexibility Testability Product transition Portability Reusability

Interoperability

McCallrsquos Quality Factors and Criteria

Table 171 McCallrsquos quality factors [10]

Product operation factors

Correctness extent to which a program fulfills its specification

Reliability ability not to fail Efficiency use of resources execution

and storage Integrity protection of the program from

unauthorized access Usability ease of use of the software

33

Product revision factors

Maintainability effort required to locate and fix a fault in a program

Flexibility ease of making changes required by changes in operating environment

Testability ease of testing the program to ensure that it is error-free and meets its specification

34

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 7: STQA

7

SW errors faults and failures

An error can be a grammatical error in one or more of the code lines or a logical error in carrying out one or more of the clientrsquos requirements

Faults Most of time Caused by error SW failures that disrupt our use of the software

8

The relationship between SW faults amp SW failures

Do all SW faults end with SW failures The answer is not necessarily The SW fault becomes a SW failure only when it is

activated

9

Classification of the causes of SW errors SW errors are the cause of poor SW quality SW errors can be

Code error Documentation error SW data error

The cause of all these errors are human

10

The nine causes of software errors1 Faulty requirement definition2 Client-developer communication failures3 Deliberate deviation from SW requirements4 Logical design errors5 Coding errors6 Non-compliance with documentation and coding

instructions7 Shortcomings of the testing process8 Procedure errors9 Documentation errors

11

Faulty requirement definition

1 Erroneous definition of requirements

2 Absence of vital requirements

3 Incomplete definition of requirements

4 Inclusion of unnecessary requirements

12

Client-developer communication failures Misunderstandings resulting from defective

client-developer communications Misunderstanding of the clientrsquos requirements

changes presented to the developer In written forms Orally Responses to the design problems others

13

Deliberate deviation from SW requirements

The developer reuse SW modules taken from the earlier project

Due to the time budget pressure Due to the unapproved improvements

14

Logical design errors This is come from systems architects system

analysts SW engineers such as Erroneous algorithms Erroneous definition of boundary conditions

15

Coding errors Misunderstanding the design documentation errors in the prog Lang Errors in the application of CASE and other

dev Tools

16

Non-compliance with documentation and coding

Team members who need to coordinate their own codes with code modules developed by non-complying team members

Individuals replacing the non-complying team member will find it difficult to fully understand his work

17

Shortcomings of the testing process Incomplete testing plans Failures to document and report errors and faults Incomplete correction of detected errors

5

QUALITYQUALITY

Quality refers to any measurable characteristics such as correctness maintainability portability testability usability reliability efficiency integrity reusability and interoperability

19

Software quality - Definition IEEE1 The degree to which a system component or

process meets specified requirements

2 The degree to which a system component or process meets customer or user needs or expectations

20

Software Quality Pressmanrsquos def

Conformance to explicitly stated functional and performance requirements explicitly documented standards and implicit characteristics that are expected of all professionally developed software

21

Software Quality Assurance The IEEE Definition

SQA is

1 A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements

SQA What is SQA

SQA is the process of assuring people that

every effort has been made to ensure that

software products have the desired level of

reliability maintainability usability

SQA What is Software (System) Quality

Absence of defects

Fitness for use

Meets specifications

Adherence to CMM or ISO quality standards

Reliable Maintainable Useable

SQA An SQA Program

Minimizing number of defects in delivered sw

Creating mechanisms for controlling software

development and maintenance so that costs and

schedules can be met

Making certain that the delivered product can be

used in its intended marketplace

Improving the quality of future products

25

Software Quality Assurance Vs Software Quality Control

Quality Control a set of activities designed to evaluate the quality of a developed or manufactured product It take place before the product is shipped to the client

Quality Assurance the main objective is to minimize the cost of guaranteeing quality by a variety of activities performed throughout the causes of errors and detect and correct them early in the dev Process

6

Quality ConceptsQuality Concepts

Quality of Design refers to the characteristics that designerrsquos specify for an item

Quality Control is the series of inspections reviews and tests used throughout the development cycle to ensure that each work product meets the requirements placed upon it

Quality of Conformance is the degree to which the design specifications are followed during manufacturing

7

(contd)(contd)

Quality policy refers to the basic aims and objectives of an organization regarding quality as stipulated by the management

Quality assurance consists of the auditing and reporting functions of management

Cost of Quality includes all costs incurred in the pursuit of quality or in performing quality related activities such as appraisal costs failure costs and external failure costs

8

(contd)(contd)

Quality planning is the process of assessing the requirements of the procedure and of the product and the context in which these must be observed

Quality testing is assessment of the extent to which a test object meets given requirements

Quality assurance plan is the central aid for planning and checking the quality assurance

Quality assurance system is the organizational structure responsibilities procedures processes and resources for implementing quality management

29

SQ Factors

The requirements document is one of the most important elements for achieving SQ

What is a ldquoGoodrdquo SQ requirements document

Software quality factors

Product operation factors

Product revision factors

Product transition factors

31

Classification of SW requirements into SW quality factors

McCallrsquos Factor Model This model classifies all SW requirements into 11 SW

quality factors grouped into 3 categories Product operation Correctness Reliability Efficiency

Integrity Usability Product revision Maintainability Flexibility Testability Product transition Portability Reusability

Interoperability

McCallrsquos Quality Factors and Criteria

Table 171 McCallrsquos quality factors [10]

Product operation factors

Correctness extent to which a program fulfills its specification

Reliability ability not to fail Efficiency use of resources execution

and storage Integrity protection of the program from

unauthorized access Usability ease of use of the software

33

Product revision factors

Maintainability effort required to locate and fix a fault in a program

Flexibility ease of making changes required by changes in operating environment

Testability ease of testing the program to ensure that it is error-free and meets its specification

34

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 8: STQA

8

The relationship between SW faults amp SW failures

Do all SW faults end with SW failures The answer is not necessarily The SW fault becomes a SW failure only when it is

activated

9

Classification of the causes of SW errors SW errors are the cause of poor SW quality SW errors can be

Code error Documentation error SW data error

The cause of all these errors are human

10

The nine causes of software errors1 Faulty requirement definition2 Client-developer communication failures3 Deliberate deviation from SW requirements4 Logical design errors5 Coding errors6 Non-compliance with documentation and coding

instructions7 Shortcomings of the testing process8 Procedure errors9 Documentation errors

11

Faulty requirement definition

1 Erroneous definition of requirements

2 Absence of vital requirements

3 Incomplete definition of requirements

4 Inclusion of unnecessary requirements

12

Client-developer communication failures Misunderstandings resulting from defective

client-developer communications Misunderstanding of the clientrsquos requirements

changes presented to the developer In written forms Orally Responses to the design problems others

13

Deliberate deviation from SW requirements

The developer reuse SW modules taken from the earlier project

Due to the time budget pressure Due to the unapproved improvements

14

Logical design errors This is come from systems architects system

analysts SW engineers such as Erroneous algorithms Erroneous definition of boundary conditions

15

Coding errors Misunderstanding the design documentation errors in the prog Lang Errors in the application of CASE and other

dev Tools

16

Non-compliance with documentation and coding

Team members who need to coordinate their own codes with code modules developed by non-complying team members

Individuals replacing the non-complying team member will find it difficult to fully understand his work

17

Shortcomings of the testing process Incomplete testing plans Failures to document and report errors and faults Incomplete correction of detected errors

5

QUALITYQUALITY

Quality refers to any measurable characteristics such as correctness maintainability portability testability usability reliability efficiency integrity reusability and interoperability

19

Software quality - Definition IEEE1 The degree to which a system component or

process meets specified requirements

2 The degree to which a system component or process meets customer or user needs or expectations

20

Software Quality Pressmanrsquos def

Conformance to explicitly stated functional and performance requirements explicitly documented standards and implicit characteristics that are expected of all professionally developed software

21

Software Quality Assurance The IEEE Definition

SQA is

1 A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements

SQA What is SQA

SQA is the process of assuring people that

every effort has been made to ensure that

software products have the desired level of

reliability maintainability usability

SQA What is Software (System) Quality

Absence of defects

Fitness for use

Meets specifications

Adherence to CMM or ISO quality standards

Reliable Maintainable Useable

SQA An SQA Program

Minimizing number of defects in delivered sw

Creating mechanisms for controlling software

development and maintenance so that costs and

schedules can be met

Making certain that the delivered product can be

used in its intended marketplace

Improving the quality of future products

25

Software Quality Assurance Vs Software Quality Control

Quality Control a set of activities designed to evaluate the quality of a developed or manufactured product It take place before the product is shipped to the client

Quality Assurance the main objective is to minimize the cost of guaranteeing quality by a variety of activities performed throughout the causes of errors and detect and correct them early in the dev Process

6

Quality ConceptsQuality Concepts

Quality of Design refers to the characteristics that designerrsquos specify for an item

Quality Control is the series of inspections reviews and tests used throughout the development cycle to ensure that each work product meets the requirements placed upon it

Quality of Conformance is the degree to which the design specifications are followed during manufacturing

7

(contd)(contd)

Quality policy refers to the basic aims and objectives of an organization regarding quality as stipulated by the management

Quality assurance consists of the auditing and reporting functions of management

Cost of Quality includes all costs incurred in the pursuit of quality or in performing quality related activities such as appraisal costs failure costs and external failure costs

8

(contd)(contd)

Quality planning is the process of assessing the requirements of the procedure and of the product and the context in which these must be observed

Quality testing is assessment of the extent to which a test object meets given requirements

Quality assurance plan is the central aid for planning and checking the quality assurance

Quality assurance system is the organizational structure responsibilities procedures processes and resources for implementing quality management

29

SQ Factors

The requirements document is one of the most important elements for achieving SQ

What is a ldquoGoodrdquo SQ requirements document

Software quality factors

Product operation factors

Product revision factors

Product transition factors

31

Classification of SW requirements into SW quality factors

McCallrsquos Factor Model This model classifies all SW requirements into 11 SW

quality factors grouped into 3 categories Product operation Correctness Reliability Efficiency

Integrity Usability Product revision Maintainability Flexibility Testability Product transition Portability Reusability

Interoperability

McCallrsquos Quality Factors and Criteria

Table 171 McCallrsquos quality factors [10]

Product operation factors

Correctness extent to which a program fulfills its specification

Reliability ability not to fail Efficiency use of resources execution

and storage Integrity protection of the program from

unauthorized access Usability ease of use of the software

33

Product revision factors

Maintainability effort required to locate and fix a fault in a program

Flexibility ease of making changes required by changes in operating environment

Testability ease of testing the program to ensure that it is error-free and meets its specification

34

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 9: STQA

9

Classification of the causes of SW errors SW errors are the cause of poor SW quality SW errors can be

Code error Documentation error SW data error

The cause of all these errors are human

10

The nine causes of software errors1 Faulty requirement definition2 Client-developer communication failures3 Deliberate deviation from SW requirements4 Logical design errors5 Coding errors6 Non-compliance with documentation and coding

instructions7 Shortcomings of the testing process8 Procedure errors9 Documentation errors

11

Faulty requirement definition

1 Erroneous definition of requirements

2 Absence of vital requirements

3 Incomplete definition of requirements

4 Inclusion of unnecessary requirements

12

Client-developer communication failures Misunderstandings resulting from defective

client-developer communications Misunderstanding of the clientrsquos requirements

changes presented to the developer In written forms Orally Responses to the design problems others

13

Deliberate deviation from SW requirements

The developer reuse SW modules taken from the earlier project

Due to the time budget pressure Due to the unapproved improvements

14

Logical design errors This is come from systems architects system

analysts SW engineers such as Erroneous algorithms Erroneous definition of boundary conditions

15

Coding errors Misunderstanding the design documentation errors in the prog Lang Errors in the application of CASE and other

dev Tools

16

Non-compliance with documentation and coding

Team members who need to coordinate their own codes with code modules developed by non-complying team members

Individuals replacing the non-complying team member will find it difficult to fully understand his work

17

Shortcomings of the testing process Incomplete testing plans Failures to document and report errors and faults Incomplete correction of detected errors

5

QUALITYQUALITY

Quality refers to any measurable characteristics such as correctness maintainability portability testability usability reliability efficiency integrity reusability and interoperability

19

Software quality - Definition IEEE1 The degree to which a system component or

process meets specified requirements

2 The degree to which a system component or process meets customer or user needs or expectations

20

Software Quality Pressmanrsquos def

Conformance to explicitly stated functional and performance requirements explicitly documented standards and implicit characteristics that are expected of all professionally developed software

21

Software Quality Assurance The IEEE Definition

SQA is

1 A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements

SQA What is SQA

SQA is the process of assuring people that

every effort has been made to ensure that

software products have the desired level of

reliability maintainability usability

SQA What is Software (System) Quality

Absence of defects

Fitness for use

Meets specifications

Adherence to CMM or ISO quality standards

Reliable Maintainable Useable

SQA An SQA Program

Minimizing number of defects in delivered sw

Creating mechanisms for controlling software

development and maintenance so that costs and

schedules can be met

Making certain that the delivered product can be

used in its intended marketplace

Improving the quality of future products

25

Software Quality Assurance Vs Software Quality Control

Quality Control a set of activities designed to evaluate the quality of a developed or manufactured product It take place before the product is shipped to the client

Quality Assurance the main objective is to minimize the cost of guaranteeing quality by a variety of activities performed throughout the causes of errors and detect and correct them early in the dev Process

6

Quality ConceptsQuality Concepts

Quality of Design refers to the characteristics that designerrsquos specify for an item

Quality Control is the series of inspections reviews and tests used throughout the development cycle to ensure that each work product meets the requirements placed upon it

Quality of Conformance is the degree to which the design specifications are followed during manufacturing

7

(contd)(contd)

Quality policy refers to the basic aims and objectives of an organization regarding quality as stipulated by the management

Quality assurance consists of the auditing and reporting functions of management

Cost of Quality includes all costs incurred in the pursuit of quality or in performing quality related activities such as appraisal costs failure costs and external failure costs

8

(contd)(contd)

Quality planning is the process of assessing the requirements of the procedure and of the product and the context in which these must be observed

Quality testing is assessment of the extent to which a test object meets given requirements

Quality assurance plan is the central aid for planning and checking the quality assurance

Quality assurance system is the organizational structure responsibilities procedures processes and resources for implementing quality management

29

SQ Factors

The requirements document is one of the most important elements for achieving SQ

What is a ldquoGoodrdquo SQ requirements document

Software quality factors

Product operation factors

Product revision factors

Product transition factors

31

Classification of SW requirements into SW quality factors

McCallrsquos Factor Model This model classifies all SW requirements into 11 SW

quality factors grouped into 3 categories Product operation Correctness Reliability Efficiency

Integrity Usability Product revision Maintainability Flexibility Testability Product transition Portability Reusability

Interoperability

McCallrsquos Quality Factors and Criteria

Table 171 McCallrsquos quality factors [10]

Product operation factors

Correctness extent to which a program fulfills its specification

Reliability ability not to fail Efficiency use of resources execution

and storage Integrity protection of the program from

unauthorized access Usability ease of use of the software

33

Product revision factors

Maintainability effort required to locate and fix a fault in a program

Flexibility ease of making changes required by changes in operating environment

Testability ease of testing the program to ensure that it is error-free and meets its specification

34

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 10: STQA

10

The nine causes of software errors1 Faulty requirement definition2 Client-developer communication failures3 Deliberate deviation from SW requirements4 Logical design errors5 Coding errors6 Non-compliance with documentation and coding

instructions7 Shortcomings of the testing process8 Procedure errors9 Documentation errors

11

Faulty requirement definition

1 Erroneous definition of requirements

2 Absence of vital requirements

3 Incomplete definition of requirements

4 Inclusion of unnecessary requirements

12

Client-developer communication failures Misunderstandings resulting from defective

client-developer communications Misunderstanding of the clientrsquos requirements

changes presented to the developer In written forms Orally Responses to the design problems others

13

Deliberate deviation from SW requirements

The developer reuse SW modules taken from the earlier project

Due to the time budget pressure Due to the unapproved improvements

14

Logical design errors This is come from systems architects system

analysts SW engineers such as Erroneous algorithms Erroneous definition of boundary conditions

15

Coding errors Misunderstanding the design documentation errors in the prog Lang Errors in the application of CASE and other

dev Tools

16

Non-compliance with documentation and coding

Team members who need to coordinate their own codes with code modules developed by non-complying team members

Individuals replacing the non-complying team member will find it difficult to fully understand his work

17

Shortcomings of the testing process Incomplete testing plans Failures to document and report errors and faults Incomplete correction of detected errors

5

QUALITYQUALITY

Quality refers to any measurable characteristics such as correctness maintainability portability testability usability reliability efficiency integrity reusability and interoperability

19

Software quality - Definition IEEE1 The degree to which a system component or

process meets specified requirements

2 The degree to which a system component or process meets customer or user needs or expectations

20

Software Quality Pressmanrsquos def

Conformance to explicitly stated functional and performance requirements explicitly documented standards and implicit characteristics that are expected of all professionally developed software

21

Software Quality Assurance The IEEE Definition

SQA is

1 A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements

SQA What is SQA

SQA is the process of assuring people that

every effort has been made to ensure that

software products have the desired level of

reliability maintainability usability

SQA What is Software (System) Quality

Absence of defects

Fitness for use

Meets specifications

Adherence to CMM or ISO quality standards

Reliable Maintainable Useable

SQA An SQA Program

Minimizing number of defects in delivered sw

Creating mechanisms for controlling software

development and maintenance so that costs and

schedules can be met

Making certain that the delivered product can be

used in its intended marketplace

Improving the quality of future products

25

Software Quality Assurance Vs Software Quality Control

Quality Control a set of activities designed to evaluate the quality of a developed or manufactured product It take place before the product is shipped to the client

Quality Assurance the main objective is to minimize the cost of guaranteeing quality by a variety of activities performed throughout the causes of errors and detect and correct them early in the dev Process

6

Quality ConceptsQuality Concepts

Quality of Design refers to the characteristics that designerrsquos specify for an item

Quality Control is the series of inspections reviews and tests used throughout the development cycle to ensure that each work product meets the requirements placed upon it

Quality of Conformance is the degree to which the design specifications are followed during manufacturing

7

(contd)(contd)

Quality policy refers to the basic aims and objectives of an organization regarding quality as stipulated by the management

Quality assurance consists of the auditing and reporting functions of management

Cost of Quality includes all costs incurred in the pursuit of quality or in performing quality related activities such as appraisal costs failure costs and external failure costs

8

(contd)(contd)

Quality planning is the process of assessing the requirements of the procedure and of the product and the context in which these must be observed

Quality testing is assessment of the extent to which a test object meets given requirements

Quality assurance plan is the central aid for planning and checking the quality assurance

Quality assurance system is the organizational structure responsibilities procedures processes and resources for implementing quality management

29

SQ Factors

The requirements document is one of the most important elements for achieving SQ

What is a ldquoGoodrdquo SQ requirements document

Software quality factors

Product operation factors

Product revision factors

Product transition factors

31

Classification of SW requirements into SW quality factors

McCallrsquos Factor Model This model classifies all SW requirements into 11 SW

quality factors grouped into 3 categories Product operation Correctness Reliability Efficiency

Integrity Usability Product revision Maintainability Flexibility Testability Product transition Portability Reusability

Interoperability

McCallrsquos Quality Factors and Criteria

Table 171 McCallrsquos quality factors [10]

Product operation factors

Correctness extent to which a program fulfills its specification

Reliability ability not to fail Efficiency use of resources execution

and storage Integrity protection of the program from

unauthorized access Usability ease of use of the software

33

Product revision factors

Maintainability effort required to locate and fix a fault in a program

Flexibility ease of making changes required by changes in operating environment

Testability ease of testing the program to ensure that it is error-free and meets its specification

34

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 11: STQA

11

Faulty requirement definition

1 Erroneous definition of requirements

2 Absence of vital requirements

3 Incomplete definition of requirements

4 Inclusion of unnecessary requirements

12

Client-developer communication failures Misunderstandings resulting from defective

client-developer communications Misunderstanding of the clientrsquos requirements

changes presented to the developer In written forms Orally Responses to the design problems others

13

Deliberate deviation from SW requirements

The developer reuse SW modules taken from the earlier project

Due to the time budget pressure Due to the unapproved improvements

14

Logical design errors This is come from systems architects system

analysts SW engineers such as Erroneous algorithms Erroneous definition of boundary conditions

15

Coding errors Misunderstanding the design documentation errors in the prog Lang Errors in the application of CASE and other

dev Tools

16

Non-compliance with documentation and coding

Team members who need to coordinate their own codes with code modules developed by non-complying team members

Individuals replacing the non-complying team member will find it difficult to fully understand his work

17

Shortcomings of the testing process Incomplete testing plans Failures to document and report errors and faults Incomplete correction of detected errors

5

QUALITYQUALITY

Quality refers to any measurable characteristics such as correctness maintainability portability testability usability reliability efficiency integrity reusability and interoperability

19

Software quality - Definition IEEE1 The degree to which a system component or

process meets specified requirements

2 The degree to which a system component or process meets customer or user needs or expectations

20

Software Quality Pressmanrsquos def

Conformance to explicitly stated functional and performance requirements explicitly documented standards and implicit characteristics that are expected of all professionally developed software

21

Software Quality Assurance The IEEE Definition

SQA is

1 A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements

SQA What is SQA

SQA is the process of assuring people that

every effort has been made to ensure that

software products have the desired level of

reliability maintainability usability

SQA What is Software (System) Quality

Absence of defects

Fitness for use

Meets specifications

Adherence to CMM or ISO quality standards

Reliable Maintainable Useable

SQA An SQA Program

Minimizing number of defects in delivered sw

Creating mechanisms for controlling software

development and maintenance so that costs and

schedules can be met

Making certain that the delivered product can be

used in its intended marketplace

Improving the quality of future products

25

Software Quality Assurance Vs Software Quality Control

Quality Control a set of activities designed to evaluate the quality of a developed or manufactured product It take place before the product is shipped to the client

Quality Assurance the main objective is to minimize the cost of guaranteeing quality by a variety of activities performed throughout the causes of errors and detect and correct them early in the dev Process

6

Quality ConceptsQuality Concepts

Quality of Design refers to the characteristics that designerrsquos specify for an item

Quality Control is the series of inspections reviews and tests used throughout the development cycle to ensure that each work product meets the requirements placed upon it

Quality of Conformance is the degree to which the design specifications are followed during manufacturing

7

(contd)(contd)

Quality policy refers to the basic aims and objectives of an organization regarding quality as stipulated by the management

Quality assurance consists of the auditing and reporting functions of management

Cost of Quality includes all costs incurred in the pursuit of quality or in performing quality related activities such as appraisal costs failure costs and external failure costs

8

(contd)(contd)

Quality planning is the process of assessing the requirements of the procedure and of the product and the context in which these must be observed

Quality testing is assessment of the extent to which a test object meets given requirements

Quality assurance plan is the central aid for planning and checking the quality assurance

Quality assurance system is the organizational structure responsibilities procedures processes and resources for implementing quality management

29

SQ Factors

The requirements document is one of the most important elements for achieving SQ

What is a ldquoGoodrdquo SQ requirements document

Software quality factors

Product operation factors

Product revision factors

Product transition factors

31

Classification of SW requirements into SW quality factors

McCallrsquos Factor Model This model classifies all SW requirements into 11 SW

quality factors grouped into 3 categories Product operation Correctness Reliability Efficiency

Integrity Usability Product revision Maintainability Flexibility Testability Product transition Portability Reusability

Interoperability

McCallrsquos Quality Factors and Criteria

Table 171 McCallrsquos quality factors [10]

Product operation factors

Correctness extent to which a program fulfills its specification

Reliability ability not to fail Efficiency use of resources execution

and storage Integrity protection of the program from

unauthorized access Usability ease of use of the software

33

Product revision factors

Maintainability effort required to locate and fix a fault in a program

Flexibility ease of making changes required by changes in operating environment

Testability ease of testing the program to ensure that it is error-free and meets its specification

34

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 12: STQA

12

Client-developer communication failures Misunderstandings resulting from defective

client-developer communications Misunderstanding of the clientrsquos requirements

changes presented to the developer In written forms Orally Responses to the design problems others

13

Deliberate deviation from SW requirements

The developer reuse SW modules taken from the earlier project

Due to the time budget pressure Due to the unapproved improvements

14

Logical design errors This is come from systems architects system

analysts SW engineers such as Erroneous algorithms Erroneous definition of boundary conditions

15

Coding errors Misunderstanding the design documentation errors in the prog Lang Errors in the application of CASE and other

dev Tools

16

Non-compliance with documentation and coding

Team members who need to coordinate their own codes with code modules developed by non-complying team members

Individuals replacing the non-complying team member will find it difficult to fully understand his work

17

Shortcomings of the testing process Incomplete testing plans Failures to document and report errors and faults Incomplete correction of detected errors

5

QUALITYQUALITY

Quality refers to any measurable characteristics such as correctness maintainability portability testability usability reliability efficiency integrity reusability and interoperability

19

Software quality - Definition IEEE1 The degree to which a system component or

process meets specified requirements

2 The degree to which a system component or process meets customer or user needs or expectations

20

Software Quality Pressmanrsquos def

Conformance to explicitly stated functional and performance requirements explicitly documented standards and implicit characteristics that are expected of all professionally developed software

21

Software Quality Assurance The IEEE Definition

SQA is

1 A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements

SQA What is SQA

SQA is the process of assuring people that

every effort has been made to ensure that

software products have the desired level of

reliability maintainability usability

SQA What is Software (System) Quality

Absence of defects

Fitness for use

Meets specifications

Adherence to CMM or ISO quality standards

Reliable Maintainable Useable

SQA An SQA Program

Minimizing number of defects in delivered sw

Creating mechanisms for controlling software

development and maintenance so that costs and

schedules can be met

Making certain that the delivered product can be

used in its intended marketplace

Improving the quality of future products

25

Software Quality Assurance Vs Software Quality Control

Quality Control a set of activities designed to evaluate the quality of a developed or manufactured product It take place before the product is shipped to the client

Quality Assurance the main objective is to minimize the cost of guaranteeing quality by a variety of activities performed throughout the causes of errors and detect and correct them early in the dev Process

6

Quality ConceptsQuality Concepts

Quality of Design refers to the characteristics that designerrsquos specify for an item

Quality Control is the series of inspections reviews and tests used throughout the development cycle to ensure that each work product meets the requirements placed upon it

Quality of Conformance is the degree to which the design specifications are followed during manufacturing

7

(contd)(contd)

Quality policy refers to the basic aims and objectives of an organization regarding quality as stipulated by the management

Quality assurance consists of the auditing and reporting functions of management

Cost of Quality includes all costs incurred in the pursuit of quality or in performing quality related activities such as appraisal costs failure costs and external failure costs

8

(contd)(contd)

Quality planning is the process of assessing the requirements of the procedure and of the product and the context in which these must be observed

Quality testing is assessment of the extent to which a test object meets given requirements

Quality assurance plan is the central aid for planning and checking the quality assurance

Quality assurance system is the organizational structure responsibilities procedures processes and resources for implementing quality management

29

SQ Factors

The requirements document is one of the most important elements for achieving SQ

What is a ldquoGoodrdquo SQ requirements document

Software quality factors

Product operation factors

Product revision factors

Product transition factors

31

Classification of SW requirements into SW quality factors

McCallrsquos Factor Model This model classifies all SW requirements into 11 SW

quality factors grouped into 3 categories Product operation Correctness Reliability Efficiency

Integrity Usability Product revision Maintainability Flexibility Testability Product transition Portability Reusability

Interoperability

McCallrsquos Quality Factors and Criteria

Table 171 McCallrsquos quality factors [10]

Product operation factors

Correctness extent to which a program fulfills its specification

Reliability ability not to fail Efficiency use of resources execution

and storage Integrity protection of the program from

unauthorized access Usability ease of use of the software

33

Product revision factors

Maintainability effort required to locate and fix a fault in a program

Flexibility ease of making changes required by changes in operating environment

Testability ease of testing the program to ensure that it is error-free and meets its specification

34

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 13: STQA

13

Deliberate deviation from SW requirements

The developer reuse SW modules taken from the earlier project

Due to the time budget pressure Due to the unapproved improvements

14

Logical design errors This is come from systems architects system

analysts SW engineers such as Erroneous algorithms Erroneous definition of boundary conditions

15

Coding errors Misunderstanding the design documentation errors in the prog Lang Errors in the application of CASE and other

dev Tools

16

Non-compliance with documentation and coding

Team members who need to coordinate their own codes with code modules developed by non-complying team members

Individuals replacing the non-complying team member will find it difficult to fully understand his work

17

Shortcomings of the testing process Incomplete testing plans Failures to document and report errors and faults Incomplete correction of detected errors

5

QUALITYQUALITY

Quality refers to any measurable characteristics such as correctness maintainability portability testability usability reliability efficiency integrity reusability and interoperability

19

Software quality - Definition IEEE1 The degree to which a system component or

process meets specified requirements

2 The degree to which a system component or process meets customer or user needs or expectations

20

Software Quality Pressmanrsquos def

Conformance to explicitly stated functional and performance requirements explicitly documented standards and implicit characteristics that are expected of all professionally developed software

21

Software Quality Assurance The IEEE Definition

SQA is

1 A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements

SQA What is SQA

SQA is the process of assuring people that

every effort has been made to ensure that

software products have the desired level of

reliability maintainability usability

SQA What is Software (System) Quality

Absence of defects

Fitness for use

Meets specifications

Adherence to CMM or ISO quality standards

Reliable Maintainable Useable

SQA An SQA Program

Minimizing number of defects in delivered sw

Creating mechanisms for controlling software

development and maintenance so that costs and

schedules can be met

Making certain that the delivered product can be

used in its intended marketplace

Improving the quality of future products

25

Software Quality Assurance Vs Software Quality Control

Quality Control a set of activities designed to evaluate the quality of a developed or manufactured product It take place before the product is shipped to the client

Quality Assurance the main objective is to minimize the cost of guaranteeing quality by a variety of activities performed throughout the causes of errors and detect and correct them early in the dev Process

6

Quality ConceptsQuality Concepts

Quality of Design refers to the characteristics that designerrsquos specify for an item

Quality Control is the series of inspections reviews and tests used throughout the development cycle to ensure that each work product meets the requirements placed upon it

Quality of Conformance is the degree to which the design specifications are followed during manufacturing

7

(contd)(contd)

Quality policy refers to the basic aims and objectives of an organization regarding quality as stipulated by the management

Quality assurance consists of the auditing and reporting functions of management

Cost of Quality includes all costs incurred in the pursuit of quality or in performing quality related activities such as appraisal costs failure costs and external failure costs

8

(contd)(contd)

Quality planning is the process of assessing the requirements of the procedure and of the product and the context in which these must be observed

Quality testing is assessment of the extent to which a test object meets given requirements

Quality assurance plan is the central aid for planning and checking the quality assurance

Quality assurance system is the organizational structure responsibilities procedures processes and resources for implementing quality management

29

SQ Factors

The requirements document is one of the most important elements for achieving SQ

What is a ldquoGoodrdquo SQ requirements document

Software quality factors

Product operation factors

Product revision factors

Product transition factors

31

Classification of SW requirements into SW quality factors

McCallrsquos Factor Model This model classifies all SW requirements into 11 SW

quality factors grouped into 3 categories Product operation Correctness Reliability Efficiency

Integrity Usability Product revision Maintainability Flexibility Testability Product transition Portability Reusability

Interoperability

McCallrsquos Quality Factors and Criteria

Table 171 McCallrsquos quality factors [10]

Product operation factors

Correctness extent to which a program fulfills its specification

Reliability ability not to fail Efficiency use of resources execution

and storage Integrity protection of the program from

unauthorized access Usability ease of use of the software

33

Product revision factors

Maintainability effort required to locate and fix a fault in a program

Flexibility ease of making changes required by changes in operating environment

Testability ease of testing the program to ensure that it is error-free and meets its specification

34

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 14: STQA

14

Logical design errors This is come from systems architects system

analysts SW engineers such as Erroneous algorithms Erroneous definition of boundary conditions

15

Coding errors Misunderstanding the design documentation errors in the prog Lang Errors in the application of CASE and other

dev Tools

16

Non-compliance with documentation and coding

Team members who need to coordinate their own codes with code modules developed by non-complying team members

Individuals replacing the non-complying team member will find it difficult to fully understand his work

17

Shortcomings of the testing process Incomplete testing plans Failures to document and report errors and faults Incomplete correction of detected errors

5

QUALITYQUALITY

Quality refers to any measurable characteristics such as correctness maintainability portability testability usability reliability efficiency integrity reusability and interoperability

19

Software quality - Definition IEEE1 The degree to which a system component or

process meets specified requirements

2 The degree to which a system component or process meets customer or user needs or expectations

20

Software Quality Pressmanrsquos def

Conformance to explicitly stated functional and performance requirements explicitly documented standards and implicit characteristics that are expected of all professionally developed software

21

Software Quality Assurance The IEEE Definition

SQA is

1 A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements

SQA What is SQA

SQA is the process of assuring people that

every effort has been made to ensure that

software products have the desired level of

reliability maintainability usability

SQA What is Software (System) Quality

Absence of defects

Fitness for use

Meets specifications

Adherence to CMM or ISO quality standards

Reliable Maintainable Useable

SQA An SQA Program

Minimizing number of defects in delivered sw

Creating mechanisms for controlling software

development and maintenance so that costs and

schedules can be met

Making certain that the delivered product can be

used in its intended marketplace

Improving the quality of future products

25

Software Quality Assurance Vs Software Quality Control

Quality Control a set of activities designed to evaluate the quality of a developed or manufactured product It take place before the product is shipped to the client

Quality Assurance the main objective is to minimize the cost of guaranteeing quality by a variety of activities performed throughout the causes of errors and detect and correct them early in the dev Process

6

Quality ConceptsQuality Concepts

Quality of Design refers to the characteristics that designerrsquos specify for an item

Quality Control is the series of inspections reviews and tests used throughout the development cycle to ensure that each work product meets the requirements placed upon it

Quality of Conformance is the degree to which the design specifications are followed during manufacturing

7

(contd)(contd)

Quality policy refers to the basic aims and objectives of an organization regarding quality as stipulated by the management

Quality assurance consists of the auditing and reporting functions of management

Cost of Quality includes all costs incurred in the pursuit of quality or in performing quality related activities such as appraisal costs failure costs and external failure costs

8

(contd)(contd)

Quality planning is the process of assessing the requirements of the procedure and of the product and the context in which these must be observed

Quality testing is assessment of the extent to which a test object meets given requirements

Quality assurance plan is the central aid for planning and checking the quality assurance

Quality assurance system is the organizational structure responsibilities procedures processes and resources for implementing quality management

29

SQ Factors

The requirements document is one of the most important elements for achieving SQ

What is a ldquoGoodrdquo SQ requirements document

Software quality factors

Product operation factors

Product revision factors

Product transition factors

31

Classification of SW requirements into SW quality factors

McCallrsquos Factor Model This model classifies all SW requirements into 11 SW

quality factors grouped into 3 categories Product operation Correctness Reliability Efficiency

Integrity Usability Product revision Maintainability Flexibility Testability Product transition Portability Reusability

Interoperability

McCallrsquos Quality Factors and Criteria

Table 171 McCallrsquos quality factors [10]

Product operation factors

Correctness extent to which a program fulfills its specification

Reliability ability not to fail Efficiency use of resources execution

and storage Integrity protection of the program from

unauthorized access Usability ease of use of the software

33

Product revision factors

Maintainability effort required to locate and fix a fault in a program

Flexibility ease of making changes required by changes in operating environment

Testability ease of testing the program to ensure that it is error-free and meets its specification

34

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 15: STQA

15

Coding errors Misunderstanding the design documentation errors in the prog Lang Errors in the application of CASE and other

dev Tools

16

Non-compliance with documentation and coding

Team members who need to coordinate their own codes with code modules developed by non-complying team members

Individuals replacing the non-complying team member will find it difficult to fully understand his work

17

Shortcomings of the testing process Incomplete testing plans Failures to document and report errors and faults Incomplete correction of detected errors

5

QUALITYQUALITY

Quality refers to any measurable characteristics such as correctness maintainability portability testability usability reliability efficiency integrity reusability and interoperability

19

Software quality - Definition IEEE1 The degree to which a system component or

process meets specified requirements

2 The degree to which a system component or process meets customer or user needs or expectations

20

Software Quality Pressmanrsquos def

Conformance to explicitly stated functional and performance requirements explicitly documented standards and implicit characteristics that are expected of all professionally developed software

21

Software Quality Assurance The IEEE Definition

SQA is

1 A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements

SQA What is SQA

SQA is the process of assuring people that

every effort has been made to ensure that

software products have the desired level of

reliability maintainability usability

SQA What is Software (System) Quality

Absence of defects

Fitness for use

Meets specifications

Adherence to CMM or ISO quality standards

Reliable Maintainable Useable

SQA An SQA Program

Minimizing number of defects in delivered sw

Creating mechanisms for controlling software

development and maintenance so that costs and

schedules can be met

Making certain that the delivered product can be

used in its intended marketplace

Improving the quality of future products

25

Software Quality Assurance Vs Software Quality Control

Quality Control a set of activities designed to evaluate the quality of a developed or manufactured product It take place before the product is shipped to the client

Quality Assurance the main objective is to minimize the cost of guaranteeing quality by a variety of activities performed throughout the causes of errors and detect and correct them early in the dev Process

6

Quality ConceptsQuality Concepts

Quality of Design refers to the characteristics that designerrsquos specify for an item

Quality Control is the series of inspections reviews and tests used throughout the development cycle to ensure that each work product meets the requirements placed upon it

Quality of Conformance is the degree to which the design specifications are followed during manufacturing

7

(contd)(contd)

Quality policy refers to the basic aims and objectives of an organization regarding quality as stipulated by the management

Quality assurance consists of the auditing and reporting functions of management

Cost of Quality includes all costs incurred in the pursuit of quality or in performing quality related activities such as appraisal costs failure costs and external failure costs

8

(contd)(contd)

Quality planning is the process of assessing the requirements of the procedure and of the product and the context in which these must be observed

Quality testing is assessment of the extent to which a test object meets given requirements

Quality assurance plan is the central aid for planning and checking the quality assurance

Quality assurance system is the organizational structure responsibilities procedures processes and resources for implementing quality management

29

SQ Factors

The requirements document is one of the most important elements for achieving SQ

What is a ldquoGoodrdquo SQ requirements document

Software quality factors

Product operation factors

Product revision factors

Product transition factors

31

Classification of SW requirements into SW quality factors

McCallrsquos Factor Model This model classifies all SW requirements into 11 SW

quality factors grouped into 3 categories Product operation Correctness Reliability Efficiency

Integrity Usability Product revision Maintainability Flexibility Testability Product transition Portability Reusability

Interoperability

McCallrsquos Quality Factors and Criteria

Table 171 McCallrsquos quality factors [10]

Product operation factors

Correctness extent to which a program fulfills its specification

Reliability ability not to fail Efficiency use of resources execution

and storage Integrity protection of the program from

unauthorized access Usability ease of use of the software

33

Product revision factors

Maintainability effort required to locate and fix a fault in a program

Flexibility ease of making changes required by changes in operating environment

Testability ease of testing the program to ensure that it is error-free and meets its specification

34

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 16: STQA

16

Non-compliance with documentation and coding

Team members who need to coordinate their own codes with code modules developed by non-complying team members

Individuals replacing the non-complying team member will find it difficult to fully understand his work

17

Shortcomings of the testing process Incomplete testing plans Failures to document and report errors and faults Incomplete correction of detected errors

5

QUALITYQUALITY

Quality refers to any measurable characteristics such as correctness maintainability portability testability usability reliability efficiency integrity reusability and interoperability

19

Software quality - Definition IEEE1 The degree to which a system component or

process meets specified requirements

2 The degree to which a system component or process meets customer or user needs or expectations

20

Software Quality Pressmanrsquos def

Conformance to explicitly stated functional and performance requirements explicitly documented standards and implicit characteristics that are expected of all professionally developed software

21

Software Quality Assurance The IEEE Definition

SQA is

1 A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements

SQA What is SQA

SQA is the process of assuring people that

every effort has been made to ensure that

software products have the desired level of

reliability maintainability usability

SQA What is Software (System) Quality

Absence of defects

Fitness for use

Meets specifications

Adherence to CMM or ISO quality standards

Reliable Maintainable Useable

SQA An SQA Program

Minimizing number of defects in delivered sw

Creating mechanisms for controlling software

development and maintenance so that costs and

schedules can be met

Making certain that the delivered product can be

used in its intended marketplace

Improving the quality of future products

25

Software Quality Assurance Vs Software Quality Control

Quality Control a set of activities designed to evaluate the quality of a developed or manufactured product It take place before the product is shipped to the client

Quality Assurance the main objective is to minimize the cost of guaranteeing quality by a variety of activities performed throughout the causes of errors and detect and correct them early in the dev Process

6

Quality ConceptsQuality Concepts

Quality of Design refers to the characteristics that designerrsquos specify for an item

Quality Control is the series of inspections reviews and tests used throughout the development cycle to ensure that each work product meets the requirements placed upon it

Quality of Conformance is the degree to which the design specifications are followed during manufacturing

7

(contd)(contd)

Quality policy refers to the basic aims and objectives of an organization regarding quality as stipulated by the management

Quality assurance consists of the auditing and reporting functions of management

Cost of Quality includes all costs incurred in the pursuit of quality or in performing quality related activities such as appraisal costs failure costs and external failure costs

8

(contd)(contd)

Quality planning is the process of assessing the requirements of the procedure and of the product and the context in which these must be observed

Quality testing is assessment of the extent to which a test object meets given requirements

Quality assurance plan is the central aid for planning and checking the quality assurance

Quality assurance system is the organizational structure responsibilities procedures processes and resources for implementing quality management

29

SQ Factors

The requirements document is one of the most important elements for achieving SQ

What is a ldquoGoodrdquo SQ requirements document

Software quality factors

Product operation factors

Product revision factors

Product transition factors

31

Classification of SW requirements into SW quality factors

McCallrsquos Factor Model This model classifies all SW requirements into 11 SW

quality factors grouped into 3 categories Product operation Correctness Reliability Efficiency

Integrity Usability Product revision Maintainability Flexibility Testability Product transition Portability Reusability

Interoperability

McCallrsquos Quality Factors and Criteria

Table 171 McCallrsquos quality factors [10]

Product operation factors

Correctness extent to which a program fulfills its specification

Reliability ability not to fail Efficiency use of resources execution

and storage Integrity protection of the program from

unauthorized access Usability ease of use of the software

33

Product revision factors

Maintainability effort required to locate and fix a fault in a program

Flexibility ease of making changes required by changes in operating environment

Testability ease of testing the program to ensure that it is error-free and meets its specification

34

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 17: STQA

17

Shortcomings of the testing process Incomplete testing plans Failures to document and report errors and faults Incomplete correction of detected errors

5

QUALITYQUALITY

Quality refers to any measurable characteristics such as correctness maintainability portability testability usability reliability efficiency integrity reusability and interoperability

19

Software quality - Definition IEEE1 The degree to which a system component or

process meets specified requirements

2 The degree to which a system component or process meets customer or user needs or expectations

20

Software Quality Pressmanrsquos def

Conformance to explicitly stated functional and performance requirements explicitly documented standards and implicit characteristics that are expected of all professionally developed software

21

Software Quality Assurance The IEEE Definition

SQA is

1 A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements

SQA What is SQA

SQA is the process of assuring people that

every effort has been made to ensure that

software products have the desired level of

reliability maintainability usability

SQA What is Software (System) Quality

Absence of defects

Fitness for use

Meets specifications

Adherence to CMM or ISO quality standards

Reliable Maintainable Useable

SQA An SQA Program

Minimizing number of defects in delivered sw

Creating mechanisms for controlling software

development and maintenance so that costs and

schedules can be met

Making certain that the delivered product can be

used in its intended marketplace

Improving the quality of future products

25

Software Quality Assurance Vs Software Quality Control

Quality Control a set of activities designed to evaluate the quality of a developed or manufactured product It take place before the product is shipped to the client

Quality Assurance the main objective is to minimize the cost of guaranteeing quality by a variety of activities performed throughout the causes of errors and detect and correct them early in the dev Process

6

Quality ConceptsQuality Concepts

Quality of Design refers to the characteristics that designerrsquos specify for an item

Quality Control is the series of inspections reviews and tests used throughout the development cycle to ensure that each work product meets the requirements placed upon it

Quality of Conformance is the degree to which the design specifications are followed during manufacturing

7

(contd)(contd)

Quality policy refers to the basic aims and objectives of an organization regarding quality as stipulated by the management

Quality assurance consists of the auditing and reporting functions of management

Cost of Quality includes all costs incurred in the pursuit of quality or in performing quality related activities such as appraisal costs failure costs and external failure costs

8

(contd)(contd)

Quality planning is the process of assessing the requirements of the procedure and of the product and the context in which these must be observed

Quality testing is assessment of the extent to which a test object meets given requirements

Quality assurance plan is the central aid for planning and checking the quality assurance

Quality assurance system is the organizational structure responsibilities procedures processes and resources for implementing quality management

29

SQ Factors

The requirements document is one of the most important elements for achieving SQ

What is a ldquoGoodrdquo SQ requirements document

Software quality factors

Product operation factors

Product revision factors

Product transition factors

31

Classification of SW requirements into SW quality factors

McCallrsquos Factor Model This model classifies all SW requirements into 11 SW

quality factors grouped into 3 categories Product operation Correctness Reliability Efficiency

Integrity Usability Product revision Maintainability Flexibility Testability Product transition Portability Reusability

Interoperability

McCallrsquos Quality Factors and Criteria

Table 171 McCallrsquos quality factors [10]

Product operation factors

Correctness extent to which a program fulfills its specification

Reliability ability not to fail Efficiency use of resources execution

and storage Integrity protection of the program from

unauthorized access Usability ease of use of the software

33

Product revision factors

Maintainability effort required to locate and fix a fault in a program

Flexibility ease of making changes required by changes in operating environment

Testability ease of testing the program to ensure that it is error-free and meets its specification

34

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 18: STQA

5

QUALITYQUALITY

Quality refers to any measurable characteristics such as correctness maintainability portability testability usability reliability efficiency integrity reusability and interoperability

19

Software quality - Definition IEEE1 The degree to which a system component or

process meets specified requirements

2 The degree to which a system component or process meets customer or user needs or expectations

20

Software Quality Pressmanrsquos def

Conformance to explicitly stated functional and performance requirements explicitly documented standards and implicit characteristics that are expected of all professionally developed software

21

Software Quality Assurance The IEEE Definition

SQA is

1 A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements

SQA What is SQA

SQA is the process of assuring people that

every effort has been made to ensure that

software products have the desired level of

reliability maintainability usability

SQA What is Software (System) Quality

Absence of defects

Fitness for use

Meets specifications

Adherence to CMM or ISO quality standards

Reliable Maintainable Useable

SQA An SQA Program

Minimizing number of defects in delivered sw

Creating mechanisms for controlling software

development and maintenance so that costs and

schedules can be met

Making certain that the delivered product can be

used in its intended marketplace

Improving the quality of future products

25

Software Quality Assurance Vs Software Quality Control

Quality Control a set of activities designed to evaluate the quality of a developed or manufactured product It take place before the product is shipped to the client

Quality Assurance the main objective is to minimize the cost of guaranteeing quality by a variety of activities performed throughout the causes of errors and detect and correct them early in the dev Process

6

Quality ConceptsQuality Concepts

Quality of Design refers to the characteristics that designerrsquos specify for an item

Quality Control is the series of inspections reviews and tests used throughout the development cycle to ensure that each work product meets the requirements placed upon it

Quality of Conformance is the degree to which the design specifications are followed during manufacturing

7

(contd)(contd)

Quality policy refers to the basic aims and objectives of an organization regarding quality as stipulated by the management

Quality assurance consists of the auditing and reporting functions of management

Cost of Quality includes all costs incurred in the pursuit of quality or in performing quality related activities such as appraisal costs failure costs and external failure costs

8

(contd)(contd)

Quality planning is the process of assessing the requirements of the procedure and of the product and the context in which these must be observed

Quality testing is assessment of the extent to which a test object meets given requirements

Quality assurance plan is the central aid for planning and checking the quality assurance

Quality assurance system is the organizational structure responsibilities procedures processes and resources for implementing quality management

29

SQ Factors

The requirements document is one of the most important elements for achieving SQ

What is a ldquoGoodrdquo SQ requirements document

Software quality factors

Product operation factors

Product revision factors

Product transition factors

31

Classification of SW requirements into SW quality factors

McCallrsquos Factor Model This model classifies all SW requirements into 11 SW

quality factors grouped into 3 categories Product operation Correctness Reliability Efficiency

Integrity Usability Product revision Maintainability Flexibility Testability Product transition Portability Reusability

Interoperability

McCallrsquos Quality Factors and Criteria

Table 171 McCallrsquos quality factors [10]

Product operation factors

Correctness extent to which a program fulfills its specification

Reliability ability not to fail Efficiency use of resources execution

and storage Integrity protection of the program from

unauthorized access Usability ease of use of the software

33

Product revision factors

Maintainability effort required to locate and fix a fault in a program

Flexibility ease of making changes required by changes in operating environment

Testability ease of testing the program to ensure that it is error-free and meets its specification

34

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 19: STQA

19

Software quality - Definition IEEE1 The degree to which a system component or

process meets specified requirements

2 The degree to which a system component or process meets customer or user needs or expectations

20

Software Quality Pressmanrsquos def

Conformance to explicitly stated functional and performance requirements explicitly documented standards and implicit characteristics that are expected of all professionally developed software

21

Software Quality Assurance The IEEE Definition

SQA is

1 A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements

SQA What is SQA

SQA is the process of assuring people that

every effort has been made to ensure that

software products have the desired level of

reliability maintainability usability

SQA What is Software (System) Quality

Absence of defects

Fitness for use

Meets specifications

Adherence to CMM or ISO quality standards

Reliable Maintainable Useable

SQA An SQA Program

Minimizing number of defects in delivered sw

Creating mechanisms for controlling software

development and maintenance so that costs and

schedules can be met

Making certain that the delivered product can be

used in its intended marketplace

Improving the quality of future products

25

Software Quality Assurance Vs Software Quality Control

Quality Control a set of activities designed to evaluate the quality of a developed or manufactured product It take place before the product is shipped to the client

Quality Assurance the main objective is to minimize the cost of guaranteeing quality by a variety of activities performed throughout the causes of errors and detect and correct them early in the dev Process

6

Quality ConceptsQuality Concepts

Quality of Design refers to the characteristics that designerrsquos specify for an item

Quality Control is the series of inspections reviews and tests used throughout the development cycle to ensure that each work product meets the requirements placed upon it

Quality of Conformance is the degree to which the design specifications are followed during manufacturing

7

(contd)(contd)

Quality policy refers to the basic aims and objectives of an organization regarding quality as stipulated by the management

Quality assurance consists of the auditing and reporting functions of management

Cost of Quality includes all costs incurred in the pursuit of quality or in performing quality related activities such as appraisal costs failure costs and external failure costs

8

(contd)(contd)

Quality planning is the process of assessing the requirements of the procedure and of the product and the context in which these must be observed

Quality testing is assessment of the extent to which a test object meets given requirements

Quality assurance plan is the central aid for planning and checking the quality assurance

Quality assurance system is the organizational structure responsibilities procedures processes and resources for implementing quality management

29

SQ Factors

The requirements document is one of the most important elements for achieving SQ

What is a ldquoGoodrdquo SQ requirements document

Software quality factors

Product operation factors

Product revision factors

Product transition factors

31

Classification of SW requirements into SW quality factors

McCallrsquos Factor Model This model classifies all SW requirements into 11 SW

quality factors grouped into 3 categories Product operation Correctness Reliability Efficiency

Integrity Usability Product revision Maintainability Flexibility Testability Product transition Portability Reusability

Interoperability

McCallrsquos Quality Factors and Criteria

Table 171 McCallrsquos quality factors [10]

Product operation factors

Correctness extent to which a program fulfills its specification

Reliability ability not to fail Efficiency use of resources execution

and storage Integrity protection of the program from

unauthorized access Usability ease of use of the software

33

Product revision factors

Maintainability effort required to locate and fix a fault in a program

Flexibility ease of making changes required by changes in operating environment

Testability ease of testing the program to ensure that it is error-free and meets its specification

34

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 20: STQA

20

Software Quality Pressmanrsquos def

Conformance to explicitly stated functional and performance requirements explicitly documented standards and implicit characteristics that are expected of all professionally developed software

21

Software Quality Assurance The IEEE Definition

SQA is

1 A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements

SQA What is SQA

SQA is the process of assuring people that

every effort has been made to ensure that

software products have the desired level of

reliability maintainability usability

SQA What is Software (System) Quality

Absence of defects

Fitness for use

Meets specifications

Adherence to CMM or ISO quality standards

Reliable Maintainable Useable

SQA An SQA Program

Minimizing number of defects in delivered sw

Creating mechanisms for controlling software

development and maintenance so that costs and

schedules can be met

Making certain that the delivered product can be

used in its intended marketplace

Improving the quality of future products

25

Software Quality Assurance Vs Software Quality Control

Quality Control a set of activities designed to evaluate the quality of a developed or manufactured product It take place before the product is shipped to the client

Quality Assurance the main objective is to minimize the cost of guaranteeing quality by a variety of activities performed throughout the causes of errors and detect and correct them early in the dev Process

6

Quality ConceptsQuality Concepts

Quality of Design refers to the characteristics that designerrsquos specify for an item

Quality Control is the series of inspections reviews and tests used throughout the development cycle to ensure that each work product meets the requirements placed upon it

Quality of Conformance is the degree to which the design specifications are followed during manufacturing

7

(contd)(contd)

Quality policy refers to the basic aims and objectives of an organization regarding quality as stipulated by the management

Quality assurance consists of the auditing and reporting functions of management

Cost of Quality includes all costs incurred in the pursuit of quality or in performing quality related activities such as appraisal costs failure costs and external failure costs

8

(contd)(contd)

Quality planning is the process of assessing the requirements of the procedure and of the product and the context in which these must be observed

Quality testing is assessment of the extent to which a test object meets given requirements

Quality assurance plan is the central aid for planning and checking the quality assurance

Quality assurance system is the organizational structure responsibilities procedures processes and resources for implementing quality management

29

SQ Factors

The requirements document is one of the most important elements for achieving SQ

What is a ldquoGoodrdquo SQ requirements document

Software quality factors

Product operation factors

Product revision factors

Product transition factors

31

Classification of SW requirements into SW quality factors

McCallrsquos Factor Model This model classifies all SW requirements into 11 SW

quality factors grouped into 3 categories Product operation Correctness Reliability Efficiency

Integrity Usability Product revision Maintainability Flexibility Testability Product transition Portability Reusability

Interoperability

McCallrsquos Quality Factors and Criteria

Table 171 McCallrsquos quality factors [10]

Product operation factors

Correctness extent to which a program fulfills its specification

Reliability ability not to fail Efficiency use of resources execution

and storage Integrity protection of the program from

unauthorized access Usability ease of use of the software

33

Product revision factors

Maintainability effort required to locate and fix a fault in a program

Flexibility ease of making changes required by changes in operating environment

Testability ease of testing the program to ensure that it is error-free and meets its specification

34

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 21: STQA

21

Software Quality Assurance The IEEE Definition

SQA is

1 A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements

SQA What is SQA

SQA is the process of assuring people that

every effort has been made to ensure that

software products have the desired level of

reliability maintainability usability

SQA What is Software (System) Quality

Absence of defects

Fitness for use

Meets specifications

Adherence to CMM or ISO quality standards

Reliable Maintainable Useable

SQA An SQA Program

Minimizing number of defects in delivered sw

Creating mechanisms for controlling software

development and maintenance so that costs and

schedules can be met

Making certain that the delivered product can be

used in its intended marketplace

Improving the quality of future products

25

Software Quality Assurance Vs Software Quality Control

Quality Control a set of activities designed to evaluate the quality of a developed or manufactured product It take place before the product is shipped to the client

Quality Assurance the main objective is to minimize the cost of guaranteeing quality by a variety of activities performed throughout the causes of errors and detect and correct them early in the dev Process

6

Quality ConceptsQuality Concepts

Quality of Design refers to the characteristics that designerrsquos specify for an item

Quality Control is the series of inspections reviews and tests used throughout the development cycle to ensure that each work product meets the requirements placed upon it

Quality of Conformance is the degree to which the design specifications are followed during manufacturing

7

(contd)(contd)

Quality policy refers to the basic aims and objectives of an organization regarding quality as stipulated by the management

Quality assurance consists of the auditing and reporting functions of management

Cost of Quality includes all costs incurred in the pursuit of quality or in performing quality related activities such as appraisal costs failure costs and external failure costs

8

(contd)(contd)

Quality planning is the process of assessing the requirements of the procedure and of the product and the context in which these must be observed

Quality testing is assessment of the extent to which a test object meets given requirements

Quality assurance plan is the central aid for planning and checking the quality assurance

Quality assurance system is the organizational structure responsibilities procedures processes and resources for implementing quality management

29

SQ Factors

The requirements document is one of the most important elements for achieving SQ

What is a ldquoGoodrdquo SQ requirements document

Software quality factors

Product operation factors

Product revision factors

Product transition factors

31

Classification of SW requirements into SW quality factors

McCallrsquos Factor Model This model classifies all SW requirements into 11 SW

quality factors grouped into 3 categories Product operation Correctness Reliability Efficiency

Integrity Usability Product revision Maintainability Flexibility Testability Product transition Portability Reusability

Interoperability

McCallrsquos Quality Factors and Criteria

Table 171 McCallrsquos quality factors [10]

Product operation factors

Correctness extent to which a program fulfills its specification

Reliability ability not to fail Efficiency use of resources execution

and storage Integrity protection of the program from

unauthorized access Usability ease of use of the software

33

Product revision factors

Maintainability effort required to locate and fix a fault in a program

Flexibility ease of making changes required by changes in operating environment

Testability ease of testing the program to ensure that it is error-free and meets its specification

34

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 22: STQA

SQA What is SQA

SQA is the process of assuring people that

every effort has been made to ensure that

software products have the desired level of

reliability maintainability usability

SQA What is Software (System) Quality

Absence of defects

Fitness for use

Meets specifications

Adherence to CMM or ISO quality standards

Reliable Maintainable Useable

SQA An SQA Program

Minimizing number of defects in delivered sw

Creating mechanisms for controlling software

development and maintenance so that costs and

schedules can be met

Making certain that the delivered product can be

used in its intended marketplace

Improving the quality of future products

25

Software Quality Assurance Vs Software Quality Control

Quality Control a set of activities designed to evaluate the quality of a developed or manufactured product It take place before the product is shipped to the client

Quality Assurance the main objective is to minimize the cost of guaranteeing quality by a variety of activities performed throughout the causes of errors and detect and correct them early in the dev Process

6

Quality ConceptsQuality Concepts

Quality of Design refers to the characteristics that designerrsquos specify for an item

Quality Control is the series of inspections reviews and tests used throughout the development cycle to ensure that each work product meets the requirements placed upon it

Quality of Conformance is the degree to which the design specifications are followed during manufacturing

7

(contd)(contd)

Quality policy refers to the basic aims and objectives of an organization regarding quality as stipulated by the management

Quality assurance consists of the auditing and reporting functions of management

Cost of Quality includes all costs incurred in the pursuit of quality or in performing quality related activities such as appraisal costs failure costs and external failure costs

8

(contd)(contd)

Quality planning is the process of assessing the requirements of the procedure and of the product and the context in which these must be observed

Quality testing is assessment of the extent to which a test object meets given requirements

Quality assurance plan is the central aid for planning and checking the quality assurance

Quality assurance system is the organizational structure responsibilities procedures processes and resources for implementing quality management

29

SQ Factors

The requirements document is one of the most important elements for achieving SQ

What is a ldquoGoodrdquo SQ requirements document

Software quality factors

Product operation factors

Product revision factors

Product transition factors

31

Classification of SW requirements into SW quality factors

McCallrsquos Factor Model This model classifies all SW requirements into 11 SW

quality factors grouped into 3 categories Product operation Correctness Reliability Efficiency

Integrity Usability Product revision Maintainability Flexibility Testability Product transition Portability Reusability

Interoperability

McCallrsquos Quality Factors and Criteria

Table 171 McCallrsquos quality factors [10]

Product operation factors

Correctness extent to which a program fulfills its specification

Reliability ability not to fail Efficiency use of resources execution

and storage Integrity protection of the program from

unauthorized access Usability ease of use of the software

33

Product revision factors

Maintainability effort required to locate and fix a fault in a program

Flexibility ease of making changes required by changes in operating environment

Testability ease of testing the program to ensure that it is error-free and meets its specification

34

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 23: STQA

SQA What is Software (System) Quality

Absence of defects

Fitness for use

Meets specifications

Adherence to CMM or ISO quality standards

Reliable Maintainable Useable

SQA An SQA Program

Minimizing number of defects in delivered sw

Creating mechanisms for controlling software

development and maintenance so that costs and

schedules can be met

Making certain that the delivered product can be

used in its intended marketplace

Improving the quality of future products

25

Software Quality Assurance Vs Software Quality Control

Quality Control a set of activities designed to evaluate the quality of a developed or manufactured product It take place before the product is shipped to the client

Quality Assurance the main objective is to minimize the cost of guaranteeing quality by a variety of activities performed throughout the causes of errors and detect and correct them early in the dev Process

6

Quality ConceptsQuality Concepts

Quality of Design refers to the characteristics that designerrsquos specify for an item

Quality Control is the series of inspections reviews and tests used throughout the development cycle to ensure that each work product meets the requirements placed upon it

Quality of Conformance is the degree to which the design specifications are followed during manufacturing

7

(contd)(contd)

Quality policy refers to the basic aims and objectives of an organization regarding quality as stipulated by the management

Quality assurance consists of the auditing and reporting functions of management

Cost of Quality includes all costs incurred in the pursuit of quality or in performing quality related activities such as appraisal costs failure costs and external failure costs

8

(contd)(contd)

Quality planning is the process of assessing the requirements of the procedure and of the product and the context in which these must be observed

Quality testing is assessment of the extent to which a test object meets given requirements

Quality assurance plan is the central aid for planning and checking the quality assurance

Quality assurance system is the organizational structure responsibilities procedures processes and resources for implementing quality management

29

SQ Factors

The requirements document is one of the most important elements for achieving SQ

What is a ldquoGoodrdquo SQ requirements document

Software quality factors

Product operation factors

Product revision factors

Product transition factors

31

Classification of SW requirements into SW quality factors

McCallrsquos Factor Model This model classifies all SW requirements into 11 SW

quality factors grouped into 3 categories Product operation Correctness Reliability Efficiency

Integrity Usability Product revision Maintainability Flexibility Testability Product transition Portability Reusability

Interoperability

McCallrsquos Quality Factors and Criteria

Table 171 McCallrsquos quality factors [10]

Product operation factors

Correctness extent to which a program fulfills its specification

Reliability ability not to fail Efficiency use of resources execution

and storage Integrity protection of the program from

unauthorized access Usability ease of use of the software

33

Product revision factors

Maintainability effort required to locate and fix a fault in a program

Flexibility ease of making changes required by changes in operating environment

Testability ease of testing the program to ensure that it is error-free and meets its specification

34

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 24: STQA

SQA An SQA Program

Minimizing number of defects in delivered sw

Creating mechanisms for controlling software

development and maintenance so that costs and

schedules can be met

Making certain that the delivered product can be

used in its intended marketplace

Improving the quality of future products

25

Software Quality Assurance Vs Software Quality Control

Quality Control a set of activities designed to evaluate the quality of a developed or manufactured product It take place before the product is shipped to the client

Quality Assurance the main objective is to minimize the cost of guaranteeing quality by a variety of activities performed throughout the causes of errors and detect and correct them early in the dev Process

6

Quality ConceptsQuality Concepts

Quality of Design refers to the characteristics that designerrsquos specify for an item

Quality Control is the series of inspections reviews and tests used throughout the development cycle to ensure that each work product meets the requirements placed upon it

Quality of Conformance is the degree to which the design specifications are followed during manufacturing

7

(contd)(contd)

Quality policy refers to the basic aims and objectives of an organization regarding quality as stipulated by the management

Quality assurance consists of the auditing and reporting functions of management

Cost of Quality includes all costs incurred in the pursuit of quality or in performing quality related activities such as appraisal costs failure costs and external failure costs

8

(contd)(contd)

Quality planning is the process of assessing the requirements of the procedure and of the product and the context in which these must be observed

Quality testing is assessment of the extent to which a test object meets given requirements

Quality assurance plan is the central aid for planning and checking the quality assurance

Quality assurance system is the organizational structure responsibilities procedures processes and resources for implementing quality management

29

SQ Factors

The requirements document is one of the most important elements for achieving SQ

What is a ldquoGoodrdquo SQ requirements document

Software quality factors

Product operation factors

Product revision factors

Product transition factors

31

Classification of SW requirements into SW quality factors

McCallrsquos Factor Model This model classifies all SW requirements into 11 SW

quality factors grouped into 3 categories Product operation Correctness Reliability Efficiency

Integrity Usability Product revision Maintainability Flexibility Testability Product transition Portability Reusability

Interoperability

McCallrsquos Quality Factors and Criteria

Table 171 McCallrsquos quality factors [10]

Product operation factors

Correctness extent to which a program fulfills its specification

Reliability ability not to fail Efficiency use of resources execution

and storage Integrity protection of the program from

unauthorized access Usability ease of use of the software

33

Product revision factors

Maintainability effort required to locate and fix a fault in a program

Flexibility ease of making changes required by changes in operating environment

Testability ease of testing the program to ensure that it is error-free and meets its specification

34

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 25: STQA

25

Software Quality Assurance Vs Software Quality Control

Quality Control a set of activities designed to evaluate the quality of a developed or manufactured product It take place before the product is shipped to the client

Quality Assurance the main objective is to minimize the cost of guaranteeing quality by a variety of activities performed throughout the causes of errors and detect and correct them early in the dev Process

6

Quality ConceptsQuality Concepts

Quality of Design refers to the characteristics that designerrsquos specify for an item

Quality Control is the series of inspections reviews and tests used throughout the development cycle to ensure that each work product meets the requirements placed upon it

Quality of Conformance is the degree to which the design specifications are followed during manufacturing

7

(contd)(contd)

Quality policy refers to the basic aims and objectives of an organization regarding quality as stipulated by the management

Quality assurance consists of the auditing and reporting functions of management

Cost of Quality includes all costs incurred in the pursuit of quality or in performing quality related activities such as appraisal costs failure costs and external failure costs

8

(contd)(contd)

Quality planning is the process of assessing the requirements of the procedure and of the product and the context in which these must be observed

Quality testing is assessment of the extent to which a test object meets given requirements

Quality assurance plan is the central aid for planning and checking the quality assurance

Quality assurance system is the organizational structure responsibilities procedures processes and resources for implementing quality management

29

SQ Factors

The requirements document is one of the most important elements for achieving SQ

What is a ldquoGoodrdquo SQ requirements document

Software quality factors

Product operation factors

Product revision factors

Product transition factors

31

Classification of SW requirements into SW quality factors

McCallrsquos Factor Model This model classifies all SW requirements into 11 SW

quality factors grouped into 3 categories Product operation Correctness Reliability Efficiency

Integrity Usability Product revision Maintainability Flexibility Testability Product transition Portability Reusability

Interoperability

McCallrsquos Quality Factors and Criteria

Table 171 McCallrsquos quality factors [10]

Product operation factors

Correctness extent to which a program fulfills its specification

Reliability ability not to fail Efficiency use of resources execution

and storage Integrity protection of the program from

unauthorized access Usability ease of use of the software

33

Product revision factors

Maintainability effort required to locate and fix a fault in a program

Flexibility ease of making changes required by changes in operating environment

Testability ease of testing the program to ensure that it is error-free and meets its specification

34

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 26: STQA

6

Quality ConceptsQuality Concepts

Quality of Design refers to the characteristics that designerrsquos specify for an item

Quality Control is the series of inspections reviews and tests used throughout the development cycle to ensure that each work product meets the requirements placed upon it

Quality of Conformance is the degree to which the design specifications are followed during manufacturing

7

(contd)(contd)

Quality policy refers to the basic aims and objectives of an organization regarding quality as stipulated by the management

Quality assurance consists of the auditing and reporting functions of management

Cost of Quality includes all costs incurred in the pursuit of quality or in performing quality related activities such as appraisal costs failure costs and external failure costs

8

(contd)(contd)

Quality planning is the process of assessing the requirements of the procedure and of the product and the context in which these must be observed

Quality testing is assessment of the extent to which a test object meets given requirements

Quality assurance plan is the central aid for planning and checking the quality assurance

Quality assurance system is the organizational structure responsibilities procedures processes and resources for implementing quality management

29

SQ Factors

The requirements document is one of the most important elements for achieving SQ

What is a ldquoGoodrdquo SQ requirements document

Software quality factors

Product operation factors

Product revision factors

Product transition factors

31

Classification of SW requirements into SW quality factors

McCallrsquos Factor Model This model classifies all SW requirements into 11 SW

quality factors grouped into 3 categories Product operation Correctness Reliability Efficiency

Integrity Usability Product revision Maintainability Flexibility Testability Product transition Portability Reusability

Interoperability

McCallrsquos Quality Factors and Criteria

Table 171 McCallrsquos quality factors [10]

Product operation factors

Correctness extent to which a program fulfills its specification

Reliability ability not to fail Efficiency use of resources execution

and storage Integrity protection of the program from

unauthorized access Usability ease of use of the software

33

Product revision factors

Maintainability effort required to locate and fix a fault in a program

Flexibility ease of making changes required by changes in operating environment

Testability ease of testing the program to ensure that it is error-free and meets its specification

34

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 27: STQA

7

(contd)(contd)

Quality policy refers to the basic aims and objectives of an organization regarding quality as stipulated by the management

Quality assurance consists of the auditing and reporting functions of management

Cost of Quality includes all costs incurred in the pursuit of quality or in performing quality related activities such as appraisal costs failure costs and external failure costs

8

(contd)(contd)

Quality planning is the process of assessing the requirements of the procedure and of the product and the context in which these must be observed

Quality testing is assessment of the extent to which a test object meets given requirements

Quality assurance plan is the central aid for planning and checking the quality assurance

Quality assurance system is the organizational structure responsibilities procedures processes and resources for implementing quality management

29

SQ Factors

The requirements document is one of the most important elements for achieving SQ

What is a ldquoGoodrdquo SQ requirements document

Software quality factors

Product operation factors

Product revision factors

Product transition factors

31

Classification of SW requirements into SW quality factors

McCallrsquos Factor Model This model classifies all SW requirements into 11 SW

quality factors grouped into 3 categories Product operation Correctness Reliability Efficiency

Integrity Usability Product revision Maintainability Flexibility Testability Product transition Portability Reusability

Interoperability

McCallrsquos Quality Factors and Criteria

Table 171 McCallrsquos quality factors [10]

Product operation factors

Correctness extent to which a program fulfills its specification

Reliability ability not to fail Efficiency use of resources execution

and storage Integrity protection of the program from

unauthorized access Usability ease of use of the software

33

Product revision factors

Maintainability effort required to locate and fix a fault in a program

Flexibility ease of making changes required by changes in operating environment

Testability ease of testing the program to ensure that it is error-free and meets its specification

34

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 28: STQA

8

(contd)(contd)

Quality planning is the process of assessing the requirements of the procedure and of the product and the context in which these must be observed

Quality testing is assessment of the extent to which a test object meets given requirements

Quality assurance plan is the central aid for planning and checking the quality assurance

Quality assurance system is the organizational structure responsibilities procedures processes and resources for implementing quality management

29

SQ Factors

The requirements document is one of the most important elements for achieving SQ

What is a ldquoGoodrdquo SQ requirements document

Software quality factors

Product operation factors

Product revision factors

Product transition factors

31

Classification of SW requirements into SW quality factors

McCallrsquos Factor Model This model classifies all SW requirements into 11 SW

quality factors grouped into 3 categories Product operation Correctness Reliability Efficiency

Integrity Usability Product revision Maintainability Flexibility Testability Product transition Portability Reusability

Interoperability

McCallrsquos Quality Factors and Criteria

Table 171 McCallrsquos quality factors [10]

Product operation factors

Correctness extent to which a program fulfills its specification

Reliability ability not to fail Efficiency use of resources execution

and storage Integrity protection of the program from

unauthorized access Usability ease of use of the software

33

Product revision factors

Maintainability effort required to locate and fix a fault in a program

Flexibility ease of making changes required by changes in operating environment

Testability ease of testing the program to ensure that it is error-free and meets its specification

34

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 29: STQA

29

SQ Factors

The requirements document is one of the most important elements for achieving SQ

What is a ldquoGoodrdquo SQ requirements document

Software quality factors

Product operation factors

Product revision factors

Product transition factors

31

Classification of SW requirements into SW quality factors

McCallrsquos Factor Model This model classifies all SW requirements into 11 SW

quality factors grouped into 3 categories Product operation Correctness Reliability Efficiency

Integrity Usability Product revision Maintainability Flexibility Testability Product transition Portability Reusability

Interoperability

McCallrsquos Quality Factors and Criteria

Table 171 McCallrsquos quality factors [10]

Product operation factors

Correctness extent to which a program fulfills its specification

Reliability ability not to fail Efficiency use of resources execution

and storage Integrity protection of the program from

unauthorized access Usability ease of use of the software

33

Product revision factors

Maintainability effort required to locate and fix a fault in a program

Flexibility ease of making changes required by changes in operating environment

Testability ease of testing the program to ensure that it is error-free and meets its specification

34

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 30: STQA

Software quality factors

Product operation factors

Product revision factors

Product transition factors

31

Classification of SW requirements into SW quality factors

McCallrsquos Factor Model This model classifies all SW requirements into 11 SW

quality factors grouped into 3 categories Product operation Correctness Reliability Efficiency

Integrity Usability Product revision Maintainability Flexibility Testability Product transition Portability Reusability

Interoperability

McCallrsquos Quality Factors and Criteria

Table 171 McCallrsquos quality factors [10]

Product operation factors

Correctness extent to which a program fulfills its specification

Reliability ability not to fail Efficiency use of resources execution

and storage Integrity protection of the program from

unauthorized access Usability ease of use of the software

33

Product revision factors

Maintainability effort required to locate and fix a fault in a program

Flexibility ease of making changes required by changes in operating environment

Testability ease of testing the program to ensure that it is error-free and meets its specification

34

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 31: STQA

31

Classification of SW requirements into SW quality factors

McCallrsquos Factor Model This model classifies all SW requirements into 11 SW

quality factors grouped into 3 categories Product operation Correctness Reliability Efficiency

Integrity Usability Product revision Maintainability Flexibility Testability Product transition Portability Reusability

Interoperability

McCallrsquos Quality Factors and Criteria

Table 171 McCallrsquos quality factors [10]

Product operation factors

Correctness extent to which a program fulfills its specification

Reliability ability not to fail Efficiency use of resources execution

and storage Integrity protection of the program from

unauthorized access Usability ease of use of the software

33

Product revision factors

Maintainability effort required to locate and fix a fault in a program

Flexibility ease of making changes required by changes in operating environment

Testability ease of testing the program to ensure that it is error-free and meets its specification

34

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 32: STQA

McCallrsquos Quality Factors and Criteria

Table 171 McCallrsquos quality factors [10]

Product operation factors

Correctness extent to which a program fulfills its specification

Reliability ability not to fail Efficiency use of resources execution

and storage Integrity protection of the program from

unauthorized access Usability ease of use of the software

33

Product revision factors

Maintainability effort required to locate and fix a fault in a program

Flexibility ease of making changes required by changes in operating environment

Testability ease of testing the program to ensure that it is error-free and meets its specification

34

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 33: STQA

Product operation factors

Correctness extent to which a program fulfills its specification

Reliability ability not to fail Efficiency use of resources execution

and storage Integrity protection of the program from

unauthorized access Usability ease of use of the software

33

Product revision factors

Maintainability effort required to locate and fix a fault in a program

Flexibility ease of making changes required by changes in operating environment

Testability ease of testing the program to ensure that it is error-free and meets its specification

34

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 34: STQA

Product revision factors

Maintainability effort required to locate and fix a fault in a program

Flexibility ease of making changes required by changes in operating environment

Testability ease of testing the program to ensure that it is error-free and meets its specification

34

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 35: STQA

Product transition factors

Portability Effort required to transfer a program from one environment to another system

Reusability ease of re-using software in a different context

Interoperability effort required to couple a system to another system

35

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 36: STQA

36

Product operation SW quality factors Correctness Output specifications are usually

multidimensional some common include The output mission The required accuracy The completeness The up-to-dateness of the info The availability of the info( the reaction time ) The standards for coding and documenting the SW system

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 37: STQA

37

Product operation SW quality factors

Reliability

Deals with failures to provide service They determine the maximum allowed SW system failure rate and can refer to the entire system or to one or more of its separate functions

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 38: STQA

38

Product operation SW quality factors

Efficiency

Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements

Integrity

Deals with the SW system security that is requirements to prevent access to unauthorized persons

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 39: STQA

39

Product operation SW quality factors

Usability

Deals with the scope of staff resources needed to train a new employee and to operate the SW system

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 40: STQA

40

Product revision SW quality factors

Maintainability

Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures to correct the failure and to verify the success of the corrections

Example Typical maintainability requirements

1 The size of a SW module will not exceed 30 statements

2 The programming will adhere to the company coding standards and guidelines

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 41: STQA

41

Product revision SW quality factors

Flexibility

The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements This factorrsquos requirements also support perfective maintenance activities such as changes and additions to the SW in order to improve its service and adapt it to changes in the firmrsquos technical or commercial environment

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 42: STQA

42

Product revision SW quality factors

Testability - Deal with the testing of an IS as well as with its operation- Providing predefined intermediate results and log files- Automatic diagnostics performed by the SW system prior

starting the system to find out whether all components of SW system are in working order

- Obtain a report about detected faults

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 43: STQA

43

Product transition SW quality factors

Portability - Tend to the adaptation of a SW system to other

environments consisting - Different HW- Different OS

Example SW designed to work under windows 2000 env Is required to allow low-cost transfer to Linux

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 44: STQA

44

Product transition SW quality factors

Reusability - Deals with the use of SW modules originally designed for

one project in a new SW project currently begin developed

- The reuse of SW is expected to save resources shorten the project period and provide higher quality modules These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 45: STQA

45

Product transition SW quality factors

Interoperability - Focus on creating interfaces with other SW systems or

with other equipment firmware- Example

- The firmware of medical lab equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 46: STQA

46

Alternative Models Of SW Quality Factors

Two other models for SQ factors Evans and Marciniak 1987 ( 12 factors ) Deutsch and Willis 1988 ( 15 factors )

Five new factors were suggested Verifiability Expandability Safety Manageability Survivability

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 47: STQA

47

Five new factors were suggested Verifiability define design and programming features that enable

efficient verification of the design and programming ( modularity simplicity adherence to documentation and prog guidelines )

Expandability refer to future efforts that will be needed to serve larger populations improve services or add new applications in order to improve usability

Safety meant to eliminate conditions hazardous to equipment as a result of errors in process control SW

Manageability refer to the admin tools that support SW modification during the SW development and maintenance periods

Survivability refer to the continuity of service These define the minimum time allowed between failures of the system and the maximum time permitted for recovery of service

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 48: STQA

48

Who is interested in the definition of quality requirements

The client is not the only party interested in defining the requirements that assure the quality of the SW product

The developer is often interested also specially Reusability Verifiability Portability

Any SW project will be carried out according to 2 requirements document The clientrsquos requirements document The developerrsquos additional requirements document

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 49: STQA

49

The SQA system- an SQA architecture

SQA system components can be classified into 6 classes Pre-project components Components of project life cycle activities assessment Components of infrastructure error prevention and

improvement Components of SQ management Components of standardization certification and SQA

system assessment Organizing for SQA- the human components

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 50: STQA

50

Pre-project Components

To assure that

1 The project commitments have been adequately defined considering the resources required the schedule and budget

2 The development and quality plans have been correctly determined

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 51: STQA

51

Components of project life cycle activities assessment

The project life cycle composed of two stages

1 The development Life cycle stage Detect design and programming errors Its components divided into

Reviews Expert opinions Software testing Assurance of the quality of the subcontractorsrsquo work

and customer-supplied parts2 The operation-maintenance stage

Include specialize maintenance components as well as development life cycle components which are applied mainly for functionality improving maintenance tasks

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 52: STQA

52

Components of infrastructure error prevention and improvement

Main objectives of these components which are applied throughout the entire organization are

To eliminate or at least reduce the rate of errors based on the organizationrsquos accumulated SQA experience

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 53: STQA

53

Components of software quality management

This class of components is geared toward several goal

The major ones being the control of development and maintenance activities and introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 54: STQA

54

Components of standardization certification and SQA system assessmentThe main objective of this class are

1 Utilization of international professional knowledge

2 Improvement of coordination of the organizational quality system with other organizations

3 Assessment of the achievements of quality systems according to a common scale

The various standards classified into 2 groupes Quality management standards Project process standards

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 55: STQA

55

Organizing for SQA- the human components

The SQA organizational base includes Managers Testing personnel The SQA unit and practitioners interested in SQ

The main objectives are to initiate and support the implementation of SQA

components Detect deviation from SQA procedures and

methodology Suggest improvements

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 56: STQA

56

The Contract review process and its stages Several situations can lead a SW company to sign

a contract with a customer such as Participation in a tender Submission of a proposal Receipt of an order from a companyrsquos customer Receipt of an internal request or order from another

department in the organization

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 57: STQA

57

The Contract review process and its stages Contract review

is the SQA component devised to guide review drafts of proposal and contract documents

If applicable provides oversight ( supervision ) of the contracts carried out with potential project partners and subcontractors

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 58: STQA

Proposal draft review + Contract draft review --------------------------- Contract review

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 59: STQA

59

The Contract review process itself is conducted in two stages Stage 1 ndash Review of the proposal draft prior to submission

to the potential customer ( proposal draft review ) Reviews the final proposal draft and proposalrsquos foundations Customerrsquos requirement documents Customerrsquos additional details and explanations of the requirements Cost and resources estimates Existing contracts or contract drafts of the supplier with partners and

subcontractors

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 60: STQA

60

The Contract review process itself is conducted in two stages Stage 2 ndash Review of the proposal draft prior to signing

( Contract draft review ) Reviews the contract draft on the basis of the proposal and the understandings ( include changes ) reached during the contract negotiations sessions

The individuals who perform the review thoroughly examine the draft while referring to a comprehensive range of review subjects ( a Check-list ) is very helpful for assuring the full coverage of relevant subjects

See appendix 5A 5B

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 61: STQA

61

Contract Review objectives Proposal draft review objectives( assure the following )

Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been

examined Formal aspects of the relationship between the customer and SW

firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been

prepared Examination of the customerrsquos capacity to fulfill his commitments Definition of partners and subcontractors participation conditions Definition and projection proprietary rights

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 62: STQA

62

Contract Review objectives

Contract draft review objectives( assure the following ) No un-clarified issues remain in the contract draft All the understandings reached between the customer

and the firm are to be fully and correctly documented

No changes additions or omissions that have not been discussed and agreed upon should be introduced into contract draft

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 63: STQA

63

Who performs a contract review The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is

not a member of the proposal team A team of outside experts

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 64: STQA

64

Implementation of a contract review of a major proposal

Recommended approaches for implementing major contract reviews The contract review should be scheduled A team should carry out the contract review A contract team leader should be appointed The activities of the team leader include

Recruitment of the team members Distribution of review tasks Coordination between members Coordination between the review team and the proposal team Follow-up of activities especially compliance with the schedule Summarization of the findings and their delivery to the proposal team

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 65: STQA

65

Development and quality plans Development plans and quality plans are the major elements needed for

project compliance with ISO 90003 standards and ISOIEC 2001 and with IEEE 730

It is also an important element in the Capability Maturity Model ( CMM ) for assessment of SW development organization maturity

The projects needs development and quality plans that Are based on proposal materials that have been re-examined and

thoroughly updated Are more comprehensive than the approved proposal especially

with respect to schedules resources estimates and development risk evaluations

Include additional subjects absent from the approved proposal others

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 66: STQA

66

Development plan and quality plan objectives1 Scheduling development activities that will lead to

successful and timely completion of the project and estimating the required manpower resources and budget

2 Recruiting team members and allocating development resources

3 Resolving development risks4 Implementing required SQA activities5 Providing mgt with data needed for project control

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 67: STQA

67

Elements of the development plan1 Project products2 Project interfaces3 Project methodology and development tools4 SW development standards and procedures5 The mapping of the development process( proj mgt Gant )6 Project milestones ( documents code report )7 Project staff organization ( org stru prof req no of team mem

names of team leaders )8 Development facilities ( SW HW tools space period req for each

use )9 Development risks ( see next slide )10 Control methods11 Project cost estimation

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 68: STQA

68

Elements of Quality Plan1 Quality goals ( quantitative measures )2 Planned review activities

The scope of review activity The type The schedule ( priorities ) The specific procedure to be applied Who responsible for carrying out the rev act

3 Planned SW tests ( a complete list of planned SW tests should be provided ) each test

The unit integration or the complete system to be tested The type of testing activities to be carried out The planned test schedule The specific procedure Who responsible

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 69: STQA

69

Elements of Quality Plan

4 Planned acceptance tests for externally developed SW

5 Configuration management configuration mgt tools and procedures including those change-control procedures meant to be applied throughout the project

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 70: STQA

Maintenance service components

Corrective maintenance support services and software corrections

Adaptive maintenance adapts the software package to differences in new customer

requirements Functionality improvement maintenance

perfective maintenance of new functions added to the software so as to enhance performance

preventive maintenance activities that improve reliability and system infrastructure for easier and more efficient future maintainability

70

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 71: STQA

Maintenance software quality assurance tools

SQA tools for corrective maintenance SQA tools for functionality improvement

maintenance SQA infrastructure tools for software

maintenance SQA tools for managerial control of software

maintenance

71

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 72: STQA

Maintenance software quality assurance tools

SQA tools for corrective maintenance Entail (User support services and Software

corrections ldquobug repairsrdquo) Most bug repair tasks require the use of

mini-testing tool Required to handle repair patch (small-scale)

tasks (small number of coding line to be corrected rapidly)

72

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 73: STQA

Maintenance software quality assurance tools

SQA tools for functionality improvement maintenance The same project life cycle tools are applied

(reviews and testing etc) Are implemented also for large-scale

adaptive maintenance tasks

73

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 74: STQA

Maintenance software quality assurance tools

SQA infrastructure component for SW maintenance We need SQA infrastructure tools for

Maintenance procedures and work instructions Supporting quality devices Preventive and corrective actions Configuration management Documentation and quality record control Training and certification of maintenance teams

74

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 75: STQA

Maintenance software quality assurance tools

Maintenance procedures and work instructions Remote handling of request for service On-site handling User support service Quality assurance control Customer satisfaction surveys

75

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 76: STQA

Maintenance software quality assurance tools

Supporting quality devices Checklists for location of causes for a failure Templates for reporting how software failure were

solved Checklists for preparing a mini testing procedure

document

76

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 77: STQA

Maintenance software quality assurance tools

Preventive and corrective actions Directed and controlled the CAB

Corrective Action Board Changes in content and frequency of customer requests for

user support services Increased average time invested in complying with

customerrsquos user support requests Increased average time invested in repairing customerrsquos

software failures

Increased percentage of software correction failures

77

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 78: STQA

Configuration management Failure repair

Software system version installed at the customerrsquos site A copy of the current code and its documentation

Group replacement Decision making about the advisability of performing a group

replacement Planning the group replacement allocating resources and

determining the timetable

Maintenance documentation and quality records

78

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 79: STQA

The objectives of training and certification To develop the knowledge and skills new staff need

to perform software development and maintenance tasks at an adequate level of efficiency and effectiveness

Such training facilitates integration of new team members

To assure conformity to the organizationrsquos standards for software products (documents and code) by transmitting style and structure procedures together with work instructions

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 80: STQA

To update the knowledge and skills of staff in response to developments in the organization and to assure efficient and effective performance of tasks as well as conformity to the organizationrsquos style and structure procedures and work instructions

To transmit knowledge of SQA procedures To assure that candidates for key software

development and maintenance positions are adequately qualified

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 81: STQA

The training and certification process The operation of a successful training and certification

system demands that the following activities be regularly performed

Determine the professional knowledge requirements for each position

Determine the professional training and updating needs Plan the professional training program Plan the professional updating program Define positions requiring certification Plan certification processes Deliver training updating and certification programs Perform follow-up of trained and certified staff

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 82: STQA

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training certification and adaptation to changing quality requirements

Training and certification activities are meant to fill the needs of staff and new employees

Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 83: STQA

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 of irregularities as well as development and assimilation of improved practices and procedures together with control of their implementation and measurement of their outcomes

83

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 84: STQA

Corrective and preventive actions (CAPA) definition

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 outcomes

84

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 85: STQA

The corrective and preventive actions process

Information collection Analysis of information Development of solutions and improved

methods Implementation of improved methods Follow-up

85

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 86: STQA

Development of solutions and their implementation

1 Updating relevant procedures

2 Changes in practices including updating of relevant work instructions

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

4 Improvement of reporting methods

5 Initiatives for training retraining or updating staff

86

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 87: STQA

Follow-up of activities

1 Follow-up of the flow of development and maintenance CAPA records

2 Follow-up of implementation

3 Follow-up of outcomes

87

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 88: STQA

Organizing for preventive and corrective actions CAPA activities depends on

the existence of a permanent core organizational ad hoc team participants

Can be members of the SQA unit top-level professionals development and

maintenance department managers

88

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 89: STQA

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

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 90: STQA

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

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 91: STQA

A unit of software code a document or piece of hardware is defined as an SCI if it is assumed that it may be needed for further development of the software system andor its maintenance

A software configuration is composed of as many SCIs as the developers assume will be needed in the future with each SCI approved identified and registered

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 92: STQA

The SCIs are generally placed into four classesas follows

Design documents Software code Data files including files of test cases and

test scripts Software development tools

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 93: STQA

software configuration management software configuration management

(SCM) is the task of tracking and controlling changes in the software

SCM are the practices and procedures for administering source code producing software development builds controlling change and managing software configurations

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 94: STQA

Specifically SCM ensures the integrity reliability and reproducibility of developing software products from conception to release

SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning and performing a set of activities to provide adequate confidence that quality is being built into the software

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 95: STQA

SCM is the development and use of software technical standards and processes for managing evolving software systems

SCM is closely related to the software quality assurance (SQA) activity

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 96: STQA

The tasks of software configuration management The tasks of software configuration

management may be classified into four groups Control software change Release of SCI and software configuration versions Provision of SCM information services Verification of compliance to SCM procedures

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 97: STQA

Software change control

Grant approval to carry out changes Control the changes and assure the quality

of approved changes Document the approved changes Apply mechanisms that coordinate the

changes made to the SCI by preventing more than one team from simultaneously introducing changes into the same SCI

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 98: STQA

3 basic SQA management tools 1048709 Project Progress Control 1048709 Software Quality Metrics 1048709 Software Quality Costs

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 99: STQA

Project Progress Control enables management to oversee each project and initiate when required And how changes and improvements in a project is performed

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 100: STQA

Project Progress Control

Delay in completing project mostly caused by optimistic scheduling and budgeting unprofessional software risk management belated identification of schedule and budget

difficulties underestimation

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 101: STQA

Components of Project Progress Control 1 Control of Risk Management activities begin with

the preparation of periodic assessments about the state of the SW risk items and the expected outcomes of the risk management activities performed in their wake

2 Project schedule control deals with the projectrsquos compliance with its approved and contracted timetables

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 102: STQA

3 Project resource control focuses on professional human resources internal composition or allocation

4 Project Budget Control based on the comparison of actual with scheduled expenditure more accurate picture of budget deviations requires

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 103: STQA

Project Progress Control

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 104: STQA

104

Examples of Metrics from Everyday Life

Working and living Cost of utilities for the month Cost of groceries for the month Amount of monthly rent per month Time spent at work each Saturday for the past month Time spent mowing the lawn for the past two times

College experience Grades received in class last semester Number of classes taken each semester Amount of time spent in class this week Amount of time spent on studying and homework this week Number of hours of sleep last night

Travel Time to drive from home to the airport Amount of miles traveled today Cost of meals and lodging for yesterday

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 105: STQA

Software quality metrics

Metrics measurable ways to design and assess the software product

Process and project metrics apply to the project as a whole

Project metrics focus on specific attributes of the project

Collected as technical tasks are being conducted

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 106: STQA

Quality metrics

a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the SW possesses a given quality attribute

106

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 107: STQA

Quality metrics

ldquoYou canrsquot control what you canrsquot measurerdquo

Tom DeMarco (1982)

IEEE definition A quantitative measure of the degree to

which an item possesses a given quality attribute

107

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 108: STQA

Main objectives of software quality metrics

To facilitate management control planning and execution of the appropriate managerial interventions

To identify situations that require development or maintenance process improvement in the form of preventive or corrective actions

108

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 109: STQA

Software quality metrics

Depend on system size measures by (KLOC Function Point) KLOC Measures the size of software by

thousands of code lines ldquoClassic metricrdquo Function Point

It measures project size by functionality indicated in the customerrsquos or tender requirement specification

109

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 110: STQA

Software quality metrics Classification

Process metrics Related to the software development process

Product metrics Related to software maintenance

110

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 111: STQA

Process metric ndash A metric used to measure characteristics of the methods techniques and tools employed in developing implementing and maintaining a software system

Product metric ndash A metric used to measure that characteristic of any product of the software development process

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 112: STQA

Process metrics1 Software process quality metrics

Error density metrics Error severity metrics

2 Software process timetable metrics

3 Error removal effectiveness metrics

4 Software process productivity metrics

112

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 113: STQA

Product metric

Refer to the software systemrsquos operational phase (Customer services)

Customer services have two types Help desk services (HD)

Method of application of the software and solution of customer implementation problems

Corrective maintenance services correction of software failures identified by users or

detected by the customer service team

113

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 114: STQA

Product metric

Can be classified into1 HD quality metrics

2 HD productivity and effectiveness metrics

3 Corrective maintenance quality metrics

4 Corrective maintenance productivity and effectiveness metrics

114

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 115: STQA

Limitations of software metrics

The main problem in software quality metrics are rooted in the attributes measured Programming style Volume of documentation comments Software complexity Percentage of reused code Professionalism of design review and software

testing teams Reporting style of the review and testing results

115

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 116: STQA

Objectives of cost quality metrics Control budgeted expenditures (for SQA

prevention and appraisal activities) Previous yearrsquos failure costs Previous projectrsquos quality costs (control costs

and failure costs) Other departmentrsquos quality costs (control

costs and failure costs)

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 117: STQA

The classic model of cost of software quality It provides a methodology for classifying the

costs associated with product quality assurance from an economic point of view It is Developed to suit the quality situations found in manufacturing organizations the model has since been widely implemented

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 118: STQA

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 119: STQA

The model classifies costs related to product quality into two general classes

Costs of control include costs that are spent to prevent and detect software errors in order to reduce them to an accepted level

Costs of failure of control include costs of failures that occurred because of failure to prevent and detect software errors

The model further subdivides these into subclasses

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 120: STQA

Costs of control are assigned to either the prevention or the appraisal costs subclass

Prevention costs include investments in quality infrastructure and quality activities that are not directed to a specific project or system being general to the organization

Appraisal costs include the costs of activities performed for a specific project or software system for the purpose of detecting software errors

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 121: STQA

Failures of control costs are further classified into internal failure costs and external failure costs

Internal failure costs include costs of correcting errors that have been detected by design reviews software tests and acceptance tests (carried out by the customer) and completed before the software is installed at customer sites

External failure costs include all costs of correcting failures detected by customers or the maintenance team after the software system has been installed

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 122: STQA

Cost of software quality

Prevention costs

Appraisal costs

Internal failure costs

External failure costs

Costs of Control costs

Costs of Failure of

control costs

Managerial preparations

and control costs

Managerial failure costs

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 123: STQA

Costs of carrying out contract reviews Costs of preparing project plans

including quality plans Costs of periodic updating of project

and quality plans Costs of performing regular progress

control of external participantsrsquo contributions to projects

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 124: STQA

Managerial failure costs

Unplanned costs for professional resources resulting from underestimation of the resources

Damages paid to customers as compensation for late project completion a result of the unrealistic schedule

Damages paid to customers as compensation for late completion of the project a result of managementrsquos failure to recruit team members

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 125: STQA

Standards certification and assessment ISO 9000-1and ISO 9000-3

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 126: STQA

The benefits of use of standards The ability to apply software development and

maintenance methodologies and procedures of the highest professional level

Better mutual understanding and coordination among development teams but especially between development and maintenance teams

Greater cooperation between the software developer and external participants in the project

Better understanding and cooperation between suppliers and customers based on the adoption of known development and maintenance standards as part of the contract

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 127: STQA

The organizations involved in standards development Development of SQA standards has been

undertaken by several national and

international standards institutes professional and industry-oriented organizations that invest remarkable amounts of resources in these projects

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 128: STQA

The following institutes and organizations among the most prominent developers of SQA and software engineering standards have gained international reputation and standing in this area

IEEE (Institute of Electrical and Electronics Engineers) Computer Society

ISO (International Organization for Standardization) DOD (US Department of Defense) ANSI (American National Standards Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association)

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 129: STQA

Classification of SQA standards Software quality assurance standards can be

classified into two main classes Software quality assurance management

standards including certification and assessment methodologies (quality management standards)

Software project development process standards (project process standards)

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 130: STQA

Quality management standards These focus on the organizationrsquos SQA

system infrastructure and requirements while leaving the choice of methods and tools to the organization ISO 9000-3 and the Capability Maturity Model (CMM) are respectively examples of a standard and a methodology belonging to this class

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 131: STQA

Project process standards

These focus on the methodologies for carrying out software development and maintenance projects that is on ldquohowrdquo a software project is to be implemented

These standards define the steps to be taken design documentation requirements the contents of design documents design reviews and review issues software testing to be performed and testing topics and so forth

Naturally due to their characteristics many SQA standards in this class can serve as software engineering standards and vice versa

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 132: STQA

Examples of standards in use ISO 9000-3 and IEEEIEA 12207 are examples of

comprehensive standards that cover all aspects of software quality management and the software development life cycle respectively

Examples of specialized standards of both classes may be found in IEEE software engineering standards such as IEEE Std 730-1998 for software quality assurance plans IEEE Std 1012-1998 for software verification and validation and IEEE Std 1045-1992 for software productivity metrics

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 133: STQA

Quality management standards Quality management standards and methodologies focus on

the software quality assurance system ndash its organization infrastructure and requirements ndash yet leave the choice of the methods and tools to be used in the hands of the organization

In other words these standards focus on the ldquowhatrdquo of SQA and not its ldquohowrdquo

Standards belonging to this class especially ISO 9000-3 structure the SQA certification procedures that are applied to organizations developing software

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 134: STQA

Describe the ISO 9000-3 certification process To acquire ISO 9000-3 certification organizations must Plan the organizationrsquos activities for gaining certification Develop the organizationrsquos SQA system including

procedures Obtain approval of procedures by the certifying organization Implement the organizationrsquos SQA system Undergo certification audits of actual performance of the

SQA system

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 135: STQA

ISO 9000-3

ISO 9000-3 the Guidelines offered by the International Organization for Standardization (ISO) represent implementation of the general methodology of quality management ISO 9000 Standards to the special case of software development and maintenance

The ISO 9000-3 Standard for the software industry can be considered to provide the requirements for ISO 9000-3 certification

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 136: STQA

ISO 9000-3 quality management system guiding principles

Eight principles guide the new ISO 9000-3 standard(1) Customer focus Organizations depend on their

customers and therefore should understand current and future customer needs

(2) Leadership Leaders establish the organizationrsquos vision They should create and maintain an internal environment in which people can become fully involved in achieving the organizationrsquos objectives via the designatedroute

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 137: STQA

(3) Involvement of people People are the essence of an organization their full involvement at all levels of the organization enables their abilities to be applied for the organizationrsquos benefit

(4) Process approach A desired result is achieved more efficiently when activities and resources are managed as a process

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 138: STQA

(5) System approach to management Identifying understanding and managing

processes if viewed as a system contributes to the organizationrsquos effectiveness and efficiency

(6) Continual improvement overall performance should be high on the organizationrsquos agenda

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 139: STQA

(7) Factual approach to decision making Effective decisions are based on the analysis of information

(8) Mutually supportive supplier relationships An organization and its suppliers are interdependent a mutually supportive relationship enhances the ability of both to create added value

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 140: STQA

In the late 1990s a new developmental direction was taken ndash development of integrated CMM models Development of specialized CMM models involved development of different sets of key processes for model variants for different departments that exhibited joint processes In practice this created a situationwhere departments that applied different CMM variants in the same organization faced difficulties in cooperation and coordination

Capability Maturity Model Integration (CMMI)

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 141: STQA

The CMMI structure and processes areas The CMMI model like the original CMM models is composed

of five levels The CMMI capability levels are the same as those of the

original apart from a minor change related to capability level 4 namely

Capability maturity level 1 Initial Capability maturity level 2 Managed Capability maturity level 3 Defined Capability maturity level 4 Quantitatively managed Capability maturity level 5 Optimizing

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 142: STQA

Bootstrap Methodology

The Bootstrap methodology measures the maturity of an organization and its projects on the basis of 31 quality attributes grouped into three classes process organization and technology A five-grade scale is applied to each of the quality attributes separately The methodology facilitates detailed assessment of the software development process by evaluating its achievements with respect to each attribute and indicates the improvements required in the software

development process and in projects

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 143: STQA

IEEEEIA std 12207

IEEEEIA Std 12207 provides a framework that incorporates the entire spectrum of software life cycle processes In this capacity it refers the reader to other IEEE standards as sources for specialized details and prescriptive requirements

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 144: STQA

The purposes of IEEEEIA Std 12207 as determined by the IEEE and EIA can be summarized thus

To establish an internationally recognized model of common software life cycle processes that can be referenced by the software industry worldwide

To promote understanding among business parties by application of commonly recognized processes activities and tasks

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 145: STQA

The IEEE Std 1012-1998 (IEEE 1998) deals with the processes for determining whether a software product conforms to its requirements specifications (verification) and whether it satisfies the objectives of its intended use (validation) The standard adopts a broad range of applications as demanded by the variety of verification and validation (VampV) methods available for use throughout the software life cycle In response to developments in the field the current standard has been substantially expanded from the 1986 version

IEEE Std 1012 ndash verification and validation

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 146: STQA

Project management responsibilities for quality

assurance Most project management responsibilities are defined in procedures and work instructions the project manager is the person in charge of making sure that all the team members comply with the said procedures and instructions

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction

Page 147: STQA

His tasks include professional hands-on and managerial tasks particularly the following

Professional hands-on tasks Preparation of project and quality plans and their updates Participation in joint customerndashsupplier committee Close follow-up of project team staffing including attending to recruitment training and instruction