Project Synopsis Software Quality Assurance and Management

Problem Statement: Quality control is defined as a set of activities designed to evaluate the quality of a developed or manufactured product (IEEE), in other words activities whose main objective is the withholding of any product that does not qualify The main objective of quality assurance is to minimize the cost of guaranteeing quality by a variety of activities performed throughout the development and manufacturing. These activities prevent the cause of errors, and detect and correct them early in the development process During the software boom years, quality may have been a secondary issue to rushing products to market. However, during the current software industry early maturity phase, software quality has repeatedly been demonstrated as important for a business to capture customers and gain their loyalty. For example, Mr. Dobson described an event wherein a competitor rushed poor quality software to market in order to take advantage of a new market requirement. FirstLogic however maintained its commitment to quality. As a result, FirstLogic gained market share while the competitor lost. Once accepting that quality is important, firms must determine the dollar value they will place on the quality assurance program. Mr. Chou approached the decision calculus as an insurance issue. For businesses, the cost of the quality assurance program should be proportional to the financial ramifications of a software failure. For projects in either consulting efforts or product development, quality assurance routinely represents 30% to 50% of the cost. In markets where 9-nines reliability is required and logic permutations are high, as in telecom software, quality assurance represents up to 75% of the project costs.

Objectives of the project: The driving force behind this project is to explore different aisles of quality assurance and innovate tools and procedures to push the benchmark. The project aims at thoroughly examining the existing assurance procedures, metrics, calibrating techniques and hence come up with innovative quality assurance customised to cater to health care domain.

Quality assurance begins with project scope definition and continues after project delivery. Early in the project effort, QAs role includes defining and documenting project requirements and

specifications. Throughout the project, QA participates as business analysts in clarify the project issues. Their broad knowledge of the business requirements for the software provides the QA with an important perspective into design issues. Near the end of the project, QAs role shifts towards testing and uncovering system bugs. Following the project, quality assurance participates in project reviews for organizational building and architecture improvements in future releases. Producing quality software requires clear, upfront, system architecture. Once defined, the entire team must follow the roadmap of the system architecture to ensure reuse and to minimize bugs. Terms like cowboys or plumbers describe team members that code outside of the defined architecture. These individuals put the entire project at the risk of coder-specific bugs which are difficult to uncover. Both the technical and business architecture must be determined prior to detailed design and coding. Technical architecture defines issues of persistence, workflow, and message queuing. Separately, business architecture defines the business logic of the system. Mr. Dobson noted that the business architecture and technical architecture should be independent to allow a change in the business logic without altering the technical architecture. Some technological means to managing changing business logic include the use of plug-ins and APIs. A major issue in managing software quality is selecting platforms and core technologies that are embedded within the product or project deliverable. Shortened product lifecycles and continual improvements can cause difficulties over the course of a project lifecycle. To manage the risk of changing platforms, the panel all agreed to the need for locking down the version numbers of system components. As for the risk of new technologies, Mr. Franklin stated that he views new technologies as probably broken. The question is whether the team can live with the problem or otherwise mitigate the risk. Through longevity or use, the risks associated with new technologies can be assessed.

Scope of project: The project will explore various aspects of quality assurance, the main points are mentioned below : What is SQA. Standards and measures of SQA Difference b/w S/w Quality Assurance and S/w Quality Control Common causes behind errors in s/w. SQA System architecture and its components Contract rules and terms of conditions with the customer on SQA Test Life Cycle

Diff types of testing process Different types of Audits and reviews in CMM companies. SQ Metrices Cost control Cost optimization Preventive costs, appraisal costs, re-work cost analysis. Role of a Manager in Software quality control process. Manual vs Automated testing. Capability Maturity Model Six sigma and lean capabilities.

Management and its role in SQA: Top management; this includes the organisations general manager and its executives Department managers; this includes the managers of software development, maintenance and software testing departments. Project managers; this is not only the project managers, but also team leaders of development projects and maintenance services.

The managements overall responsibilities are as follows: Assuring the quality of companys software products and software maintenance services Communicating to employees at all levels the importance of product and service quality additionally to customer satisfaction Assuring satisfactory functioning and full conformity to customer requirements Ensuring that the SQA s system objectives are established and realized Planning and overseeing implementation of changes for the SQA system adaptation to internal or external transformations (e.g. changes in clientele, competition or technology) Intervening directly to aid resolving crisis situations and minimize damages Ensuring availability of resources demanded by the SQA systems

Research Methodology: The research includes every aspect of SQA that encompasses the entire software development process, which includes processes such as requirements definition, software design, coding, source code control, code reviews, change management, configuration management, testing, release management, and product integration. SQA is organized into goals, commitments, abilities, activities, measurements, and verifications. It will sail through the below mentioned bullet points mainly: History Initial efforts to control the quality of production Failure testing Statistical control Total quality management QA in software development Models and standards Company quality Inspiring applications and implementations of SQA ISO overview

History of quality assurance

The development of Quality Assurance traces back to the aftermath of the first world war and the high death rate through accidents during munitions manufacture. Techniques developed in the UK and the States but sprang to prominence in the 1950's with the birth of Japanese manufacturing skills. The purpose of the concept is to manufacture the product or produce the service "Right First Time" and to maintain the cost of quality within budgets when substantial manufacturing cost savings can be achieved. Dr W. Edwards Deming an American statistical academic became the 'father' of the quality movement when invited to 'invigorate the Japanese manufacturing sector in the early 1950'. He was also renowned for his famous 14 principles. A summary of which is worthwhile at this point.

Seek constancy of purpose for continual improvement of products and service Adopt the new philosophy created in Japan Eliminate the need for mass inspection End the practice of awarding business solely on the basis of price Improve constantly and forever every process for planning, production, and service Institute modern methods of training on the job for all Adopt and institute leadership aimed at helping people do a better job Encourage effective two way communication Break down barriers between departments and staff Eliminate the use of slogans without providing methods Eliminate work standards that prescribe quotas - substitute aids and helpful leadership

Remove the barriers that rob workers and management of their right to pride of workmanship Institute a vigorous program of education, and encourage self improvement for everyone

Clearly define top management's permanent commitment to ever improving quality and productivity Many analytical tools and methods have been evolved to achieve these principles in practice including FMEA and Pareto analysis, Ishikawa, 8D, 5 whys and DOE. Widespread use of SPC, Six

Sigma fault prevention and its Master Black Belts concept, quality improvement, lean manufacturing and manual charting APQP processes also arose. To aid the adaptation of these principles by any business organisation management procedures and systems have been continuously codified over the year to now result in the all embracing general purpose international standard ISO9000 as well as specialist codes such as TS16949 and Q1in the automotive sector, ISO 15504 for software project modelling, versioning and control - previously known as Tickit, ISO 13485 (Medical Devices), ISO 17025 (Calibration and test laboratories)- and Qualifas, UL/CSA, QS9000, and many more. Peripheral tools include best practice, planning and achieving continuous improvement (KAIZEN), Total Quality & Change Management, the EFQM Excellence Model and Investors in people. However, after so much endeavour it is sad to relate that so often the principles and tools of 'quality' and 'business excellence' are often inefficiently and ineffectively, applied. The promised benefits are lost in a fog of jargon and empty phrases and are made difficult to attain by an emphasis on models and badges rather than on straightforward good practice.

Failure testing Valuable processes to perform on a whole consumer product is failure testing or stress testing. In mechanical terms this is the operation of a product until it fails, often under stresses such as increasing vibration, temperature, and humidity. This exposes many unanticipated weaknesses in a product, and the data is used to drive engineering and manufacturing process improvements. Often quite simple changes can dramatically improve product service, such as changing to mould-resistant paint or adding lock-washer placement to the training for new assembly personnel. Statistical control Statistical control is based on analyses on objective and subjective data. Many organizations use statistical process control as a tool in any quality improvement effort to track quality data. Any product can be statistically charted as long as they have a common cause variance or special cause variance to track. Walter Shewart of Bell Telephone Laboratories recognized that when a product is made, data can be taken from scrutinized areas of a sample lot of the part and statistical variances are then analyzed and charted. Control can then be implemented on the part in the form of rework or scrap, or control can be implemented on the process that made the part ideally eliminating the defect before more parts can be made like it. Total quality management The quality of products is dependent upon that of the participating constituents, some of which are sustainable and effectively controlled while others are not. The process(es) which are managed with QA pertain to Total Quality Management.

If the specification does not reflect the true quality requirements, the product's quality cannot be guaranteed. For instance, the parameters for a pressure vessel should cover not only the material and dimensions but operating, environmental, safety, reliability and maintainability requirements. QA in software development Main article: Software quality assurance Software quality assurance consists of a means of monitoring the software engineering processes and methods used to ensure quality. The methods by which this is accomplished are many and varied, and may include ensuring conformance to one or more standards, such as ISO 9000 or a model such as CMMI. "QA" is sometimes used informally as a synonym for software testing. 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 into 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).

Quality Measurement: Software quality measurement is about quantifying to what extent a system or software possesses desirable characteristics. This can be performed through qualitative or quantitative means or a mix of both. In both cases, for each desirable characteristic, there are a set of measurable attributes the existence of which in a piece of software or system tend to be correlated and associated with this characteristic. For example, an attribute associated with portability is the number of targetdependent statements in a program. More precisely, using the Quality Function Deployment approach, these measurable attributes are the "hows" that need to be enforced to enable the "whats" in the Software Quality definition above.

The structure, classification and terminology of attributes and metrics applicable to software quality management have been derived or extracted from the ISO 9126-3 and the subsequent ISO 25000:2005 quality model. The main focus is on internal structural quality. Subcategories have been

created to handle specific areas like business application architecture and technical characteristics such as data access and manipulation or the notion of transactions.

The dependence tree between software quality characteristics and their measurable attributes is represented in the diagram on the right, where each of the 5 characteristics that matter for the user (right) or owner of the business system depends on measurable attributes (left):

Application Architecture Practices Coding Practices Application Complexity Documentation Portability Technical & Functional Volume

Code-based analysis

Many of the existing software measures count structural elements of the application that result from parsing the source code for such individual instructions (Park, 1992),tokens (Halstead, 1977), control structures (McCabe, 1976), and objects (Chidamber & Kemerer, 1994).

Software quality measurement is about quantifying to what extent a system or software rates along these dimensions. The analysis can be performed using a qualitative or quantitative approach or a mix of both to provide an aggregate view [using for example weighted average(s) that reflect relative importance between the factors being measured].

This view of software quality on a linear continuum has to be supplemented by the identification of discrete Critical Programming Errors. These vulnerabilities may not fail a test case, but they are the result of bad practices that under specific circumstances can lead to catastrophic outages, performance degradations, security breaches, corrupted data, and myriad other problems (Nygard, 2007) that make a given system de facto unsuitable for use regardless of its rating based on aggregated measurements. A well-known example of vulnerability is the Common Weakness Enumeration (Martin, 2001), a repository of vulnerabilities in the source code that make applications exposed to security breaches.

Reliability The root causes of poor reliability are found in a combination of non- compliance with good architectural and coding practices. This non-compliance can be detected by measuring the static quality attributes of an application. Assessing the static attributes underlying an applications reliability provides an estimate of the level of business risk and the likelihood of potential application failures and defects the application will experience when placed in operation. Assessing reliability requires checks of at least the following software engineering best practices and technical attributes:

Application Architecture Practices Coding Practices Complexity of algorithms Complexity of programming practices Compliance with Object-Oriented and Structured Programming best practices (when applicable) Component or pattern re-use ratio

Dirty programming Error & Exception handling (for all layers - GUI, Logic & Data) Multi-layer design compliance Resource bounds management Software avoids patterns that will lead to unexpected behaviors Software manages data integrity and consistency Transaction complexity level

Efficiency As with Reliability, the causes of performance inefficiency are often found in violations of good architectural and coding practice which can be detected by measuring the static quality attributes of an application. These static attributes predict potential operational performance bottlenecks and future scalability problems, especially for applications requiring high execution speed for handling complex algorithms or huge volumes of data. Assessing performance efficiency requires checking at least the following software engineering best practices and technical attributes:

Application Architecture Practices Appropriate interactions with expensive and/or remote resources Data access performance and data management Memory, network and disk space management Coding Practices Compliance with Object-Oriented and Structured Programming best practices (as appropriate) Compliance with SQL programming best practices

Security Most security vulnerabilities result from poor coding and architectural practices such as SQL injection or cross-site scripting. These are well documented in lists maintained by CWE, and the SEI/Computer Emergency Center (CERT) at Carnegie Mellon University.

Assessing security requires at least checking the following software engineering best practices and technical attributes:

Application Architecture Practices Multi-layer design compliance Security best practices (Input Validation, SQL Injection, Cross-Site Scripting, etc. ) Programming Practices (code level) Error & Exception handling Security best practices (system functions access, access control to programs)

Maintainability Maintainability includes concepts of modularity, understandability, changeability, testability, reusability, and transferability from one development team to another. These do not take the form of critical issues at the code level. Rather, poor maintainability is typically the result of thousands of minor violations with best practices in documentation, complexity avoidance strategy, and basic programming practices that make the difference between clean and easy-to-read code vs. unorganized and difficult-to-read code. Assessing maintainability requires checking the following software engineering best practices and technical attributes:

Application Architecture Practices Architecture, Programs and Code documentation embedded in source code Code readability Complexity level of transactions Complexity of algorithms Complexity of programming practices Compliance with Object-Oriented and Structured Programming best practices (when applicable) Component or pattern re-use ratio Controlled level of dynamic coding

Coupling ratio Dirty programming Documentation Hardware, OS, middleware, software components and database independence Multi-layer design compliance Portability Programming Practices (code level) Reduced duplicated code and functions Source code file organization cleanliness

Identifying critical programming errors Critical Programming Errors are specific architectural and/or coding bad practices that result in the highest, immediate or long term, business disruption risk.

These are quite often technology-related and depend heavily on the context, business objectives and risks. Some may consider respect for naming conventions while others those preparing the ground for a knowledge transfer for example will consider it as absolutely critical. Critical Programming Errors can also be classified per CISQ Characteristics. Basic example below:

Reliability o Avoid software patterns that will lead to unexpected behavior (Uninitialized variable, null pointers, etc.) o Methods, procedures and functions doing Insert, Update, Delete, Create Table or Select must include error management o Multi-thread functions should be made thread safe, for instance servlets or struts action classes must not have instance/non-final static fields Efficiency o Ensure centralization of client requests (incoming and data) to reduce network traffic o Avoid SQL queries that dont use an index against large tables in a loop Security o Avoid fields in servlet classes that are not final static o Avoid data access without including error management o Check control return codes and implement error handling mechanisms o Ensure input validation to avoid cross-site scripting flaws or SQL injections flaws Maintainability o Deep inheritance trees and nesting should be avoided to improve comprehensibility o Modules should be loosely coupled (fanout, intermediaries, ) to avoid propagation of modifications o Enforce homogeneous naming conventions