Software Certifications CSQA - CSQA Certified Software Quality Analyst

Target Audience

The target audience for ISO/IEC 12207 is:

Organizations acquiring a system that contains software or a stand-alone software product

Organizations that supply software products

Organizations involved in software operation or software maintenance

The standard is especially applicable for acquisitions, as it recognizes the distinct roles of acquirer and supplier. Its intended use is for the two parties of an agreement or contract that defines the development, maintenance, or operation of software. It does not apply to the purchase of commercial off-the-shelf software products. It is also intended for use with trained, experienced developers, managers, and acquirers of software.

Views of Software Development

Given the target audience, ISO/IEC 12207 includes several different points of view regarding software development:

Acquirers and suppliers see a contract view, which includes the acquisition and supply processes and begins with a contractual relationship to supply software. Depending on the contract, the supply process may use the development process to create new software, the operation process to provide software operation services, or the maintenance process to repair or improve the software.

Operators see an operating view, which includes the operations process. The operations process may use the maintenance process.

Developers and maintainers see the engineering view, which includes the maintenance and development processes. The maintenance process may also use the development process.

The employer of supporting processes sees the supporting view, which includes the eight supporting processes.

Managers see the corporate view, which includes the four organizational processes.

If the application system is interconnected with applications and/or other software from different contractors, that interrelationship should be specified. It is important to state in the contract that has primary responsibility for tracing and correcting errors. In a multi-contractor environment, when no contractor accepts primary responsibility for error tracking, the customer may need to expend large amounts of funds to trace errors because of the unwillingness of contractors to accept this responsibility.

The dynamic nature of most business activities causes software or system changes. Changes require well-formulated and well-documented procedures to prevent the manipulation of programs for unauthorized purposes. The primary objective of configuration management (or change control) is to get the right change installed at the right time. Change control concerns should be identified so that proper control mechanisms can be established to deal with the concerns.

Some key points regarding changes include:

Each release of software, documentation, database, etc., should have a unique version number. Changes should be incorporated through new versions of the program. There should be a process for moving versions in and out of production on prescribed dates.

Procedures should exist for maintaining the production and source libraries. They should address when to add to the library and when prior versions should be deleted. Care should be taken to regularly review libraries for obsolete programs, as large libraries can negatively impact operations performance.

Project documentation such as requirements specifications, design documents, test plans, standards, procedures, and guidelines should also be identified with version numbers and kept under version control to ensure the project team is working with the latest, approved documents.

Automatic

When performing a Do procedure, automation is the only way to force compliance. Some tools, such as CASE tools, automatically enforce task completion and sequence, and deliverable standards.

Self-Checking

This is when the process owner (author) uses a method other than the Do procedure, to crosscheck his/her work. Methods in this category are:

Analysis tools, which parse and analyze deliverables after they have been created, such as spelling checkers, writing analyzers, and code analyzers (e.g., standards compliance, complexity analyzers, and cross-reference tools).

Checklists, which are worksheets containing a list of questions oriented towards determining whether the standards have been adhered to. They are designed to provide a summary-style self-check for the author. Checklists often mirror policies, standards, and procedures, but address each compliance issue in the form of a question. A "yes" answer means that the author has followed the process and has produced a result that matches the intent of the policy statement. A "no" answer indicates noncompliance.

Desk-checks, where the author or owner reviews the product against specifications and standards. It is uncontrolled and subject to the time requirements of each individual.

One-on-one reviews, which are informal reviews conducted between the author/owner and one other person. The objective is to review against specifications and standards.

Tests, which validate that the actual results are the expected or desired results.

Peer Reviews

One or more process owners review the results of the author. Typically, quality problems are noted, and the author corrects them. Various methods exist, from informal to formal.

Supervisory

The author’s supervisor reviews the work and ensures that defects found are corrected. This is problematic because it takes responsibility for quality away from the worker, and may beineffective because the supervisor is not sufficiently skilled or knowledgeable about the work to make intent or judgment calls regarding compliance. It may also influence the supervisor unfairly regarding a worker’s performance. Supervisors may use the informal walkthrough, checklists, or testing for control methods.

Third Party

An independent group evaluates the product. As with supervisory controls, this is problematic because responsibility for quality is taken from the worker and the third party may not have the skills or knowledge about the work to determine compliance. Examples of independent groups are quality functions and independent test teams. Methods used by third parties include informal walkthroughs, checklists, testing, analysis tools, and sampling.

Preventive controls are located throughout the entire IT system. Many of these controls are executed prior to the data entering the computer programs. Following are three of the 8 preventive controls:

Source-data authorization- Once data has been recorded properly, there should be control techniques to ensure that the source data has been authorized. Typically, authorization should be given for source data such as credit terms, prices, discounts, commission rates, overtime hours, and so forth.

Data input -Data input is the process of converting data in non-machine-readable form (such as hard-copy source documents) into a machine-readable form so that the computer can update files with the transactions. Since the data input process is typically a manual operation, control is needed to ensure that the data input has been performed accurately.

Source-data preparation -In many automated systems, conventional source documents are still used and, therefore, no new control problems are presented prior to the conversion of source documents into machine-readable form. Specially designed forms promote the accuracy of the initial recording of the data. A pre-audit of the source documents by knowledgeable personnel to detect misspellings, invalid codes, unreasonable amounts, and other improper data helps to promote the accuracy of input preparation.

There is a high correlation between process maturity and cycle time. As shown in the figure below, as processes mature, there is a decrease in the cycle time to build software products. The maturity of processes, people, and controls has associated with it a search for the root cause of problems. It is these problems that lead to rework which, in turn, extends the cycle time. Thus, improvements also focus on facilitating transitions of deliverables from work task to work task, which also significantly reduces cycle time.

Rahail HDD:Users:iMac:Desktop:Screen Shot 2015-01-12 at 12.47.42 PM.png

A code review is a special kind of inspection in which the team examines a sample of code and fixes any defects in it. In a code review, a defect is a block of code which does not properly implement its requirements, which does not function as the programmer intended, or which is not incorrect but could be improved (for example, it could be made more readable or its performance could be improved). In addition to helping teams find and fix bugs, code reviews are useful for both cross-training programmers on the code being reviewed and for helping junior developers learn new programming techniques.

This technique consists of developing test cases and data that focus on the input and output boundaries of a given function. In the credit limit example, boundary analysis would test the:

Low boundary plus or minus one ($9,999 and $10,001)

Boundaries ($10,000 and $15,000)

Upper boundary plus or minus one ($14,999 and $15,001)

Joiner outlined this strategy for reducing common causes of variation:

"Talk to lots of people including local employees, other managers, and staff from various functions.”

“Improve the measurement processes if measuring contributes too much to the observed variation.”

“Identify and rank categories of problems by Pareto analysis.”

1 - Baselining is defining the current level of performance. For example, the number of defects currently contained in a thousand lines of code is usually calculated quantitatively and can be used to measure improvement.

2 – Develop a clearly defined baseline in your organization - This means that all of the attributes involved in your baseline are defined. In our example of defects per lines of code, clearly defining what is meant by defect and a line of code would meet the objective of this step.

3 - Process Benchmarking - This benchmark is used to plan for business process improvement, and is documented as part of business plans and quality improvement projects.