There is significant research to support the premise that end user satisfaction increases as process maturity increases. End users are dissatisfied for many reasons, which are addressed by process maturity. One is variability, meaning that the service or product they receive one time is significantly different from product received at a later point in time. As shown in the following figure, process maturity levels 2 through 5 greatly reduce this variability. End users are also dissatisfied by high costs and long cycle time, which are both reduced by process maturity. In addition, end users are dissatisfied when the information system does not provide significant value in accomplishing their mission. Levels 3 through 5 have a significant impact on value received from the information areas.

Rahail HDD:Users:iMac:Desktop:Screen Shot 2015-01-12 at 1.00.42 AM.png

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.

LOC is the most common way of quantifying software size; however, this cannot be done until the coding process is complete. Function points have the advantage of being measurable during the design phase of the development process or possibly earlier.

J. Albrecht proposed a metric for software size and the effort required for development that can be determined early in the development process. This approach computes the total function points (FP) value for the project, by totaling the number of external user inputs, inquiries, outputs, and master files, and then applying the following weights: inputs (4), outputs (5), inquiries (4), and master files (10). Each FP contributor can be adjusted within a range of ±35% for a specific project complexity.

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.

Benchmarking involves a comparison of one organization’s, or one part of an organization’s, process for performing a work task to another organization’s process, for the purpose of finding best practices or competitive practices that will help define superior performance of a product, service or support process.

A benchmarking baseline is one determined by another organization. For example, if you wanted to establish a baseline goal for up-time in your computer center, you might want to go to what you believe is a leading organization and use their up-time percentage as your baseline goal.

Nominal Data

This data can be categorized. For example, a program can be classified as database software, operating system, etc. Nominal data cannot be subjected to arithmetic operations of any type, and the values cannot be ranked in any "natural order." The only possible operation is to determine whether something is the same type as something else. Nominal data can be objective or subjective, depending on the rules for classification.

Ordinal Data

This data can be ranked, but differences or ratios between values are not meaningful. For example, programmer experience level may be measured as low, medium, or high. For ordinal data to be used in an objective measurement the criteria for placement in the various categories must be well defined; otherwise, it is subjective.

Interval Data

This data can be ranked and can exhibit meaningful differences between values. Interval data has no absolute zero, and ratios of values are not necessarily meaningful. For example, a program with a complexity value of 6 is four units more complex than a program with a complexity of 2, but it

The quality professional should assure that reports will be issued regularly by the contractor on the software being developed.

A histogram requires some understanding of the data set being measured to consolidate or condense it into a meaningful display. To create a histogram, perform the following steps:

Gather data and organize it from lowest to highest values.

Calculate the range, which is the largest value – smallest value.

Based on the number of observations, determine the number of cells, which is normally between 7 and 13.

Calculate the interval or width of the cells, which is the range divided by number of cells.

Sort the data or observations into their respective cells.

Count the data points of each cell (frequency) to determine the height of the interval, and create a frequency table.

Plot the results.

An evaluator can use the six steps below to assess the climate of a specific organization, group, committee, task force, etc.

1. Look at the organization (group, committee, task force, etc.)

Assess the mission and goals of the organization, what it is supposed to produce, and the overriding principles by which it operates.

2. Examine the jobs

Examine each job in the organization. Ask whether the job is necessary, whether it makes full use of the employee’s capabilities, and whether it is important in accomplishing the mission and goals of the organization.

3. Assess employees’ performance

Evaluate each employee’s performance in relation to the organization’s mission and goals. For each job being performed, ask if the employee is doing what should be done, is using his or her skills effectively, likes his or her job, and has enthusiasm and interest in performing the job.

4. Evaluate how employees feel about their manager or leader

Good organizational climate requires good leadership. Determine whether each employee within the group likes his or her manager, whether they follow or ignore the requests of their manager, and whether they attempt to protect their manager (i.e., make their manager look good).

5. Create a dialog with the members of the group

Interact with each employee asking a series of hypothetical questions to identify the employee's true feelings toward the organization. Questions such as, “do you feel the organization supports your suggestions”, can help draw out the true feelings of each employee.

1. Create Consistency of Purpose in the Company

In quality-oriented companies, quality should be the cornerstone of the corporation. All units within the organization should work toward common goals and purposes. Within IT this can be translated to mean that the training department teaches the standards, operations is working for the same goals as systems programming, and systems programming is dedicated to improving application performance. Assuring quality involves:

Innovating new approaches and allocating resources for long-term planning, such as possible new service, new skills required, training and retraining of personnel, satisfaction of the user.

Putting resources into research, education and maintenance.

2. Institute Modern Aids to Training on the Job

Training must be totally reconstructed. Statistical methods must be used to learn when training is finished, and when further training would be beneficial. A person once hired and trained and in statistical control of his/her own work, whether it be satisfactory or not, can do no better. Further training cannot help. If their work is not satisfactory, move them to another job, and provide better training there.

3. Drive Out Fear

Most people on a job, and even in management positions, do not understand what the job is, or what is right versus wrong. Moreover, it is not clear to them how to find out. Many of them are afraid to ask questions or to report trouble. The economic loss from fear is appalling. It is necessary, for better quality and productivity, that people feel secure.

Another related aspect of fear is the inability to serve the best interest of the company through necessity to satisfy specified rules, or to satisfy a production quota, or to cut costs by some specified amount.

One common result of fear is seen in inspection. An inspector records incorrectly the result of an inspection for fear of overdrawing the quota of allowable defectives of the work force.

4. Look Carefully at Work Standards

Do they take account of quality, or only numbers? Do they help anyone do a better job? How old are they? Work standards are costing as much loss as poor materials and mistakes. In hundreds of companies any day, people stand around the last hour or two waiting for the whistle to blow. They have completed their quotas for the day. Is this good for the competitive position of any industry? Ask these people. They are unhappy doing nothing, and would rather work.

A baseline study is one designed to quantitatively show the current status of an activity, program, or attitude. It both shows “how you are doing” and provides a quantitative base from which change can be measured.

1. Develop a charter.

Determine the responsibilities and activities of the quality function.

2. Identify the quality manager.

Select a quality "fanatic" to head the quality function.

3. Locate organizationally the IT quality function.

Determine to whom the quality leader reports.

4. Build support for quality.

Initiate programs that will encourage both management and staff to support quality processes.

5. Staff and train the quality function.

Determine what is needed to make quality happen, identify and select the people to do it, and provide them with the training they need.

6. Build and deploy the quality toolbox.

Select effective quality tools and implement them throughout the organization.

7. Drive the implementation of the quality management environment.

The quality manager will need to spend a significant amount of time maturing the quality management environment.

Consider questions such as:

How big is the risk?

What exactly is being exposed to the risk?

Can this be considered an acceptable risk?

What alternatives are there?

Will alternatives invoke additional risks?

As it is impossible to be completely certain of the impact or likelihood of many events, these events are estimated using a combination of historical data, knowledge of the event, and experience and judgment. Tools such as simulation, decision trees, or calculating a monetary value are used. Risk can be calculated by structured (associated with data) and unstructured (focus on judgment and experience) methods. Regardless of the method used, two elements must always be considered:

The probability of such an event occurring

The resulting impact if the event occurs

The general principles of a Defect Management Process are as follows:

The primary goal is to prevent defects. Where this is not possible or practical, the goals are to find the defect as quickly as possible and to minimize the impact of the defect.

The defect management process, like the entire software development process, should be risk driven, i.e., strategies, priorities, and resources should be based on an assessment of the risk and the degree to which the expected impact of a risk can be reduced

Defect measurement should be integrated into the development process. Information on defects should be captured at the source as a natural by-product of doing the job. It should not be done after the fact by people unrelated to the project or system.

As much as possible, the capture and analysis of the information should be automated. The QA analyst should look for trends and perform a root-cause analysis to identify special and common cause problems.

Defect information should be used to improve the process. As imperfect or flawed processes cause most defects, processes may need to be altered to prevent defects.

The steps below describe a sample defect tracking process. Depending on the size of the project or project team, this process may be substantially more complex.

1. Execute test and log any discrepancies.

The tester executes the test and compares the actual results to the documented expected results. If a discrepancy exists, the discrepancy is logged as a “defect” with a status of “open.” Supplementary documentation, such as screen prints or program traces, is attached if available.

2. Determine if discrepancy is a defect.

The Test Manager or tester reviews the defect log with an appropriate member of the development team to determine if the discrepancy is truly a defect, and is repeatable. If it is not adefect, or repeatable, the log should be closed with an explanatory comment.

3. Assign defect to developer.

If a defect exists it is assigned to a developer for correction. This may be handled automatically by the tool, or may be determined as a result of the discussion in step 2.

4. Defect resolution process.

When the developer has acknowledged the defect is valid, the resolution process begins.

The Check process incorporates the process controls needed to be assured the “Do process” was performed correctly. Process control identifies the appropriate types of quality controls needed within a process, and designs and incorporates them as Check procedures into the process. Check procedures describe how to evaluate whether the right work was done (output meets needs) and whether the work was done right (output meets standards). Controls should be designed based on the criticality of the process and what needs to be checked.

Check procedures are defined in the same way as Do procedures. If the playscript format is used, Check procedures should be incorporated to the taskflow diagram or flowchart at the appropriate spot. For example, a quality control checklist associated with programming would have questions such as, "Was a flowchart produced that describes the processing of the program?" or “How much quality control is enough?”

The challenge is to install the appropriate amount and types of controls to minimize cost, effort, and cycle time; and to minimize the risk that defects will go undetected and "leak" into other processes.

There are three COQ categories:

Prevention- Money required preventing errors and to do the job right the first time is considered prevention cost. This category includes money spent on establishing methods and procedures, training workers and planning for quality. Prevention money is all spent before the product is actually built.

Appraisal– Appraisal costs cover money spent to review completed products against requirements. Appraisal includes the cost of inspections, testing and reviews. This money is spent after the product or subcomponents are built but before it is shipped to the user.

Failure– Failure costs are all costs associated with defective products. Some failure costs involve repairing products to make them meet requirements. Others are costs generated by failures, such as the cost of operating faulty products, damage incurred by using them and the costs incurred because the product is not available. The user or customer of the organization may also experience failure costs.

The following figure shows a few examples of the three costs of quality that illustrate the types of activities in each of the categories. Experience has shown that a small group of knowledgeable people can develop estimates for the COQ categories. The estimate does not have to be highly precise because the amounts will be so large that even errors of plus or minus 50% would not affect identifying the actions that need to be taken to reduce the COQ.

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