Lecture 1: Introduction to Software Quality Assurance

Transcription

1 Lecture 1: Introduction to Software Quality Assurance Software Quality Assurance (INSE 6260/4-UU) Winter 2009 Thanks to Rachida Dssouli for some slides Course Outline Software Quality Overview Software Quality Assurance Software Development Life Cycle Project 2 Course Outline Course Outline Instructor: Dr. J. Bentahar Course Web: Office: EV7.630 Lectures: Thursday, 17h45 20h15 Office Hours: Wednesday, 14h00 16h00 or by appointment Phone: ext bentahar@ciise.concordia.ca Lecture notes Assignment Useful links Useful information 3 4

2 INSE 6250/4-UU Software Quality Assurance: Software Quality (factors, models, life cycles, and standards) Quality assurance for quality models and specifications: inspection and testing Objectives: To discover and learn various concepts and techniques related to software quality assurance To learn to apply these techniques To develop critical thinking skills Software Systems Procurement 5 6 INSE 6260/4-UU Textbooks Software Quality Assurance 1) Software Quality Assurance: From Theory to Implementation, 2004 Factors and Models Software Quality Specification Language Inspection Quality Assurance Testing Techniques Reachability Analysis This book covers several issues related to software quality assurance. Some important chapters are: software quality challenge, what is software quality, software quality factors, and software testing 7 8

3 Textbooks Requirements and Grading 2) Metrics and Models in Software Quality Engineering, 2004 This book is a reference in software metrics. It covers a comprehensive breadth of measurement theory and software quality metrics One individual/group assignment 15% (Two parts: Technical part + Synthesis part) One in-class midterm exam (closed book) 25% One in-class final exam (closed book) 30% One team project (2~3 members, presentation + report) 15% + 15% = 30% 9 10 Important dates Project Project proposal Assignment Midterm exam Project presentation Final exam Project report February 05, 2009 February 12, 2009 March 053, 2009 April 02, 2009 TBS April 10, 2009 Project proposal Deadline: February 05, 2009 Team members Topic and title Abstract Main references 11 12

4 Questions Overview Please describe briefly about yourself: Course Outline Academic background Background in programming and software engineering Software Quality Software Quality Assurance Industrial experience Research domains you are interested in Software Development Life Cycle Definitions What is Software? Software Software quality IEEE definition, ISO 1997 sec and ISO/IEC SEC Software quality assurance Errors, faults, failures Cause of errors Software is: Computer programs (Code) Procedures Documentation Data necessary for operating the software system 15 16

5 Software Quality SQ Pressman s s Definition SQ- IEEE definition 1) 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 SQ is defined as Conformance to explicitly stated functional and performance requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software This definition suggests 3 requirements to be met by the developer: Specific functional requirements (output) The software quality standards mentioned in the contract Good Software Engineering Practices Developers Quality Problem Users software Intermediate Products Quality Decision maker client Request Benefits Decision maker provider Quality Policies and Quality System Expressed and implicit Requirements by the users Quality Policies Quality system Implements Product (quality) 19 20

6 Course Outline Software Quality Overview Software Quality Assurance Software Development Life Cycle Quality Software Assurance IEEE definition Quality assurance is 1. A planed and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements 2. A set of activities designed to evaluate the process by which the products are developed or manufactured Software Quality Assurance (cont.) SQA expanded definition A systematic, planed set of actions necessary to provide adequate confidence that the software development process or the maintenance process of the software system product conforms to established functional technical requirements as well as with the managerial requirements of keeping the schedule and operating within budgetary confines Quality Control versus SQA Quality Control (QC) is a set of activities carried out with the main objective of withholding products from shipment if they do not qualify Quality Assurance (QA) is meant to minimize the costs of quality by introducing a variety of activities throughout the development process and maintenance process in order to prevent the causes of errors, detect them, and correct them in the early stages of the development. As a result, quality assurance substantially reduces the rate of non-qualifying products 23 24

7 The Uniqueness of SQA Why do we care about Quality? High complexity Invisibility of software Nature of the product development Production process Need for SQA methodologies and tools Development cost Specification: 6% Design: 5% Coding: 7% V&V (Testing): 15% Maintenance: 67% Correction cost& source Req. & Specification: 56% Design: 24% Coding: 10% Other: 10% Relative Cost of Error Correction Distinction between Software Errors, Faults and Failures 1000 Software Error: section of the code that are incorrect as a result of grammatical, logical or other mistakes made by a system analyst, a programmer, or another member of the software development team Software Fault are software errors that causes the incorrect functioning of the software during a specific application 1 Rqmts Design Code Dev Test Sys Test Operation Software Failure: software faults become software failures only when they are activated 27 28

8 Causes of Software Errors Cost of quality Faulty requirements Client- developer communication failures Deliberate deviations from software requirements Logical design errors Coding errors Non compliance with documentation and coding instructions Shortcoming of the testing process Procedure errors Documentation errors Cost of Quality Cost of quality --> includes all costs incurred in the pursuit of quality or perform quality related work Quality cost includes: - prevention cost: - quality planning - formal technical reviews - testing equipment - training - appraisal cost: - in-process and inter-process inspection - equipment calibration and maintenance - testing - failure cost: internal failure cost: - rework, repair, and failure mode analysis external failure cost: - complaint resolution - product return and replacement - help line support - warranty work Product view: functionality, correctness, performance, usability... this is what we usually mean by quality Process view: efficiency, cost & schedule, failures (rework), reuse, learning, work satisfaction,... this is what process management is concerned about Views of Quality Business view: fitness for purpose, timeliness, customer satisfaction does it sell? producing the right product at the right time for the right price? this is usually the ultimate basis of decision 31 32

9 Quality Concepts Software quality assurance is an umbrella activity that is applied throughout the software process SQA encompasses: (1) a quality management approach (2) effective software engineering technology (3) formal technical reviews (4) a multi-tiered testing strategy (5) document change control (6) software development standard and its control procedure (7) measurement and reporting mechanism Quality Concepts Two types of quality control: Quality design -> the characteristics that designers specify for an item includes: requirements, specifications, and the system design Quality of conformance -> the degree to which the design specifications are followed It focuses on implementation based on the design Quality refers to measurable characteristics of a software Software Quality Assurance (SQA) SQA Activities SQA is a collection of activities during software development that focus on increasing the quality of the software being produced SQA includes Analysis, design, coding and testing methods and tools Formal technical reviews during software development A multi-tiered testing strategy Control of software documentation and the changes made to it Procedures to ensure compliance with software development standards Software measurement and reporting mechanisms SQA is often conducted by an independent group in the organization. Often this group has the final veto over the release of a software product 1. Application of Technical Methods Tools to aid in the production of a high quality specification i.e. specification checkers and verifiers Tools to aid in the production of high-quality designs i.e. design browsers, checkers, cross-references, verifiers Tools to analyze source code for quality 2. Formal Technical Reviews Group analysis of a specification or design to discover errors 3. Software Testing 4. Enforcement of Standards Specification and design standards Implementation standards, e.g. portability Documentation standards Testing standards 35 36

10 SQA Activities 5. Control of Change Formal management of changes to the software and documentation Changes require formal request to approving authority Approving authority makes decision on which changes get implemented and when Programmers are not permitted to make unapproved changes to the software Opportunity to evaluate the impact and cost of changes before committing resources Evaluate effect of proposed changes on software quality 6. Measurement Ongoing assessment of software quality Track quality changes as system evolves Warn management if software quality appears to be degrading 7. Record Keeping and Reporting SQA Activities Collect output and reports of SQA activities Disseminate reports to software managers Maintain archive of SQA reports Maintain log of software development activity (especially testing) to satisfy legal requirements Maintain institutional memory of the software development effort SQA Group People involved in quality assurance activities: Software engineers, project managers, customers, sale people, SQA group Activities: - apply technical methods and measures - conduct formal technical review - perform well-planned software testing The SQA group s role -> serves as the customer s in-house representative assist the software engineering team in achieving high-quality The SQA group s responsibility: - quality assurance planning oversight, record keeping, analysis and reporting The SQA group s tasks: - Prepare a SQA plan for a project - Participate in the development of the project s software process description - Review engineering activities to verify compliance with the defined process - Ensure the deviations in software work and products according to a documented procedure - Records any noncompliance and reports to senior management What experts say about Quality? Two dominant views on software quality: 1. Conformance and degree of satisfaction to defined specification. 2. The products or services capability to meet customer expectations explicitly or implicitly stated. Experts: Philip B. Crosby Edwards Deming Armand V. Feigenbaum Joseph M. Juran Walter A. Shewhart Kaoru Ishikawa 39 40

11 Philip B. Crosby W. Edwards Deming Quality is a subjectively identified notion by each individual and institution As this is not useful in software engineering, quality must be defined as conformance to Translating future needs of the user into measurable characteristics requirements Nonconformance to requirements is the Constantly changing based on real world competitors, solutions, technology, and price absence of quality, quality problems become nonconformance problems, and quality becomes definable Armand V. Feigenbaum Kaoru Ishikawa Quality is based upon the customer s actual experience with the product or service, measured against his or her requirements stated or unstated conscious or merely sensed technically operational entirely subjective always representing a moving target Quality defined according to standards (ISO, IEEE etc.) contain shortcomings, does not reflect constantly changing customer needs Narrowly interpreted, quality means quality of products Broadly interpreted, quality means quality of product, service, information, processes, people, systems etc. Quality must be defined comprehensively and dynamically 43 44

12 Joseph M. Juran Walter A. Shewhart Quality can be: Those product features which meet the need of customers and thereby provide product satisfaction Freedom from deficiencies Quality in terms of satisfying customer expectations or specifications is not usable as it is very hard to achieve Quality from two perspectives: An objective reality independent of the existence of the customer The subjective perspective dependent on individual thoughts, feelings or senses as a result of the objective reality Quality is fitness for use Overview Some Software Development Life Cycles Course Outline Software Quality Software Quality Assurance SDLC model (~waterfall) Prototyping Model Spiral Model Advanced Spiral Model Software Development Life Cycle Evolutionary Models Transformation Model Object Oriented Model 47 48

13 Structured Development Instantiation of Standard Process Specification Project Management Specification Project Management Design Design Coding Configuration Management Coding Verification & Validation Test Document Management Verification & Validation Reuse & Training, Testing Process Improvement Requirements definition Analysis SDLC Models Specification Project Management Design Design Metrics Coding Configuration Management Coding System Tests Document Management Verification & Validation Reuse, Training,... Testing Installation and Conversion Operation and Maintenance 51 52

14 Req. determination By the costumer The Prototyping Model Prototype Design Prototype implementation Prototype Evaluation By customer Req. fulfilled? Yes System Tests & Acceptance tests No System Conversion Demands for Corrections, Changes and additions System Operation and maintenance Spiral Model An iterative process, at each iteration, the following activities are performed: Planning Risk analysis and resolution Engineering activities according to the stage of the project: design, coding, testing, installation and release Customer evaluation, including comments, changes and additional requirements, etc Planning Determine objectives, alternatives, constraints Evaluation by the customer IV. Spirale Cycle I. Risk analysis II. review Requirements Plan, life cycle plan Development plan etc Concept of Operation Validation of requirements Coding Operational Prototype Simulation, models, benchmarks Detailed design Engineering III. 55 The Advanced Spiral Model The advanced Spiral model add extra emphasis on communication and negotiation between the customer and the developer It contains six activities that are carried out in each iteration Customer s specification of requirements, comments and change demands Developer s planning activities Developer s risk analysis and resolution Developer s Design activities Developer s construction activities pertaining to coding, testing, installation and release Customer s evaluation 56

15 Evolutionary Models Transformation Model Many variants available Product development evolves through increments evolutionary prototype Evolutionary process model (B. Boehm, 1988) "model whose stages consist of expanding increments of an operational software product, with the direction of evolution being determined by operational experience" Guided by formal methods Specifications transformed into implementations via transformations Still a theoretical reference model Transformation Model Decisions & rationale Reusable components Not accepted Requirements definition Object-oriented analysis Object oriented design Reusability survey Of components lib. The object Oriented Model Reusable Components library Addition to Lib. Requirements Requirements analysis and specification Verification Formal specifications Optimization Tuning Lower level specifications Customer s needs accepted Component is not available Availability Of comp. in Lib.? Reusable component Is available System construction Req. definition Analysis and Design Coding Component tests Recording of developmental history Installation And conversion Operation and maintenance System tests Development of a new component 59 60

16 References Chap 1, 2, 3 &4 of Software Quality Assurance Daniel Galin 61