Download Quality, Producing Quality Software-Software Project Management-Lecture Notes and more Study notes Software Project Management in PDF only on Docsity!
LECTURE # 42
10. Quality
10.1 Quality Concept
What is it? It's not enough to talk the talk by saying that soft ware quality is important, you have to (1) explicitly define what is meant when you say 'software quality, (2) create a set of activities that will help ensure that every software engineering Work product exhibits high quality, (3) perform quality assurance activities on every software project, (4) use metrics to develop strategies to improving your software process and as a consequence the quality of. the end product.
Who does it? Everyone involved in the software engineering process is responsible for quality.
Why is it important? You can do it right, or you can do it over again. If a software team stresses quality in all software engineering activities, it reduces the amount of rework that it must do that results in lower costs, and more importantly, improved time-to-market.
What are the steps? Before software quality assurance activities can be initiated, it is important to define 'software quality' at a number of different levels of abstraction, Once you understand what quality is, a software team must identify a set of SQA activities that will filter errors out of work products before they are passed on.
What is the work product? A Software Quality Assurance Plan is created to define a software team's SQA strategy. During analysis, design, and code generation, the primary SQA work product is the formal technical review summary report. During testing, test plans and procedures are produced. Other work products associated with process improvement may also be generated.
How do I ensure that I've done it right? Find errors before they become defects! That is, work to improve your defect removal efficiency, thereby reducing the amount of rework that your software team has to perform.
SQA encompasses:
(1) A quality management approach (2) Effective software engineering technology (methods and tools) (3) Formal technical reviews that are applied throughout the software process (4) A multi-tiered testing strategy
docsity.com
(5) Control of software documentation and the changes made to it (6) A procedure to ensure compliance with software development standards (when applicable) (7) Measurement and reporting mechanisms.
Software quality is defined as conformance to explicitly stated functional and performance requirements, documents, and standards. The factors that affect software quality are a complex combination of conditions that can be measured based on data, such as audit-ability, completeness, consistency, error tolerance, and expandability.1n addition, this data includes hardware independence, software system independence, modularity, security, and simplicity.
Software quality assurance is a planned and systematic approach necessary to ensure the quality of a software product. Software reviews filter the product of all errors. Software reviews can be conducted at all stages in the DLC of a software product, such as analysis, design, and coding.
Testing is an important element of SQA activity. There are various testing tools to automate testing process. The SQA plan is used as the template for all SQA activities planned for a software project and includes details of the SQA activities to be performed during project execution.
SCM is used to establish and maintain integrity of software items and ensure that they can be traced easily. SCM helps define a library structure for storage and retrieval of software items. SCM helps assess the impact of a recommended change and make decisions depending on the costs and benefits. SCM needs to be performed at all phases in the DLC of a software project.
The various SCM activities are identifying changes, controlling changes, controlling versions, implementing changes, and communicating changes. These activities are independent of the supervision of the project or the product manager. This is to ensure objectivity in SCM. The scope of SCM is not limited by code and includes requirements, design, database structures, test plans, and documentation. SCM procedures vary with the project.
10.2 Producing quality software
As we have seen, one of the main problems in producing quality software is the difficulty in determining the degree of quality within the software. As there is no single widely accepted definition for quality, and because different people perceive quality in different ways, both the developer and the customer must reach agreement on metrics for quality' (this is discussed in more detail later). The method of measuring quality may differ for different projects.
docsity.com
process when the work products created fail to meet their specifications. This approach views quality control as part of the manufacturing process.
Quality control activities may be fully automated, entirely manual, or a combination of automated tools and human interaction. A key concept of quality control is that all work products have defined; measurable specifications to which we may compare the output of each process. The feedback loop is essential to minimize the defects produced.
10.4 Quality Control Myths
The establishment of effective quality control frequently encounters various misconceptions and myths, the most common of which is related to the cost effectiveness of quality control. Cobb and Mills (1990) list several of these myths, and suggest methods of combating them. Two of the more prevalent myths identified by Cobb and Mills are described below.
Myth: Quality costs money. This is one of the most common myths (not only in software development). In fact, quality in software usually saves money. Poor quality breeds failure. There is a positive correlation between failures and cost in that it is more expensive to remove execution failures designed into software than to design software to exclude execution failures.
Myth: Software failures are unavoidable. This is one of the worst myths because the statement is partly true, and is therefore often used as an excuse to justify poor quality software. The claim that ‘there is always another bug' should never be a parameter in the design or implementation of software.
As these myths lose ground in modern approaches to software development, the demand for suitable quality control standards and procedures increases. The IEEE issued their first standard for software quality assurance plans in 1984 (IEEE .1984), followed by a detailed guide to support the standard, issued in 1986. The US Department of Defense issued a separate standard 2168 for defense systems software quality programs (DOD 1988b), which forms a companion to the famous US DOD standard 2167A (DOD 1988a) for defense systems software development. The European ISO standard 9000-3, of 1990 (ISO 1990) gives a broader meaning to the term quality assurance and covers configuration control too.
10.5 Resources for quality control
When the SQA mandate includes configuration control activities, the required resources will also include those required for configuration control. Merging SQA and configuration control is not uncommon, and can eliminate some duplication of assignments and activities. Two alternative organizational charts are shown in
docsity.com
Fig. 8.5. Note that for small projects, merging the two groups may mean simply assigning both responsibilities to the same person.
Though many tools are common to quality control and configuration control, few tools are specifically designed for quality control. The following are some of the general support tools that can be useful in supporting SQA activities:
Documentation utilities Software design tools Debugging aids Structured preprocessors File comparators Structure analyzers Standards auditors Simulators Execution analyzers Performance monitors Statistical analysis packages Integrated CASE tools Test drivers Test case generators
These tools support quality control in all phases of software development. Documentation aids can provide partially automatic document writers, spelling checkers and thesauruses etc. Structured preprocessors (such as the UNIX utility lint) are useful both to standardize code listings. And to provide additional compile-time warnings that compilers often overlook. Early warnings regarding possible execution time problems can be provided by simulators, execution time analyzers and performance monitors. Substantial software system testing can often be performed automatically by test suite generators and automatic test executors.
All SQA tools to be used during software development should be identified and described in the SQA plan. This plan includes a description of all required quality assurance resources and details of how they will be applied. Thus, at the start of the project SQA resources can be budgeted and procured as part of the required project development resources.
docsity.com
Many definitions of software quality have been proposed in the literature. For our purposes, software quality 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.
There is little question that this definition could be modified or extended. In fact, a definitive definition of software quality could be debated endlessly. For the purposes of this book, the definition serves to emphasize three important points:
- Software requirements are the foundation from which quality is measured. Lack of conformance to requirements is lack of quality.
- 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.
- A set of implicit requirements often goes unmentioned (e.g., the desire for ease of use and good maintainability). If software conforms to its explicit requirements but fails to meet implicit requirements, software quality is suspect.
Background Issues
Quality assurance is an essential activity for any business that produces products to be used by others. Prior to the twentieth century, quality assurance was the sole responsibility of the craftsperson who built a product. The first formal quality assur ance and control function was introduced at Bell Labs in 1916 and spread rapidly throughout the manufacturing world. During the 1940s, more formal approaches to quality control were suggested. These relied on measurement and continuous process improvement as key elements of quality management.
Today, every company has mechanisms to ensure quality in its products. In fact, explicit statements of a company's concern for quality have become a marketing ploy during the past few decades.
The history of quality assurance in software development parallels the history of quality in hardware manufacturing. During the early days of computing (1950s and 1960s), quality was the sole responsibility of the programmer. Standards for quality assurance for software were introduced in military contract software development during the 1970s and have spread rapidly into software development in the commercial world [IEE94].
docsity.com
Extending the definition presented earlier, software quality assurance is a planned and systematic pattern of actions [SCH98] that are required to ensure high quality in software.
The scope of quality assurance responsibility might best be characterized by paraphrasing a once-popular automobile commercial:
Quality is Job # 1'. The implication for software is that many different constituencies have software quality assurance responsibility-software engineers, project managers, customers, salespeople, and the individuals who serve within an SQA group.
The SQA group serves as the customer's in-house representative. That is, the people who perform SQA must look at the software from the customer's point of view. Has software development been conducted according to pre-established standards? Have the technical disciplines properly performed their roles as part of the SQA activity? The SQA group attempts to answer these and other questions to ensure that software quality is maintained.
SQA Activities
Software quality assurance is composed of a variety of tasks associated with two different constituencies-the software engineers who do technical work and an SQA group that has responsibility for quality assurance planning, oversight, record keeping, analysis, and reporting. 'If Software engineers address quality and perform quality assurance and quality control activities by applying solid technical methods and measures, conducting formal technical reviews, and performing well-planned software testing.
The charter of the SQA group is to assist the software team in achieving a high- quality end product. The Software Engineering Institute [PAU93] recommends a set of SQA activities that address quality assurance planning, oversight, record keeping, analysis, and reporting.
These activities are performed (or facilitated) by an independent SQA group that:
1. Prepares SQA plan for a project
The plan is developed during project planning and is reviewed by all interested parties. Quality assurance activities performed by the software engineering team and the SQA group are governed by the plan. The plan identifies
- evaluations to be performed
- audits and reviews to be performed
- standards that are applicable to the project
docsity.com
- Project document such as project plan, requirements document, test cases, test reports, user manual, and administrative manuals
- Models such as ERDs, class hierarchies
- Technical document such as specifications, test plans
- User document such as help files
All applicable standards to be used in the project are listed in the Standards and Guidelines section of the SQA plan. The standards and practices applied are the document standards, coding standards, and review guidelines.
Example of the contents of a software quality assurance plan
1. Software quality assurance organization and resources Organization structure. Personnel skill level and qualifications Resources **2. SQA standards, procedures, policies and guidelines
- SQA documentation requirements** List of all documentation subject to quality control Description of method of evaluation and approval 4. SQA software requirements Evaluation and approval of software Description of method of evaluation Evaluation of the software development process Evaluation of reused software Evaluation of non-deliverable software 5. Evaluation of storage, handling and delivery Project documents Software Data files **6. Reviews and audits
- Software configuration management** (when not addressed in a separate document) **8. Problem reporting and corrective action
- Evaluation of test procedures
- Tools techniques and methodologies
- Quality control of subcontractors, vendors and suppliers
- Additional control** Miscellaneous control procedures Project specific control 13. SQA reporting, records and documentation. Status reporting procedures Maintenance
docsity.com
Storage and security Retention period
10.8 Software quality metrics
Much attention has been devoted to questions associated with the measurement of quality. How do we determine the extent to which a software product contains this vague attribute called quality? When is the quality of a software product high and when is it low?
One of the more recent developments in quality assurance (not only for software) is the realization that quality is not a binary attribute that either exists or does not exist. Kaposi and Myers (1990), in a paper on measurement-based quality assurance, have stated their belief that 'the quality assurance of products and processes of software engineering must be based on measurement^7. The earlier the measurement of quality begins, the earlier problems will be located. Cohen et al. (1986), in addressing the cost of removing errors during the early phases of software development, proclaim the existence of the famous exponential law^8_._
docsity.com
User-friendliness: The amount of training time needed for a new user
The measurement of software quality should not be performed only at the end of a project. The degree of quality should be measured at regular intervals during development. Thus, any major reduction in the overall measure of quality should act as a warning for the project manager that collective action is required. High quality at the end of the project is achieved by assuring high quality throughout the development of the project.
10.9 Some general guidelines
The basic software quality assurance activities cover the review and approval of the development methodology, the software and documentation, and the supervision and approval of testing. Other SQA activities, such as the supervision of reviews, the selection and approval of development tools, or the administration of configuration control, depend on the way SQA is adapted to a specific project. The size of the project is usually the determining factor. The following guidelines discuss some of the parameters to be considered for different types of project when planning SQA.
In small projects, many SQA activities can be performed by the project manager. This includes the organization and supervision of reviews and audits, the evaluation and selection of development tools, and the selection and application of standards.
Test procedures and testing are always best when conducted by a separate independent team (discussed later). The decision on whether supervision of testing activities can be assigned to SQA depends on many factors, including the independence of the SQA team, the size of the project and the 'complexity of the project.
When testing is performed by an independent test team, SQAS involvement will be minimal. In most other cases it will be the responsibility of the SQA team to plan and supervise the testing of the system.
As a general guideline, it is usually undesirable for SQA to be performed by a member of the development team. However, small projects often cannot justify the cost of a dedicated SQA engineer. This problem can be solved by having a single SQA engineer responsible for two or three small projects (with each project funding its share of the SQA services).
One additional guideline is based on the conclusions of Wesselius and Ververs (1990) for the application of effective quality control:
docsity.com
The ability to control software quality is directly linked to the quality of the software requirements specification. Quality control requires the unambiguous specification of as many of the required characteristics of the software product as possible.
docsity.com
