OHT 1.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 The uniqueness of software quality assurance The environments for which SQA methods are developed (significantly modified by R. Roggio, Fall 2011)

OHT 1.2 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Introduction Why Quality Assurance? With all the methodology wars, numerous processes, huge number of tools to assist in software development, why this separate topic? What makes it important that it deserves separate treatment? Why do so many companies add disclaimers to their software? –Don’t warranty the documentation… –Not responsible for direct, indirect, consequential, loss?

OHT 1.3 Galin, SQA from theory to implementation © Pearson Education Limited 2004 What we are after; that is, we want to be able to: 1. Identify the unique characteristics of software as a product and as process that justify separate treatment of its quality issues. 2. Recognize the characteristics of the software environment where professional software develepment and maintenance take place

OHT 1.4 Galin, SQA from theory to implementation © Pearson Education Limited 2004 High complexity –The potential ways in which a software product can be used with different data / data paths reflecting different incoming data is almost infinite. –Manner in which industrial products can be used are usually well-defined. –Think about software: every loop with different values of data reflects a different opportunity to see software fail.

OHT 1.5 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Invisibility of the product –In an industrial product, missing parts are obvious. Something missing? Easily identified. –Not so in software products. May not be noticeable for years – if at all! Cite: phantom paths product at AFDSDC!

OHT 1.6 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Opportunities to detect defects (“bugs”)?? Consider: –Product Development –Product Planning –Product Manufacturing –

OHT 1.7 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Product Development: –Industrial: test product; voltages; performance; strength; size; ….ready to distribute to markets –Computer Software: once prototype and system testing are concluded, product is ready for deployment About the same approach Arguable: equal chance to discover defects? –What do YOU think??

OHT 1.8 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Product Production Planning: –Industrial: Often need new tooling approaches, assembly lines, new manufacturing processes. Results in additional ‘looks’ at products One could say that there is a better chance to discover defects –Computer Software: No real additional ‘look-see.’ Packages shrink-wrapped, printed, distributed to public No real chance to discover additional defects.

OHT 1.9 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Product Manufacturing: –Industrial: Usually defects uncovered here; easily fixed. Typical burn-in problems; another view of product; stabilizes. These represent additional opportunities to discover defects. –Computer Software: We merely copyright, print copies of software and manuals No real chance for additional quality views No real chance for discovering additional defects

OHT 1.10 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Only Chance to Discover Defects: Best chance to really detect defects occurs during the software development process itself! “The need for special tools and methods for the software industry is reflected in the professional publications as well in special standards devoted to SQA, such as ISO , “Guidelines for the application of ISO 9001 to the development, supply, and maintenance of software.” Another: ISO : “Quality Management and Quality Systems Elements: Guidelines for the Services.” These characteristics of software – complexity, invisibility, and limited opportunity to detect bugs has led to the development of the ISO Guidelines and an awareness of real SQA methodology.

OHT 1.11 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Important to note that quality issues seem to center around software development professional activities undertaken by development and maintenance organizations vice an individual. Quality issues govern professional software development. This is our focus: large scale development rather than individual application development Here are some of our main environmental issues:

OHT 1.12 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Being contracted Subjection to customer-supplier relationship Requirement for teamwork Need for cooperation and coordination with other development teams Need for interfaces with other software systems Need to continue carrying out a project while the team changes Need to continue maintaining the software system for years

OHT 1.13 Galin, SQA from theory to implementation © Pearson Education Limited 2004 SQA Environment Being Contracted: –Professional software development is almost always contracted. Have requirements / supplied requirements (hopefully) –But may have in-house customer representatives. –Or, customer representatives available… Budget Time schedule

OHT 1.14 Galin, SQA from theory to implementation © Pearson Education Limited 2004 SQA Environment Subject to Customer-Supplier Relationship –In professional software development, there is a constant (hopefully) oversight between customer and developer. Changes will occur; Criticisms will arise. Cooperation is critical to overall project success. –Customer availability / relationship is essential and often problematic whether reps are in-house or not.

OHT 1.15 Galin, SQA from theory to implementation © Pearson Education Limited 2004 SQA Environment Required Teamwork –We need teams due to Time required for development. –Workload is too much for a single person A frequent variety of experts needed –Database; networking; algorithms; … Need ‘independent’ reviews to ensure quality (me) –Who is ‘on the team?’ Developers Clients / customers Others???

OHT 1.16 Galin, SQA from theory to implementation © Pearson Education Limited 2004 SQA Environment Cooperation and Coordination with Other Software Teams –May be partially outsourced thus requiring cooperation Outsourced  overseas? Many potential problems here … and benefits. –Laision? –May be that specialized hardware requires cooperation. –Other teams may have developed similar software for the client and can offer tremendous help.

OHT 1.17 Galin, SQA from theory to implementation © Pearson Education Limited 2004

OHT 1.18 Galin, SQA from theory to implementation © Pearson Education Limited 2004 SQA Environment Interfaces with Other Systems –Interface, link to, import, include other packages containing, say, libraries of perhaps classes / packages to assist in development. –Standardization considerations in interfaces –May need to cooperate with inputs coming from other systems and outputs requiring special formats that serve as inputs to other systems… –Do you think Billing, Payroll, Accounts Payable are all distinct systems???

OHT 1.19 Galin, SQA from theory to implementation © Pearson Education Limited 2004

OHT 1.20 Galin, SQA from theory to implementation © Pearson Education Limited 2004 SQA Environment Need to Continue Project despite Team Changes –Team members leave, are hired, fired, take unexpected vacations, transferred within the company, and more. –Maddening truism, but the development must continue. –You can count on disruption!

OHT 1.21 Galin, SQA from theory to implementation © Pearson Education Limited 2004 SQA Environment Need to continue Software Maintenance for an Extended Period –Whether external customers or in-house customers, follow-on maintenance is typical and for many years!! –Highly desirable from management/enterprise perspective SQA must address development, operations, and maintenance! (next chapter)