Download Software Quality - Lecture 04 Slides 2011 - Computer Science and more Slides Computer Science in PDF only on Docsity!
Department of Computer & Information Sciences Pakistan Institute of Engineering and Applied Sciences
Department of Computer & Information Sciences Pakistan Institute of Engineering and Applied Sciences
Software Quality
Lecture 3
Elements of Software Quality System
Umar Faiz http://www.pieas.edu.pk/umarfaiz/cis
Software Quality Umar Faiz
http://www.pieas.edu.pk/umarfaiz/cis
Elements of a Software Quality System
Goals of Software Quality
There are two goals of the software quality system. The first goal is to build quality into the software from the beginning. The second goal of the SQS is to keep that quality in the software throughout the software life cycle.
Elements of a Software Quality System
The 10 elements of the SQS are as follows:
Standards Reviewing Testing Defect analysis Configuration management (CM)Configuration management (CM) Security Education Vendor management Safety Risk management
Elements of a Software Quality System
Every SLC model has divisions, or periods of effort, into
which the work of developing the software is divided.
Recognition of a need or problem (e.g., concept definition) Definition of the software solution to be applied (e.g., requirements definition) Developmentp of the software that solves the pproblem or satisfies the need (e.g., design and coding) Proving that the solution is correct (e.g., testing) Implementing the solution (e.g., installation and acceptance) Using the solution (e.g., operation) Improving the solution (e.g., maintenance)
1. Standards
Standards
Standards are intended to provide consistent, rigorous, uniform, and enforceable methods for software development and operation activities. Software standards should be imposed so that the producer of a software product or component can pay attention to the technical aspects of the taskattention to the technical aspects of the task. It should be the intent of responsible management to see that they are followed and enforced.
1. Standards
Quality Assurance and Standards
Concerned with ensuring that the required level of quality is achieved in a software product. Involves defining appropriate quality standards and procedures and ensuring that these are followed. Should aim to develop a ‘quality culture’ where quality is seen as everyone’s ’ responsibility.ibilit
1. Standards
Standard: Definition
It is the deliberate acceptance by a group of people having common interests or background of a quantifiable metric that influences their behaviour and activities by permitting a common interchange.
Standard: ISO Definition
Document, established by consensus and approved by a recognized body, that provides, for common and repeated use, rules, guidelines or characteristics for activities or their results, aimed at the achievement of the optimum degree of order in a given context
1. Standards
Standards
Whether a standard comes from within a company, is imposed by government, or is adopted from an industry source, it must have several characteristics. These include the following: Necessity : No standard will be observed for long if there is no real reason ffor its existence. Feasibility : Common sense tells us that if it is not possible to comply with the tenets of a standard, then it will be ignored. Measurability : It must be possible to demonstrate that the standard is being followed.
1. Standards
Types of Standards
Regulatory Standards: These standards are imposed by Government legislation or regulation. Traffic Speed Limits Telecomm Regulations Electric Voltages for Distribution standards. Consensus Standards: These standards are adopted by a community of interest to further the interests of the community.
1. Standards
Types of Standards
External Standards: These standards define the ways in which an organisation relates to its clients and competitors. AS 3563; ISO 9001; ANSI/IEEE 730
Internal Standards: These standards define the practices and procedures in place within an organisation.
1. Standards
Focus of Standards
Standards which define in detail a specific product. Standards which define the process through which products in the field need to pass. Standards which define requirements for a particular resource to be used in the development process.
1. Standards
Development Process of Standards
2. Reviews
Types of Reviews
Informal reviews generally occur during SDLC phases, while formal reviews usually mark the ends of the phases. Informal reviews include walk‐throughs and inspections
2. Reviews
Types of Reviews
Walkthroughs Walkthroughs are informal, but scheduled, reviews, usually conducted by peer groups. The author of the subject component‐a design specification, test procedure, coded unit walks through his or her component, explaining it to a small group of peers. The role of the peers is to look for defects in or problems with theof the peers is to look for defects in or problems with the component. These are then corrected before the component becomes the basis for further development.
2. Reviews
Types of Reviews
Inspections Inspections are a more structured type of walk‐through. Though the basic goal of an inspection‐removal of defects‐is the same as that of the walk‐through, the format of the meeting and the roles of the participants are more strictly defined, and more formal records of the proceedings are preparedrecords of the proceedings are prepared.
2. Reviews
Types of Reviews
Process reviews The purpose of a process review is to examine the success of the software process in effect. Data for the review is collected in the technical reviews and is usually based on defects identified by the technical reviews.
2. Reviews
Types of Reviews
Audits Audits are examinations of components for compliance with a content and format specification or for consistency with or comparison to a predecessor.
3. Testing
Testing
Test activities include planning, design, execution, and reporting. Actual testing begins with the debugging and early unit and module tests conducted by the programmer. Formal test execution generally begins with integration tt estst ii n whichhi h modulesd l are combinedbi d i t into subsystemsb t ffor functional testing.
3. Testing
Testing
Test execution requires the use of detailed test procedures. These are step‐by‐step directions that tell the test conductor exactly what to do as the test is run. Every action, input, expected output, and response should be documented so that the test conductor is not put into the position of making test design decisions while the test is being runof making test design decisions while the test is being run. Test cases, scenarios, data, and procedures, together with expected results and completion criteria, should be ready to be applied from module testing
4. Defect Analysis
Defect Analysis
Defect analysis is the combination of defect detection and correction, and defect trend analysis. Defect detection and correction, together with change control, presents a record of all discrepancies found in each software component. It also records the disposition of each discrepancy, perhaps in the form of a software problem report or software change request.
4. Defect Analysis
Defect Analysis
A running record of defects, their solutions, and status is provided by the defect trend analysis effort The record of defects and their solutions can serve to do the following: Prevent defects from remaining unsolved for inappropriate ll engthsh off time; Prevent unwarranted changes; Point out inherently weak areas in the software; Provide analysis data for development process evaluation and correction; Provide warnings of potential defects through analysis of defect trends.
5. Configuration Management
Configuration Management
Configuration Management consists of three related activities: identification, control, and accounting. Its intent is to maintain control of the software, both during development and after it is put into use and changes begin.
5. Configuration Management
Configuration Identification
Configuration identification is, as its name implies, the naming, and documentation, of each component (document, unit, module, subsystem, and system) so that at any given time, the particular component of interest can be uniquely identified.
5. Configuration Management
Configuration Control
Configuration control is that activity that prevents unauthorized changes to any software product. Any changes to the documents are formally processed so that unnecessary or unapproved changes are not made. As the life cycle moves into the coding, testing, and operation ti andd maintenancei t phases,h changesh tt o eitherith documents or code are closely controlled. Each change is verified for necessity and correctness before approval for insertion, so that control of the software can be maintained.
8. Vendor Management
Off‐the‐Shelf
Off‐the‐shelf software is the package we buy at the store. Microsoft Office, Adobe Photoshop, virus checkers, and the like are examples. These packages come as they are with no warrantee that they will do what you need to have done. They are also almost totally outside the buyeralmost totally outside the buyer s's influence with respect to influence with respect to quality.
8. Vendor Management
Customized
In this case, a basic, existing framework is purchased and the vendor then adds specific capabilities as required by the contract.
8. Vendor Management
Contracted Software
This is software that is contractually specified and provided by a third‐party developer. The contract can also specify the software quality activities that the vendor must perform and which the buyer will audit. The software quality practitioner has the responsibility in each case to determine the optimum level of influence toeach case to determine the optimum level of influence to be applied, and how that influence can be most effectively applied. The purchaser's quality practitioners must work closely with the vendor's quality practitioners to assure that all required steps are being taken.
9. Software Safety
Safety
Every software project must consciously consider the safety implications of the software and the system of which it is a part. The project management plan should include a paragraph describing the safety issues to be considered. If appropriate a software safety plan should be preparedappropriate, a software safety plan should be prepared.
9. Software Safety
Safety
The following are four of the most important aspects of software safety: Software whose failure could damage hardware or equipment Software whose failure could hurt the business or enterprise Software whose failure could cause harm to the environment Software whose failure could cause harm to people
9. Software Safety
Damaging hardware
Damage caused when the software embedded in a generator fails to respond to a high temperature signal. Meltdown of a nuclear power plant caused by an incorrect software action or response.
9. Software Safety
Business or enterprise damage
Software is often used to make important business decisions and actually run the business. A retail store chain could lose track of its inventory and discover its automatic ordering system is ordering the wrong products.
9. Software Safety
Environmental damage
The software monitoring an oil pipeline could fail to detect, or react incorrectly to the detection of, a leaking or burst section of the line. Navigational software failure could cause an oil tanker to run aground and spill millions of gallons of crude oil into the seathe sea.
9. Software Safety
Damage to humans
An air traffic control system failure could result in the collision of aircraft Software controlling a morphine intravenous injection system could result in a patient's overdose.
10. Risk Management
Risk Management
Risk management includes identification of the risk; determining the probability, cost, or threat of the risk; and taking action to eliminate, reduce, or accept the risk. Risk and its treatment is a necessary topic in the project plan and may deserve its own risk management plan.
10. Risk Management
Types of Risk
Technical, managerial, operational, environment, and testing risks all represent threats to the success of a software product. While other risks exist, these are the most prevalent, identifiable, and addressable in a software development or maintenance project.
10. Risk Management
1. Technical Risk
Two major questions need to be asked: Do we really know what the problem is? Is the problem solvable? A complete definition of the business needs and subsequent software requirements is essential prior to software ft dd evelopmentl t Just because a problem is known does not mean it can be solved. Solutions may be too expensive or could turn out to be a negative contribution to the overall business.
10. Risk Management
Software Misuse
Anticipation of, and built‐in software protection against, common unintentional mistakes on the part of the user is a risk response that is often possible. The intentional misuse of the product usually cannot be foreseen and is hard to stop even if it can be foreseen. In these cases clear statements of the proper scope and usethese cases, clear statements of the proper scope and use of the product and specific cautions about the potential results of misuse may be a company's only defense. It is the responsibility of the quality practitioner is to keep management aware of the potential for and possible consequences of product misuse.
10. Risk Management
Maintenance
Both quality control and quality assurance practitioners have direct roles in identifying and addressing maintenance risks. The quality control practitioner's role is to make certain that every maintenance activity is checked, tested, reviewed and configuration managed prior to thereviewed, and configuration managed prior to the completion of the maintenance action.
10. Risk Management
4. Environment Risk
A formal risk should be carried out to assess various types of damage to which the specific data center is vulnerable and the degree of protection that is appropriate.
10. Risk Management
5. Testing Risk
The quality control practitioner should stick to a well‐ constructed test plan and test process to reduce incomplete The results of the analysis will be presented to responsible management for the final decision as to whether to accept the risk or end testingthe risk or end testing.
Elements of a Software Quality System
Suggested Reading:
Practical Guide to Software Quality Management, Second Edition by John W. Horch, Artech House, 2003
