Download Understanding Software Quality System: Elements & Systematic Approach and more Slides Software Engineering in PDF only on Docsity!
Elements of Software Quality System
Lecture 2 What is Software Quality?
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)
docsity.com
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
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.
2. Reviews
Reviewing
Reviews permit ongoing visibility into the software development and installation activities.
2. Reviews
Types of Reviews
Product reviews Product reviews (also called technical reviews), are formal or informal examinations of products and components throughout the development phases of the life cycle.
docsity.com
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 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.
docsity.com
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 lengths of time;lengths of 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.
docsity.com
7. Vendor Management
Vendor Management
The following are three basic types of purchased software: Off‐the‐shelf; Tailored shell; Contracted.
7. 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.
7. 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.
docsity.com
9. 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 prepared.
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.
docsity.com
