Software Quality Assurance


Presentation Description

It is the technique from which we can measure the quality of any software. The software should meets its specified standards during its development cycle.


By: sev1111111 (60 month(s) ago)

good 1 !! :)... thnx a lot....

By: menyeng (62 month(s) ago)

thank you. i used this document for my task

By: lebasham57 (62 month(s) ago)

I would like a copy of the presentation. I am a QA Manager and it would like to use it as an overview for new staff, peers, etc...thanks!

By: rizrose1 (63 month(s) ago)

i need the slides for my lecturing since it is nicely compiled..kindly send it to rizrose1@yahoo,com

See all

Presentation Transcript

Slide 1: 



SOFTWARE QUALITY ASSURANCE OUTLINE Quality Assurance An Umbrella Activity – Software Metrics Software Standards Product Quality Design Quality Metrics – Formal Approaches Program Quality Metrics Project Quality Reviews Software Configuration Management Process Quality ISO 9001/9000-3 The SEI Capability Maturity Model People Quality The People Capability Maturity Model 10, 12


THE FOUR P’s IN SOFTWARE DEVELOPMENT Product Project People template participate result software engineers set of artifacts set of activities Process education & training management & monitoring testing & measurement How can we achieve software quality? measurement & feedback


SOFTWARE QUALITY ASSURANCE (SQA) Quality assurance consists of those procedures, techniques, and tools applied by professionals to ensure that a product meets or exceeds pre-specified standards during it’s development cycle. E.H. Bersoff It is an essential activity for any business thatproduces products used by others. It needs to be planned and systematic.(It does not just happen) It needs to be built into the development process.(A natural outcome of software engineering) Continuous improvement is the overall goal.


SQA — AN UMBRELLA ACTIVITY Quality Standards and Procedures Metrics and Measurement Software Configuration Management Testing Formal Technical Reviews Methods and Tools


SQA — AN UMBRELLA ACTIVITY Includes all techniques used to improve the quality of the software: 1. methods and tools for System Requirements Capture, System Analysis, System Design, Implementation and Testing to help ensure that we achieve a high quality system 2. standards and procedures compliance to help ensure repeatability of the development process 3. metrics and measurement procedures to help us improve the software development process 4. formal technical reviews at each step to help uncover quality problems and to sign-off 5. software configuration management and change control to help ensure changes are managed and controlled 6. multi-tiered testing to help ensure effective error detection


WHY SQA ACTIVITIES PAY OFF cost to find and fix a defect log scale


SOFTWARE QUALITY What is software quality and how do we measure it? customer’s viewpoint ® meets specifications developer’s viewpoint ® easy to maintain, test, . . . Other attributes of software that affect its quality: safety – understandability – portability security – testability – usability reliability – adaptability – reusability resilience – modularity – efficiency robustness – complexity – learnability Software quality is not just about meetingspecifications and removing defects! We need to select critical quality attributes early in the development process and plan for how to achieve them.


PRINCIPLES OF SOFTWARE QUALITY ASSURANCE 1. We have a set of standards and quality attributes that a software product must meet. There is a goal to achieve. 2. We can measure the quality of a software product. There is a way to determine how well the productconforms to the standards and the quality attributes. 3. We track the values of the quality attributes. It is possible to assess how well we are doing. 4. We use information about software quality to improve the quality of future software products. There is feedback into the software development process.


1. encapsulate best (or most appropriate) practices acquired after much trial and error ® helps avoid previous mistakes 2. provide a framework around which to implement SQA process ensures that best practices are properly followed 3. assist in ensuring continuity of project work reduces learning effort when starting new work product standards: define the characteristics all product artifacts should exhibit so as to have quality process standards: define how the software process should be conducted to ensure quality software SOFTWARE STANDARDS Why are software standards important? Standards Handbook needed! Each project needs to decide which standards should be: ignored; used as is; modified; created.


SOFTWARE METRICS metric: any type of measurement that relates to a software system, process or related artifact control metrics - used to plan, manage and control the development process (e.g., effort expended, elapsed time, disk usage, etc.) predictor metrics - used to predict an associated product quality (e.g., cyclomatic complexity can predict ease of maintenance) external attribute: something we can only discover after the software has been put into use (e.g.,ease of maintenance) internal attribute: something we can measure directly from the software itself (e.g., cyclomatic complexity)


SOFTWARE METRICS (cont’d) We want to use internal attributes to predict the value of external attributes. Problems: 1. hard to formulate and validate relationships between internal and external attributes 2. software metrics must be collected, calibrated, interpreted external maintainability reliability portability usability internal # of parameters cyclomatic complexity lines of code # of error messages length of user manual


PRODUCT QUALITY: DESIGN QUALITY METRICS For a design component, the key quality attribute is maintainability. For design components maintainability is related to: cohesion - how closely related is the functionality of the component? coupling - how independent is the component? understandability - how easy is it to understand what the component does? adaptability - how easy is it to change the component? Problem: most of these cannot be measured directly, but it is reasonable to infer that there is a relationship between these attributes and the “complexity” of a component measure complexity How?


PRODUCT QUALITY: DESIGN QUALITY METRICS a) Structural fan-in/fan-out fan-in – number of calls to a component by other components fan-out – number of components called by a component high fan-in => high coupling high fan-out => calling component has high complexity b) Informational fan-in/fan-out consider also the number of parameters passed plus access to shared data structures complexity = component-length x (fan-in x fan-out)2 It has been validated using the Unix system It is a useful predictor of effort required for implementation


PRODUCT QUALITY: DESIGN QUALITY METRICS c) IEEE Standard 982.1-1988 looks at: subsystem properties (number of subsystems and degree of coupling) database properties (number of attributes and classes) compute a design structure quality index—DSQI ® (0-1) used to compare with past designs; if DSQI is too low,further design work and review may be required we can also consider changes made throughout the lifetime of the software and compute how stable the product is (i.e., how many changes have been made in subsystems in the current release) define a software maturity index—SMI ® (0-1) as SMI approaches 1, the product begins to stabilize

IEEE STANDARD 982.1-1988 : 

IEEE STANDARD 982.1-1988 S1 = the total number of subsystems defined in the program architecture S2 = the number of subsystems whose correct function depends on the source of data input or that produces data to be used elsewhere S3 = the number of subsystems whose correct function depends on prior processing S4 = the number of database items (includes data objects and all attributes that define objects) S5 = the total number of unique database items S6 = the number of database segments (different records or individual objects S7 = the number of subsystems with a single entry and exit This slide is for information only – you are not required to know this!

IEEE STANDARD 982.1-1988 : 

IEEE STANDARD 982.1-1988 Program structure:D1 = 1 if the architecture was developed using a distinct methodD1 = 0 otherwise Subsystem independence: D2 = 1 - (S2/S1) Subsystems not dependent on prior processing: D3 = 1 - (S3/S1) Database size: D4 = 1 - (S5/S4) Database compartmentalization: D5 = 1 - (S6/S4) Subsystem entrance/exit characteristic: D6 = 1 - (S7/S1) DSQI = wiDi wi = relative weighting of each Di This slide is for information only – you are not required to know this!

IEEE STANDARD 982.1-1988 : 

IEEE STANDARD 982.1-1988 SMI = [MT - (Fa + Fc + Fd)]MT MT = the number of subsystems in the current release Fc = the number of subsystems in the current release that have been changed Fa = the number of subsystems in the current release that have been added Fd = the number of subsystems in the preceding release that were deleted in the current release This slide is for information only – you are not required to know this!


PRODUCT QUALITY: PROGRAM QUALITY METRICS a) Halstead’s Software Science Looks at operators and operands in an implementation component and calculates values for component volume, V, component difficulty, D, and effort, E, required to implement the component. n1 = number of unique operators in a component n2 = number of unique operands in a component N1 = the total number of operators N2 = the total number of operands L = N1+ N2 (component length) V = L * log2(n1 + n2) (component volume in bits) D = (n1/2) * (N2/n2) (difficulty of implementing the component) E = V * D (effort required to implement the component) For an implementation component, the key quality attributes are reliability and difficulty of implementation.


PRODUCT QUALITY: PROGRAM QUALITY METRICS b) McCabe’s Complexity Metric Looks at control flow in a component. Cyclomatic Complexity ® measures component’s logical complexity an indication of the testing difficulty of a component Studies have shown a distinct relationship between the Cyclomatic Complexity of a component and the number of errors found in the source code, as well as the time required to find and fix errors. c) Other program quality metrics length of code – length of identifiers depth of conditional nesting Standards can be established to avoid complex components and/or highlight problem components.


PRODUCT QUALITY: FORMAL APPROACHES a) Proving programs/specifications correct logically prove that requirements have been correctly transformed into programs (e.g., prove assertions about programs) b) Statistical Quality Assurance categorize and determine cause of software defects 80-20 rule  80% of defects can be traced to 20% of causes isolate and correct 20% of the causes effort directed to things that cause the majority of defects c) The Cleanroom Process combination of above two approaches


PROJECT QUALITY: REVIEWS Requirements capture Analysis Design Implementation Testing requirements walkthroughs analysis walkthroughs design walkthroughs code walkthroughs test plan review Leads to early discovery of defects Requirements, Analysis and Design introduce 50-60% of all defects. Formal technical reviews can uncover 75% of these! The principal method of validating the quality of a project.


SOFTWARE CONFIGURATION MANAGEMENT (SCM) An activity executed throughout the system life cycle to control change of products and life cycle artifacts. audit control report identify support To what do we want to control changes? configuration item: an artifact to which we want to control changes 10.2 Software Configuration Management • plans • programs • specifications • documents/manuals • procedures • data


CONFIGURATION ITEM IDENTIFCATION AND DESCRIPTION each configuration item must be identified and described a unique name configuration item type project identifier change and/or version information resources the configuration item provides or requires pointer to actual configuration item the configuration items also must be organized (i.e., need to define the relationships that exist between configuration items) object diagram <part-of> domain model domain model <related-to> use-case model This is metadata about configuration items Define and construct a software library (database) that stores, manages and tracks configuration items. 10.3.1


CONTROLLING CONFIGURATION ITEMS: BASELINES A baseline is a time/phase in the software development (usually a project milestone) after which any changes must be formalized (e.g., go through a formal change control procedure). 10.3.2 In order to become a baseline, the configuration item must first pass a set of formal review procedures (e.g., formal code review, documentation review, etc.). It then becomes part of the project software library. After this a “check-out” procedure is applied to the item(i.e., access to and change of the configuration item is controlled) Any modified configuration item must again go through a formal review process before it can replace the original (baselined) item.


SCM BASELINES Requirements gathering Analysis Design Implementation Testing Requirements Specification Analysis Specification Design Specification Source code, manuals Test Plans/Procedures/Data Operational System


CONTROLLING CONFIGURATION ITEMS:VERSION CONTROL a configuration item usually evolves throughout the software engineering process (i.e., it will have several versions) An evolution graph can be used to describe aconfiguration item’s change history version configuration itemk is obtained by modifying configuration itemi usually a result of bug fixes, enhanced system functionality, etc. itemk supercedes original itemi; created in a linear order branch a concurrent development path requiring independent configuration management variant different configurations that are intended to coexist e.g., different configurations depending on operating system type Oracle for Windows Oracle for Linux


CONTROLLING CONFIGURATION ITEMS:VERSION CONTROL 1.0 2.0 2.1 2.2 3.0 2.0.1 2.0.2 branch line parallel development mainline development branch line


Uncontrolled change rapidly leads to chaos ! SCM CHANGE CONTROL STOP change request submitted byusers/developers change control authority evaluates,decides and issues an engineeringchange order if approved configuration item is checked-out,changed, checked-in after SQA,and version controlled configuration item made availablefor use (promotion; release)


SCM CHANGE CONTROL change request from user/developer change control authority evaluates and decides request is queued for action change request is denied assign individuals to configuration items user is informed “check-out” configuration items make changes review (audit) the change “check-in” the configuration items that have been changed establish a baseline for testing perform quality assurance and testing activities “promote” changes for inclusion in next release rebuild appropriate version of software review (audit) the change to all configuration items include changes in release distribute the release can be applied tointernal requests(i.e., user = developer)andexternal requests(i.e., user = end-user)


SCM AUDIT AND STATUS REPORTING Audit: ensures that changes have been properly implemented. Have the proper steps and procedures been followed? ® checklist Usually done by Quality Assurance (QA) group if SCM is a formal activity. Status reporting: keeps all parties informed and up-to-date on the status of a change. A communication mechanism among project members to help keep them coordinated. Can determine who made what changes, when and why.


SCM SUPPORT a software library provides facilities to store, label, identify versions and track the status of the configuration items software repository developer’s workspace master directory promotions releases everyday development used by a single developer used by other developers for users tracks tracks check-in; check-out after SQA 10.3.5


SCM BENEFITS reduces the effort required to manage and effect change improved productivity leads to better software integrity and security increased quality generates information about the process enhanced management control maintains a software development database better record keeping and tracking


PROCESS QUALITY unlike manufactured products, software development has some unique factors that affect its quality: software is designed, not manufactured software development is creative, not mechanical individual skills and experience have a significant influence external factors (application novelty, commercial pressure) software development processes are organization specific people, technology may be more important than process insufficient resources will always adversely affect quality

PROCESS QUALITY: ISO 9001/ 9000-3 : 

PROCESS QUALITY: ISO 9001/ 9000-3 certification is easy; can be a marketing ploy generic quality model customized for a particular organization Focus is on process management

ISO 9001/9000-3 STANDARD (1/3) : 

ISO 9001/9000-3 STANDARD (1/3) A. Quality system framework 1. Management responsibility quality policy defined, documented, understood, implemented and maintained responsibilities and authorities for all personnel defined in-house verification resources defined, trained and funded a designated manager ensures that the quality program is implemented and maintained 2. Quality system requires a documented quality system be established should be an integral process throughout the entire life cycle 3. Internal quality system audits requires audits be planned and performed results communicated to management deficiencies corrected 4. Corrective action requires causes of non-conforming product be identified potential causes of non-conformance eliminated procedures changed as a result This slide is for information only – you are not required to know this!

ISO 9001/9000-3 STANDARD (2/3) : 

ISO 9001/9000-3 STANDARD (2/3) B. Quality Life Cycle Activities 1. Contract review contracts are reviewed to determine whether the requirements are adequately defined, agree with the bid, and can be implemented 2. Purchaser’s requirements specification procedures to identify and collect purchaser’s requirements 3. Development planning production processes are defined and planned 4. Quality record quality assurance process is planned 5. Design and implementation procedures to control and verify the design includes planning design activities, identifying inputs and outputs, verifying the design and controlling design changes 6. Testing and validation requires systems/products to be tested and validated before use records of testing are kept 7. Acceptance procedures for acceptance should be established 8. Replication, delivery and installation procedures for the above should be established and maintained 9. Maintenance requires that maintenance activities be performed as specified This slide is for information only – you are not required to know this!

ISO 9001/9000-3 STANDARD (3/3) : 

ISO 9001/9000-3 STANDARD (3/3) C. Quality System Supporting Activities 6. Tools and Techniques are applied appropriately to support the development process 7. Purchasing purchased products conform to their specified requirements 8. Included software product should be verified and maintained 9. Training training needs should be identified and training provided since related tasks may require qualified personnel training records should be maintained 1. Configuration management process of development and maintenance should be documented and controlled 2. Document control distribution and modification of documents should be controlled 3. Quality records quality records should be collected, maintained and dispositioned 4. Measurement where appropriate, adequate statistical techniques should be identified and used to verify the acceptability of process capability and product characteristics 5. Rules, practices and conventions are in place and followed This slide is for information only – you are not required to know this!


PROCESS QUALITY:THE SEI CAPABILITY MATURITY MODEL (CMM) Intended to help a software organizationimprove their software development processes. Level 1 Organization: Initial process (ad hoc) no formal procedures, no cost estimates, no project plans,no management mechanism to ensure procedures are followed Level 2 Organization: Repeatable process (intuitive) basic project controls; intuitive methods used Level 3 Organization: Defined process (qualitative) development process defined and institutionalized Level 4 Organization: Managed process (quantitative) measured process; process database established Level 5 Organization: Optimizing process improvement feedback; rigorous defect-cause analysis and prevention Focus is on process improvement 12.3


CAPABILITY MATURITY MODEL (CMM) Key Processes in Place Level 1: Initial process Level 2: Repeatable process Requirements Management Software Project Planning Software Project Tracking & Oversight Software Subcontract Management Software Quality Assurance Software Configuration Management Level 3: Defined process Organization Process Focus Organization Process Definition Training Program Integrated Software Management Software Product Engineering Intergroup Coordination Peer Reviews Level 4: Managed process Quantitative Process Management Software Quality Management Level 5: Optimizing process Fault Prevention Technology Change Management Process Change Management This slide is for information only – you are not required to know this!


PROCESS QUALITY — NOTES It is possible for a Level 1 organization to receive ISO 9000 certification! A Level 3 organization would have little difficulty in obtaining ISO 9000 certification. A Level 2 organization would have significant advantage in obtaining ISO 9000 certification. excellent software developers (e.g., space shuttle) attain around level 3-4 only


PEOPLE QUALITY:PEOPLE CAPABILITY MATURITY MODEL (PCMM) Intended to improve knowledge and skill of people. Level 1 – Initial no technical or management training provided;staff talent not a critical resource; no organizational loyalty Level 2 – Repeatable focus on developing basic work practices; staff recruiting, growth and development important; training to fill skill “gaps”; performance evaluated Level 3 – Defined focus on tailoring work practices to organization’s business; strategic plan to locate and develop required talent; skills-based compensation Level 4 – Managed focus on increasing competence in critical skills; mentoring; team-building; quantitative competence goals; evaluation of effectiveness of work practices Level 5 – Optimizing focus on improving team and individual skills; use of best practices Focus is on people improvement


SQA — THE BOTTOM LINE an organization should have a quality manual which documents its quality assurance procedures each project should have a quality plan which sets out the quality attributes that are most important for that project and how they will be assessed an organization should have established standards for documentation mechanisms (processes) should be established that monitor compliance with all quality requirements of the organization reviews are the primary means of carrying out quality assurance metrics can be used to highlight anomalous parts of the software which may have quality problems


SUMMARY — SOFTWARE QUALITY Quality software does not just happen! Quality assurance mechanisms should be built into the software development process Developing quality software requires: Management support and involvement Gathering and use of software metrics Policies and procedures that everyone follows Commitment to following the policies and procedures even when things get rough! Testing is an important part of quality assurance, but its not all there is to obtaining a quality software product.

authorStream Live Help