STQA
-
Upload
akash-tyagi -
Category
Documents
-
view
57 -
download
0
description
Transcript of 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
(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
(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
(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
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
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
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
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
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
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
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
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