Total Quality Management FINAL

DEPARTMENT OF MANAGEMENT (LSM) TERM PAPER OF SOFTWARE PROJECT MANAGEMENT ON TOTAL QUALITY MANAGEMENT

SUBMITTED TO: MS. PENCY

SUBMITTED BY: SALEEM ANWAR ROLL NO: A 06 SHUJA QAMMER ROLL NO: A 03 JEEVAN JOT KAUR ROLL NO: A 01

MBA (IT) 3rd Sem.

1

ACKNOWLEDGEMENT

The successful completion of any task would be incomplete without mentioning the people who have made it possible. So it`s with the gratitude that we acknowledge the help, which crowned our efforts with success. Life is a process of accumulating and discharging debts, not all of those can be measured. We cannot hope to discharge them with simple words of thanks but we can certainly acknowledge them. We owe our gratitude to Ms.Pency Lect. LSM for her constant guidance and support. We would also like to thank the various department officials and staff who not only provided us with required opportunity but also extended their valuable time and we have no words to express our gratefulness to them. Last but not the least we are very much indebted to our family and friends for their warm encouragement and moral support in conducting this project work. SALEEM ANWAR ,SHUJA QAMMER & JEEVAN JOT.

2

Table of Contents
Table of Contents...................................................................................................3 INTRODUCTION...................................................................................................... 5 SOFTWARE QUALITY FACTORS...............................................................................6 Understandability................................................................................................7 Completeness..................................................................................................... 7 Conciseness........................................................................................................ 7 Portability............................................................................................................7 Consistency.........................................................................................................7 Maintainability.................................................................................................... 7 Testability........................................................................................................... 8 Usability.............................................................................................................. 8 Reliability............................................................................................................ 8 Efficiency............................................................................................................ 8 Security............................................................................................................... 8 MEASUREMENT OF SOFTWARE QUALITY FACTORS................................................8 Understandability..............................................................................................10 Completeness................................................................................................... 10 Conciseness...................................................................................................... 10 Portability..........................................................................................................10 Consistency.......................................................................................................10 Maintainability.................................................................................................. 11 Testability......................................................................................................... 11 Usability............................................................................................................ 11 Reliability.......................................................................................................... 11 Efficiency.......................................................................................................... 11 Security............................................................................................................. 11 QUALITY ASSURANCE IN SOFTWARE DEVELOPMENT...........................................12 Models and standards.......................................................................................12 SOFTWARE PRODUCT QUALITY............................................................................12 QUALITY IMPROVEMENT.......................................................................................13 SOFTWARE QUALITY MANAGEMENT PROCESSES.................................................14 Software quality assurance...............................................................................15

3

Verification & Validation...................................................................................16 Reviews and Audits...........................................................................................17 Management reviews.....................................................................................18 Technical reviews..........................................................................................18 Inspections.....................................................................................................19 Walk-through.................................................................................................20 Audits............................................................................................................ 20 SOFTWARE QUALITY REQUIREMENTS...................................................................20 SOFTWARE QUALITY MANAGEMENT TECHNIQUES...............................................21 Static techniques..............................................................................................21 People-intensive techniques.............................................................................21 Analytical techniques........................................................................................22 Dynamic techniques.........................................................................................22 Testing.............................................................................................................. 23 REFRENCES.......................................................................................................... 24

4

INTRODUCTION
The notion of “quality” is not as simple as it may seem. For any engineered product, there are many desired qualities relevant to a particular project, to be discussed and determined at the time that the product requirements are determined. Qualities may be present or absent, or may be matters of degree, with tradeoffs among them, with practicality and cost as major considerations. The software engineer has a responsibility to elicit the system’s quality requirements that may not be explicit at the outset and to discuss their importance and the difficulty of attaining them. All processes associated with software quality (e.g. building, checking, improving quality) will be designed with these in mind and carry costs based on the design. Thus, it is important to have in mind some of the possible attributes of quality, Software quality may be 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. This definition emphasis from three points: 1. 2. 3. Software requirements are the foundations from which quality is measured. Specified standards define a set of development criteria that guide the manager A set of implicit requirements often goes unmentioned, like for example ease

is software engineering. of use, maintainability etc. A definition in Steve McConnell's Code Complete divides software into two

pieces: internal and external quality characteristics. External quality characteristics are those parts of a product that face its users, where internal quality characteristics are those that do not. Another definition by Dr. Tom DeMarco says "a product's quality is a function of how much it changes the world for the better." This can be interpreted as meaning that user satisfaction is more important than anything in determining software quality. Another definition, coined by Gerald Weinberg in Quality Software Management: Systems Thinking, is "Quality is value to some person." This definition stresses that quality is
5

inherently subjective - different people will experience the quality of the same software very differently. One strength of this definition is the questions it invites software teams to consider, such as "Who are the people we want to value our software?" and "What will be valuable to them?" In the context of software engineering, software quality measures how well software is designed (quality of design), and how well the software conforms to that design (quality of conformance), although there are several different definitions. It is often described as the 'fitness for purpose' of a piece of software. Whereas quality of conformance is concerned with implementation (see Software Quality Assurance), quality of design measures how valid the design and requirements are in creating a worthwhile product. Software reliability is an important facet of software quality. It is defined as "the probability of failure-free operation of a computer program in a specified environment for a specified time". One of reliability's distinguishing characteristics is that it is objective, measurable, and can be estimated, whereas much of software quality is subjective criteria. This distinction is especially important in the discipline of Software Quality Assurance. These measured criteria are typically called software metrics. The software used to track the three main components of quality management through the use of databases and/or charting applications.

SOFTWARE QUALITY FACTORS
A software quality factor is a non-functional requirement for a software program which is not called up by the customer's contract, but nevertheless is a desirable requirement which enhances the quality of the software program. Note that none of these factors are binary; that is, they are not “either you have it or you don’t” traits. Rather, they are characteristics that one seeks to maximize in one’s software to optimize its quality. Some software quality factors are listed here:

6

Understandability
Clarity of purpose-This goes further than just a statement of purpose; all of the design and user documentation must be clearly written so that it is easily understandable. This is obviously subjective in that the user context must be taken into account: for instance, if the software product is to be used by software engineers it is not required to be understandable to the layman.

Completeness
Presence of all constituent parts, with each part fully developed. This means that if the code calls a subroutine from an external library, the software package must provide reference to that library and all required parameters must be passed. All required input data must also be available.

Conciseness
Minimization of excessive or redundant information or processing. This is important where memory capacity is limited, and it is generally considered good practice to keep lines of code to a minimum. It can be improved by replacing repeated functionality by one subroutine or function which achieves that functionality. It also applies to documents.

Portability
Ability to be run well and easily on multiple computer configurations. Portability can mean both between different hardware such as running on a PC as well as a Smartphone and between different operating systems such as running on both Mac OS X and GNU/Linux.

Consistency
Uniformity in notation, symbology, appearance, and terminology within itself.

Maintainability
Propensity to facilitate updates to satisfy new requirements. Thus the software product that is maintainable should be well-documented, should not be complex, and should have spare capacity for memory, storage and processor utilization and other resources.

7

Testability
Disposition to support acceptance criteria and evaluation of performance. Such a characteristic must be built-in during the design phase if the product is to be easily testable; a complex design leads to poor testability.

Usability
Convenience and practicality of use. This is affected by such things as the humancomputer interface. The component of the software that has most impact on this is the user interface (UI), which for best usability is usually graphical (i.e. a GUI).

Reliability
Ability to be expected to perform its intended functions satisfactorily. This implies a time factor in that a reliable product is expected to perform correctly over a period of time. It also encompasses environmental considerations in that the product is required to perform correctly in whatever conditions it finds itself (sometimes termed robustness).

Efficiency
Fulfilment of purpose without waste of resources, such as memory, space and processor utilization, network bandwidth, time, etc.

Security
Ability to protect data against unauthorized access and to withstand malicious or inadvertent interference with its operations. Besides the presence of appropriate security mechanisms such as authentication, access control and encryption, security also implies resilience in the face of malicious, intelligent and adaptive attackers.

MEASUREMENT OF SOFTWARE QUALITY FACTORS

There are varied perspectives within the field on measurement. There are a great many measures that are valued by some professionals or in some contexts that are decried as harmful by others. Some believe that quantitative measures of software quality are essential.
8

Others believe that contexts where quantitative measures are useful are quite rare, and so prefer qualitative measures. Several leaders in the field of software testing have written about the difficulty of measuring what we truly want to measure well. One example of a popular metric is the number of faults encountered in the software. Software that contains few faults is considered by some to have higher quality than software that contains many faults. Questions that can help determine the usefulness of this metric in a particular context include: 1. What constitutes “many faults?” Does this differ depending upon the purpose

of the software (e.g., blogging software vs. navigational software)? Does this take into account the size and complexity of the software? 2. Does this account for the importance of the bugs (and the importance to the stakeholders of the people those bugs bug)? Does one try to weight this metric by the severity of the fault, or the incidence of users it affects? If so, how? And if not, how does one know that 100 faults discovered is better than 1000? 3. If the count of faults being discovered is shrinking, how do I know what that means? For example, does that mean that the product is now higher quality than it was before? Or that this is a smaller/less ambitious change than before? Or that fewer tester-hours have gone into the project than before? Or that this project was tested by less skilled testers than before? Or that the team has discovered that fewer faults reported is in their interest? This last question points to an especially difficult one to manage. All software quality metrics are in some sense measures of human behaviour, since humans create software. If a team discovers that they will benefit from a drop in the number of reported bugs, there is a strong tendency for the team to start reporting fewer defects. That may mean that email begins to circumvent the bug tracking system, or that four or five bugs get lumped into one bug report, or that testers learn not to report minor annoyances. The difficulty is measuring what we mean to measure, without creating incentives for software programmers and testers to consciously or unconsciously “game” the measurements. Software quality factors cannot be measured because of their vague definitions. It is necessary to find measurements, or metrics, which can be used to quantify them as nonfunctional requirements. For example, reliability is a software quality factor, but cannot be
9

evaluated in its own right. However, there are related attributes to reliability, which can indeed be measured. Some such attributes are mean time to failure, rate of failure occurrence, and availability of the system. Similarly, an attribute of portability is the number of targetdependent statements in a program. A scheme that could be used for evaluating software quality factors is given below. For every characteristic, there are a set of questions which are relevant to that characteristic. Some type of scoring formula could be developed based on the answers to these questions, from which a measurement of the characteristic can be obtained.

Understandability
Are variable names descriptive of the physical or functional property represented? Do uniquely recognisable functions contain adequate comments so that their purpose is clear? Are deviations from forward logical flow adequately commented? Are all elements of an array functionally related?

Completeness
Are all necessary components available? Does any process fail for lack of resources or programming? Are all potential pathways through the code accounted for, including proper error handling?

Conciseness
Is all code reachable? Is any code redundant? How many statements within loops could be placed outside the loop, thus reducing computation time? Are branch decisions too complex?

Portability
Does the program depend upon system or library routines unique to a particular installation? Have machine-dependent statements been flagged and commented. Has dependency on internal bit representation of alphanumeric or special characters been avoided? How much effort would be required to transfer the program from one hardware/software system or environment to another?

Consistency
Is one variable name used to represent different logical or physical entities in the program? Does the program contain only one representation for any given physical or mathematical
10

constant?

Are functionally similar arithmetic expressions similarly constructed?

Is a

consistent scheme used for indentation, nomenclature, the colour palette, fonts and other visual elements?

Maintainability
Has some memory capacity been reserved for future expansion? Is the design cohesive i.e., does each module have distinct, recognizable functionality. Does the software allow for a change in data structures (object-oriented designs are more likely to allow for this). If the code is procedure-based (rather than object-oriented), is a change likely to require restructuring the main program, or just a module.

Testability
Are complex structures employed in the code? Does the detailed design contain clear pseudocode? Is the pseudo-code at a higher level of abstraction than the code? If tasking is used in concurrent designs, are schemes available for providing adequate test cases.

Usability
Is a GUI used? Is there adequate on-line help? Is a user manual provided? Are meaningful error messages provided?

Reliability
Are loop indexes range-tested? Is input data checked for range errors? Is divide-by-zero avoided? Is exception handling provided? It is the probability that the software performs its intended functions correctly in a specified period of time under stated operation conditions. But there could also be a problem with the requirement document.

Efficiency
Have functions been optimized for speed. Have repeatedly used blocks of code been formed into subroutines. Has the program been checked for memory leaks or overflow errors?

Security
Does the software protect itself and its data against unauthorized access and use? Does it allow its operator to enforce security policies? Are security mechanisms appropriate, adequate and correctly implemented? Can the software withstand attacks that can be anticipated in its intended environment?
11

QUALITY ASSURANCE IN SOFTWARE DEVELOPMENT
The following are examples of QA models relating to the software development process

Models and standards
ISO 17025 is an international standard that specifies the general requirements for the competence to carry out tests and or calibrations. There are 15 management requirements and 10 technical requirements. These requirements outline what a laboratory must do to become accredited. Management system refers to the organization's structure for managing its processes or activities that transform inputs of resources into a product or service which meets the organization's objectives, such as satisfying the customer's quality requirements, complying with regulations, or meeting environmental objectives. The CMMI (Capability Maturity Model Integration) model is widely used to implement Quality Assurance (PPQA) in an organization. The CMMI maturity levels can be divided in to 5 steps, which a company can achieve by performing specific activities within the organization. (CMMI QA processes are excellent for companies like NASA, and may even be adapted for agile development style).

SOFTWARE PRODUCT QUALITY
The software engineer needs, first of all, to determine the real purpose of the software. In this regard, it is of prime importance to keep in mind that the customer’s requirements come first and that they include quality requirements, not just functional requirements. Thus, the software engineer has a responsibility to elicit quality requirements which may not be explicit at the outset and to discuss their importance as well as the level of difficulty in attaining them. All processes associated with software quality (for example, building, checking, and improving quality) will be designed with these requirements in mind, and they carry additional costs.

12

Standard ISO9126-01 defines, for two of its three models of quality, the related quality characteristics and sub-characteristics, and measures which are useful for assessing software product quality. The meaning of the term “product” is extended to include any artefact which is the output of any process used to build the final software product. Examples of a product include, but are not limited to, an entire system requirements specification, a software requirements specification for a software component of a system, a design module, code, test documentation, or reports produced as a result of quality analysis tasks. While most treatments of quality are described in terms of the final software and system performance, sound engineering practice requires that intermediate products relevant to quality be evaluated throughout the software engineering process.

QUALITY IMPROVEMENT
The quality of software products can be improved through an iterative process of continuous improvement which requires management control, coordination, and feedback from many concurrent processes: the software life cycle processes; the process of error/defect detection, removal, and prevention; and the quality improvement process. The theory and concepts behind quality improvement, such as building in quality through the prevention and early detection of errors, continuous improvement, and customer focus, are pertinent to software engineering. These concepts are based on the work of experts in quality who have stated that the quality of a product is directly linked to the quality of the process used to create it. Approaches such as the Total Quality Management (TQM) process of Plan, Do, Check, and Act (PDCA) are tools by which quality objectives can be met. Management sponsorship supports process and product evaluations and the resulting findings. Then, an improvement program is developed identifying detailed actions and improvement projects to be addressed in a feasible time frame. Management support implies that each improvement project has enough resources to achieve the goal defined for it. Management sponsorship must be

13

solicited frequently by implementing proactive communication activities. The involvement of work groups, as well as middle-management support and resources allocated at project level.

SOFTWARE QUALITY MANAGEMENT PROCESSES
Software quality management (SQM) applies to all perspectives of software processes, products, and resources. It defines processes, process owners, and requirements for those processes, measurements of the process and its outputs, and feedback channels. Software quality management processes consist of many activities. Some may find defects directly, while others indicate where further examination may be valuable. The latter are also referred to as direct-defect-finding activities. Many activities often serve as both. Planning for software quality involves:
• •

Defining the required product in terms of its quality characteristics. Planning the processes to achieve the required product.

These aspects differ from, for instance, the planning SQM processes themselves, which assess planned quality characteristics versus actual implementation of those plans. The software quality management processes must address how well software products will, or do, satisfy customer and stakeholder requirements, provide value to the customers and other stakeholders, and provide the software quality needed to meet software requirements. SQM can be used to evaluate the intermediate products as well as the final product. Some of the specific SQM processes are defined in standard (IEEE12207.0-96):
• • • • •

Quality assurance process Verification process Validation process Review process Audit process

14

These processes encourage quality and also find possible problems. But they differ somewhat in their emphasis. SQM processes help ensure better software quality in a given project. They also provide, as a by-product, general information to management, including an indication of the quality of the entire software engineering process. The Software Engineering Process and Software Engineering Management KAs discuss quality programs for the organization developing the software. SQM can provide relevant feedback for these areas. SQM processes consist of tasks and techniques to indicate how software plans (for example, management, development, configuration management) are being implemented and how well the intermediate and final products are meeting their specified requirements. Results from these tasks are assembled in reports for management before corrective action is taken. The management of an SQM process is tasked with ensuring that the results of these reports are accurate. As described in this KA, SQM processes are closely related; they can overlap and are sometimes even combined. They seem largely reactive in nature because they address the processes as practiced and the products as produced; but they have a major role at the planning stage in being proactive in terms of the processes and procedures needed to attain the quality characteristics and degree of quality needed by the stakeholders in the software. Risk management can also play an important role in delivering quality software. Incorporating disciplined risk analysis and management techniques into the software life cycle processes can increase the potential for producing a quality product.

Software quality assurance
SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning, enacting, and performing a set of activities to provide adequate confidence that quality is being built into the software. This means ensuring that the problem is clearly and adequately stated and that the solution’s requirements are properly defined and expressed. SQA seeks to maintain the quality throughout the development and maintenance of the product by the execution of a variety of activities at each stage which can result in early identification of problems, an almost

15

inevitable feature of any complex activity. The role of SQA with respect to process is to ensure that planned processes are appropriate and later implemented according to plan, and that relevant measurement processes are provided to the appropriate organization. The SQA plan defines the means that will be used to ensure that software developed for a specific product satisfies the user’s requirements and is of the highest quality possible within project constraints. In order to do so, it must first ensure that the quality target is clearly defined and understood. It must consider management, development, and maintenance plans for the software. Refer to standard (IEEE730-98) for details. The specific quality activities and tasks are laid out, with their costs and resource requirements, their overall management objectives, and their schedule in relation to those objectives in the software engineering management, development, or maintenance plans. The SQA plan should be consistent with the software configuration management plan. The SQA plan identifies documents, standards, practices, and conventions governing the project and how they will be checked and monitored to ensure adequacy and compliance. The SQA plan also identifies measures, statistical techniques, procedures for problem reporting and corrective action, resources such as tools, techniques, and methodologies, security for physical media, training, and SQA reporting and documentation. Moreover, the SQA plan addresses the software quality assurance activities of any other type of activity described in the software plans, such as procurement of supplier software to the project or commercial offthe-shelf software (COTS) installation, and service after delivery of the software. It can also contain acceptance criteria as well as reporting and management activities which are critical to software quality.

Verification & Validation
For purposes of brevity, Verification and Validation (V&V) are treated as a single topic in this Guide rather than as two separate topics as in the standard (IEEE12207.0-96). “Software V&V is a disciplined approach to assessing software products throughout the product life cycle. A V&V effort strives to ensure that quality is built into the software and that the software satisfies user requirements” (IEEE1059-93).

16

V&V addresses software product quality directly and uses testing techniques which can locate defects so that they can be addressed. It also assesses the intermediate products, however, and, in this capacity, the intermediate steps of the software life cycle processes. The V&V process determines whether or not products of a given development or maintenance activity conform to the requirement of that activity, and whether or not the final software product fulfils its intended purpose and meets user requirements. Verification is an attempt to ensure that the product is built correctly, in the sense that the output products of an activity meet the specifications imposed on them in previous activities. Validation is an attempt to ensure that the right product is built, that is, the product fulfils its specific intended purpose. Both the verification process and the validation process begin early in the development or maintenance phase. They provide an examination of key product features in relation both to the product’s immediate predecessor and to the specifications it must meet. The purpose of planning V&V is to ensure that each resource, role, and responsibility is clearly assigned. The resulting V&V plan documents and describes the various resources and their roles and activities, as well as the techniques and tools to be used. An understanding of the different purposes of each V&V activity will help in the careful planning of the techniques and resources needed to fulfil their purposes. The plan also addresses the management, communication, policies, and procedures of the V&V activities and their interaction, as well as defect reporting and documentation requirements.

Reviews and Audits
For purposes of brevity, reviews and audits are treated as a single topic in this Guide, rather than as two separate topics as in (IEEE12207.0-96). The review and audit process is broadly defined in (IEEE12207.0-96) and in more detail in (IEEE1028-97). Five types of reviews or audits are presented in the IEEE1028-97 standard:
• • • •

Management reviews Technical reviews Inspections Walk-through

17

•

Audits

Management reviews

The purpose of a management review is to monitor progress, determine the status of plans and schedules, confirm requirements and their system allocation, or evaluate the effectiveness of management approaches used to achieve fitness for purpose. They support decisions about changes and corrective actions that are required during a software project. Management reviews determine the adequacy of plans, schedules, and requirements and monitor their progress or inconsistencies. These reviews may be performed on products such as audit reports, progress reports, V&V reports, and plans of many types, including risk management, project management, software configuration management, software safety, and risk assessment, among others.
Technical reviews

The purpose of a technical review is to evaluate a software product to determine its suitability for its intended use. The objective is to identify discrepancies from approved specifications and standards. The results should provide management with evidence confirming (or not) that the product meets the specifications and adheres to standards and that changes are controlled” (IEEE1028-97). Specific roles must be established in a technical review: a decision-maker, a review leader, a recorder, and technical staff to support the review activities. A technical review requires that mandatory inputs be in place in order to proceed:
• • • • •

Statement of objectives A specific software product The specific project management plan The issues list associated with this product The technical review procedure

The team follows the review procedure. A technically qualified individual presents an overview of the product, and the examination is conducted during one or more meetings. The technical review is completed once all the activities listed in the examination have been completed.

18

Inspections

The purpose of an inspection is to detect and identify software product anomalies. Two important differentiators of inspections as opposed to reviews are as follows:
•

An individual holding a management position over any member of the inspection team shall not participate in the inspection. An inspection is to be led by an impartial facilitator who is trained in inspection techniques.

•

Software inspections always involve the author of an intermediate or final product, while other reviews might not. Inspections also include an inspection leader, a recorder, a reader, and a few (2 to 5) inspectors. The members of an inspection team may possess different expertise, such as domain expertise, design method expertise, or language expertise. Inspections are usually conducted on one relatively small section of the product at a time. Each team member must examine the software product and other review inputs prior to the review meeting, perhaps by applying an analytical technique to a small section of the product, or to the entire product with a focus only on one aspect, for example, interfaces. Any anomaly found is documented and sent to the inspection leader. During the inspection, the inspection leader conducts the session and verifies that everyone has prepared for the inspection. A checklist, with anomalies and questions germane to the issues of interest, is a common tool used in inspections. The resulting list often classifies the anomalies and is reviewed for completeness and accuracy by the team. The inspection exit decision must correspond to one of the following three criteria:
• • •

Accept with no or at most minor reworking Accept with rework verification Re inspect

Inspection meetings typically last a few hours, whereas technical reviews and audits are usually broader in scope and take longer.

19

Walk-through

The purpose of a walk-through is to evaluate a software product. A walk-through may be conducted for the purpose of educating an audience regarding a software product. The major objectives are to:
• • • •

Find anomalies Improve the software product Consider alternative implementations Evaluate conformance to standards and specifications

The walk-through is similar to an inspection but is typically conducted less formally. The walk-through is primarily organized by the software engineer to give his teammates the opportunity to review his work, as an assurance technique.
Audits

The purpose of a software audit is to provide an independent evaluation of the conformance of software products and processes to applicable regulations, standards, guidelines, plans, and procedures. The audit is a formally organized activity, with participants having specific roles, such as lead auditor, another auditor, a recorder, or an initiator, and includes a representative of the audited organization. The audit will identify instances of non conformance and produce a report requiring the team to take corrective action. While there may be many formal names for reviews and audits such as those identified in the standard (see IEEE1028- 97), the important point is that they can occur on almost any product at any stage of the development or maintenance process.

SOFTWARE QUALITY REQUIREMENTS
Various factors influence planning, management, and selection of SQM activities and techniques, including:
•

The domain of the system in which the software will reside (safety-critical, missioncritical, business-critical) System and software requirements
20

•

• • •

The commercial (external) or standard (internal) components to be used in the system The specific software engineering standards applicable The methods and software tools to be used for development and maintenance and for quality evaluation and improvement The budget, staff, project organization, plans, and scheduling of all the processes The intended users and use of the system The integrity level of the system

• • •

Information on these factors influences how the SQM processes are organized and documented, how specific SQM activities are selected, what resources are needed, and which will impose bounds on the efforts.

SOFTWARE QUALITY MANAGEMENT TECHNIQUES
SQM techniques can be categorized in many ways: static, people-intensive, analytical, dynamic.

Static techniques
Static techniques involve examination of the project documentation and software, and other information about the software products, without executing them. These techniques may include people-intensive activities or analytical activities conducted by individuals, with or without the assistance of automated tools.

People-intensive techniques
The setting for people-intensive techniques, including reviews and audits, may vary from a formal meeting to an informal gathering or a desk-check situation, but (usually, at least) two or more people are involved. Preparation ahead of time may be necessary. Resources other than the items under examination may include checklists and results from analytical techniques and testing. These activities are discussed in (IEEE1028-97) on reviews and audits.

21

Analytical techniques
A software engineer generally applies analytical techniques. Sometimes several software engineers use the same technique, but each applies it to different parts of the product. Some techniques are tool-driven; others are manual. Some may find defects directly, but they are typically used to support other techniques. Some also include various assessments as part of overall quality analysis. Examples of such techniques include complexity analysis, control flow analysis, and algorithmic analysis. Each type of analysis has a specific purpose, and not all types are applied to every project. An example of a support technique is complexity analysis, which is useful for determining whether or not the design or implementation is too complex to develop correctly, to test, or to maintain. The results of a complexity analysis may also be used in developing test cases. Defect-finding techniques, such as control flow analysis, may also be used to support another activity. For software with many algorithms, algorithmic analysis is important, especially when an incorrect algorithm could cause a catastrophic result. There are too many analytical techniques to list them all here. The list and references provided may offer insights into the selection of a technique, as well as suggestions for further reading. Other, more formal, types of analytical techniques are known as formal methods. They are used to verify software requirements and designs. Proof of correctness applies to critical parts of software. They have mostly been used in the verification of crucial parts of critical systems, such as specific security and safety requirements.

Dynamic techniques
Different kinds of dynamic techniques are performed throughout the development and maintenance of software. Generally, these are testing techniques, but techniques such as simulation, model checking, and symbolic execution may be considered dynamic. Code reading is considered a static technique, but experienced software engineers may execute the code as they read through it. In this sense, code reading may also qualify as a dynamic technique. This discrepancy in categorizing indicates that people with different roles in the organization may consider and apply these techniques differently.

22

Some testing may thus be performed in the development process, SQA process, or V&V process, again depending on project organization. Because SQM plans address testing, this section includes some comments on testing.

Testing
The assurance processes described in SQA and V&V examine every output relative to the software requirement specification to ensure the output’s traceability, consistency, completeness, correctness, and performance. This confirmation also includes the outputs of the development and maintenance processes, collecting, analyzing, and measuring the results. SQA ensures that appropriate types of tests are planned, developed, and implemented, and V&V develops test plans, strategies, cases, and procedures. Two types of testing may fall under the headings SQA and V&V, because of their responsibility for the quality of the materials used in the project:
• •

Evaluation and test of tools to be used on the project (IEEE1462-98) Conformance test (or review of conformance test) of components and COTS products to be used in the product; there now exists a standard for software packages (IEEE1465-98)

Sometimes an independent V&V organization may be asked to monitor the test process and sometimes to witness the actual execution to ensure that it is conducted in accordance with specified procedures. Again, V&V may be called upon to evaluate the testing itself: adequacy of plans and procedures, and adequacy and accuracy of results. Another type of testing that may fall under the heading of V&V organization is third-party testing. The third party is not the developer, nor is in any way associated with the development of the product. Instead, the third party is an independent facility, usually accredited by some body of authority. Their purpose is to test a product for conformance to a specific set of requirements.

23

REFRENCES
1.

Paul H. Selden (December 1998). "Sales Process Engineering: An Emerging Quality Management Strategy, May 2010 "Object Oriented Quality Management, a model for quality management.". http://ssrn.com/abstract=1488690 "Thareja" Thareja P(2008), "Total Quality Organization Thru’ People, Each one is Pyzdek, T, "Quality Engineering Handbook", 2003, ISBN 0824746147 http://www.softwarequalitymethods.com/Papers/DarkMets%20Paper.pdf http://www.kaner.com/pdfs/metrics2004.pdf

Quality Application". Quality Progress: 59–63.
2. 3.

Statistics Netherlands, The Hague.
4. 5.

Capable", FOUNDRY, Vol. XX, No. 4, July/Aug 2008
6. 7. 8.

24