Lecture Notes 2 Software Quality Assuran PDF

Preview

Summary

Lecture notes about testing of software and its importance in application usage...

Description

Software Development LECTURE NOTES 2

Software Quality Assurance

: Software Quality Assurance

Objectives: At the end of this chapter, the students should be able to: 1. Differentiate quality control from quality assurance 2. Explain the different SQA activities 3. Estimate the quality of the software based on software quality metrics Software Quality Assurance (SQA) An umbrella activity that is applied throughout the software engineering process. It is an error-prevention technique that focuses on the process of systems and software development. It is a planned and systematic pattern of actions that are required to ensure quality in software. SQA encompasses: 1. 2. 3. 4. 5. 6.

analysis, design, coding and testing methods and tools formal technical reviews that are applied during each software engineering step a multi tiered testing strategy control of software documentation and the changes made to it a procedure to assure compliance with software development standards measurement and reporting mechanism

SQA is often thought of as a software testing activity - WRONG If quality isn’t part of a product prior to testing, it won’t be part of the product after testing is completed. SQA must be part of Software Engineering from the beginning The goals of SQA 1. to improve software quality by monitoring both the process and the product 2. to ensure compliance with all local standards for SE 3. to ensure that any product defect, process variance, or standards noncompliance is noted and fixed Scenario You are hired to manage the software engineering of a new product estimated at 25,000 lines of code, involving three or four people working for about 18 months Consider the following: 1. What should be in place before the project starts? 2. What quality checkpoints should you have? 3. What measures will you collect to determine the level of quality of the work being performed? SQA: a dose of reality Elmerito D. Pineda, MBA-IS, DIT(cand)

Page No. 1/11

Software Development

1. 2. 3. 4.

Software Quality Assurance

SQA cannot put quality into a product the existence of an SQA function is no guarantee that quality will exist if management doesn’t act on SQA, the function will be ineffective unless SQA and development staff work together, little benefit will be derived

Quality Control Vs. Quality Assurance  Quality control is about work product, quality assurance is about work process. 

Quality control activities are work product oriented. They measure the product, identify deficiencies, and suggest improvements. The direct result of these activities are changes to the product. These can range from single-line code changes to completely reworking a product. It is an error-removal technique.



Quality assurance activities are work process oriented. They measure the process, identify deficiencies, and suggest improvements. The direct result of these activities are changes to the process. These changes can range from better compliance with the process to entirely new processes. The output of quality control activities is often the input to quality assurance activities.

Software Quality Conformance to explicitly stated functional and performance requirements, explicitly documented development standards and implicit characteristics that are expected of all professionally develop software. An alternative definition by W. Edwards Deming Striving for excellence in reliability and functions by continuous (process) improvement, supported by statistical analysis of the causes of failure Three (3) important points to remember on software quality 1. Software requirements are the foundation from which quality is measured. Lack of conformance to requirements is lack of quality. 2. Specified standards define a set of development criteria that guide the manner in which software is engineered. If the criteria are not followed, lack of quality will almost surely result. 3. There is a set of implicit requirements that often goes unmentioned (e.g., the desire for good maintainability). If software conforms to its explicit requirements, but fails to meet implicit requirements. Quality Characteristics

Elmerito D. Pineda, MBA-IS, DIT(cand)

Page No. 2/11

Software Development

Software Quality Assurance

Is any property or element that can be used to define the nature of a product. Each characteristic can be physical or chemical properties such as size, weight, volume, color or composition. Software Quality 1. Is achieved through a disciplined approach - called software engineering SE 2. Can be defined, described, and measured 3. Can be assessed before any code has been written 4. Cannot be tested into a product Software quality challenges 1. Defining it 2. Describing it (qualitatively) 3. Measuring it (quantitatively) 4. Achieving it (technically) Designing software is a creative task, and like most such tasks, success is more likely if the designer follows what might be termed a set of rules of form. The rules of form also provide some way of assessing the quality of the eventual product, and possibly of the processes that led to it. Quality example Music provides a good analogy: we could write music by scattering notes around at random, but we would get a better result if we considered melody and harmony Awful

Bearable

Good

My music

Extremely good

Beethoven’s music How do we scale this?

In his book Quality Is Free, Philip Crosby suggests an analogy between quality and sex: 1. Everyone is for it, except in certain situations; Elmerito D. Pineda, MBA-IS, DIT(cand)

Page No. 3/11

Software Development

Software Quality Assurance

2. Everyone believes they understand it, but they don’t want to explain it; 3. Most people believe the execution is merely a matter of following natural inclinations; 4. Everyone believes that problems with it are always someone else’s fault REALISING QUALITY A set of abstract quality factors (‘the ilities’) has been defined. These cannot be measured directly but do relate to the ultimate goal.

mapped on to quality factors (ilities)

realised through quality criteria

measured by measurable quantity

counts from designs

Software Quality Factors (by McCall) 1) Product Revision (changing it)



Flexibility (can I change it?) The effort required to modify an operational program. Change and enhancement of the system should be easily implementable.



Maintainability (can I fix it?) The effort required to locate and fix an error in a program. The system should be easy to keep up for its intended use. Changes for improving operational efficiency should be easy to implement. Failed operations should be easy to restore to satisfactory condition.



Testability (can I test it?) The effort required to test a program to ensure that it performs its intended function . The ability of the system to produce quality product units should be easily testable. Useful messages should be generated for testing and debugging purposes.

2) Product Transition (modifying it to work in a different environment)



Interoperability (Will I be able to interface it with another system?) The effort required to couple one system to another.

Elmerito D. Pineda, MBA-IS, DIT(cand)

Page No. 4/11

Software Development

Software Quality Assurance



Portability (Will I be able to use it on another machine?) The effort required to transfer the program from one hardware and/or software system environment to another. The system should be portable among people and among machines. Attainment of the other quality characteristics greatly facilitates portability.



Reusability (Will I be able to reuse some of the software?) The extent to which a program (or part of a program) can be reused in other applications-related to the packaging and scope of the functions that the program performs.

3) Product Operations (using it) 

Correctness (Does it do what I want?) The extent to which a program satisfies its specification and fulfills the customer’s mission objectives. The extent to which software is free from design defects and from coding defects.; that is fault-free.



Reliability (Does it do it accurately all of the time?) The extent to which a program can be expected to perform its intended function with required precisions under stated conditions for a stated period of time.



Efficiency (Will it run on my hardware as well as it can?) The extent to which a software performs its function.with a minimum consumption of computing resources. It should not use any hardware components or peripheral equipment unnecessarily.



Integrity (Is it secure?) The extent to which access to software or data by unauthorized persons can be controlled.



Usability (Is it designed for the use?) The effort required to learn, operate, prepare input, and interpret output of a program.

Quality Metrics Provides an indication of how closely software conforms to implicit (essential) and explicit (specific) requirements. 

Auditability

Elmerito D. Pineda, MBA-IS, DIT(cand)

Page No. 5/11

Software Development

Software Quality Assurance

The ease with which conformance to standards can be checked. 

Accuracy The precision of computations and control. A qualitative assessment of freedom from error. A quantitative measure of the magnitude of error. The correct data values are recorded.



Communication commonality The degree to which standards interfaces, protocols, and bandwidths are used.



Completeness The degree to which full implementation of required function has been achieved. All data items are captured and stored for use. Data items are properly identified with time periods.



Conciseness The compactness of the program in terms of lines code.



Consistency The use of uniform design and documentation techniques throughout the software development project.



Data commonality The use of standard data structures and types throughout the program.



Error tolerance The damage that occurs when the programs encounters an error. Suitable error prevention and detection procedures are in place. There are procedures for reporting and correcting errors. Various audit procedures are applied.



Execution efficiency The run-time performance of a program.



Expandability The degree to which architectural, data, or procedural design can be extended.



Generality The breadth of potential application of program components.



Hardware independence

Elmerito D. Pineda, MBA-IS, DIT(cand)

Page No. 6/11

Software Development

Software Quality Assurance

The degree to which the software is decoupled from the hardware on which it operates.



Instrumentality The degree to which the program monitors its own operation and identifies errors that do occur.



Modularity The functional independence of program components.



Operability The ease of operation of a program.



Robustness The extent to which software can continue to operate correctly despite the introduction of invalid inputs



Security The availability of mechanism that control or protect programs and data. The system and its operations are protected from various environmental and operation risks. There are provisions for recovery in the event of failure or destruction of part or all system



Self-documentation The degree to which the source code provides meaningful documentation.



Simplicity The degree to which a program can be understood without difficulty.



Software system independence The degree to which the program is independent of nonstandard programming language features, operating system characteristics, and other environmental constraints.



Traceability The ability to trace a design representation or actual program component back to requirements.



Training The degree to which the software in enabling new users to apply the system.

Laws of software evolution dynamics (by Belady and Lehman):

Elmerito D. Pineda, MBA-IS, DIT(cand)

Page No. 7/11

Software Development

Software Quality Assurance

1. Law of continuing Change (self evident)- a large program that is being used undergoes continuing change until it is judged more cost-effective to rewrite it. Software over time must be changed not only to repair errors that are discovered, but also to incorporate enhancements to adapt to new hardware systems and changing environment. 1. Law of Increasing Entropy (intuitive)- the entropy (disarray) of a system increases with time unless specific work is done to maintain it or to reduce it. Continuous changes made to a system tend to destroy the integrity of the system thus increasing entropy. 1. Law of Statistically-Smooth Change (controversial) - Measures of a global system attributes and project attributes may appear quite irregular for a particular system, but are cynically self-regulating, with statistically identifiable invariance and well-defined long-range trends. Work input or the effort expended per unit time, remained constant over the lifetime of the system. SQA ACTIVITIES 1. Application of technical methods The use of technical tools and methods helps analyst to achieve high quality specification and the designer to develop a high quality design 1. Conduct of formal technical reviews (FTR) Reviews are another quality control activity. Again, reviews are held to find defects in a work product. The result is changes to the work product. Over time, the collection of these changes may induce process changes, but that is not necessary. a. To uncover errors in function., logic or implementation for any representation of the software b. To verify if software meet requirements c. To ensure that software has been presented according to pre-defined standards. d. To achieve software that is developed in a uniform manner e. Make projects more manageable. It is not the task of team to correct faults, but merely to record them for later correction. Defect found early in the software life cycle can be repaired at much less expense than later in the life cycle. Types of Reviews 1) Walk through - an interactive process to evoke questions and discussions time limit - 2 hours SQA , participants : 4 - 6, senior tech. staff

Elmerito D. Pineda, MBA-IS, DIT(cand)

Page No. 8/11

Software Development

Software Quality Assurance

Ways to conduct walk through: a) Participant - driven  each participant goes through his or her list of unclear items which may appear incorrect. b) document-driven  A person responsible for the document walks the participants through that document, with the reviewers in everything either with their prepared comments or comments triggered by the presentation 2) Inspection (goes far beyond walk through) Formal steps of inspection a) an overview of document is given to participants b) participants prepare for inspection, aided with lists of fault types previously found c) inspection - every piece of logic is covered at least once, and every branch is taken at least once. Written report is inspection is produce d) Rework - resolves all faults and problems noted in written report e) Follow-up ensure that every single issue raised has been satisfactorily resolved. Review Guidelines 1. 1. 1. 1. 1. 1. 1. 1. 1. 1.

Review the product, not the producer Set an agenda and maintain it. Limit debate and rebuttal Enunciate problem areas, but don’t attempt to solve every problem noted. Take written notes Limit the number of participants and insist upon advance preparation Develop a checklist for each product that is likely to be reviewed. Allocate resources and time schedule for FTRs Conduct meaningful training for all reviewers. Review your early reviews

3. Software testing Software testing is the activity or running software to find errors in the software. The direct output of testing results in product changes. A study of these changes may result in process changes, but this is not necessary. Thus, testing is a quality control activity. It combines a multi-step strategy with a series of test case design methods that help ensure effective error detection .Program testing can be very effective Elmerito D. Pineda, MBA-IS, DIT(cand)

Page No. 9/11

Software Development

Software Quality Assurance

way to show the presence of bugs but it is hopelessly inadequate for showing their absence [Dijkastra 1972] 4. Enforcement of standards SQA must be established to ensure that standards are being followed. An assessment of compliance to standards must be conducted 5. Control of change Every change to software has the potential for introducing error or creating side effects that propagate errors. Request for change must be formalize, evaluate the nature of change, control the impact of change. 6. Measurement To track software quality and assess impact of changes to software quality. 7. Record keeping and reporting `

Provide procedures for the collection and dissemination of SQA information.

Software Quality and Productivity: What Top Management Must Do A.

Create constancy of purpose to increase software quality and productivity. With a plan to become competitive and to stay in business. Top management is responsible to the general public, especially the software users whose satisfaction is the supreme justification for the existence of a software business.

B.

Adopt the new philosophy of quality and cost-effective software - with the understanding that we can no longer live with delays, mistakes, poor quality and costly software.

C.

Cease dependence on conventional software methods - requiring, instead, statistical evidence that software quality is built in the eliminate need for inspection and correction on the job where the software is used. Top management of every computer and software developer and user company has a new job and must learn it. Every user company can now demand meaningful software warranty using statistical quality control. Every developer company must now show credibility by delivering software warranty.

D.

End the practice of awarding software business on a lowest cost basis demanding, instead, meaningful measures of quality along with price. Software

Elmerito D. Pineda, MBA-IS, DIT(cand)

Page No. 10/11

Software Development

Software Quality Assurance

developers who cannot qualify with statistical evidence of quality must be eliminated. E.

Find problems - Management must work continually on improving software practices: training, supervision, retraining, and improvement of software development methodologies using statistical methods.

F.

Institute modern methods and rigorous programs of training in software engineering and quality assurance with statistical quality control.

G.

Institute modern methods of supervision of software personn...