CSQA Sample Questions Answers

Experience has shown that over 50% of the software developed by offshore organizations fails to meet the expectations of the contractor. Since many of the decisions to have software developed offshore are economic decisions, the differences associated with having the software developed offshore negate the economic advantages in many cases. These offshore differences are:

Cultural differences

There may be a significant difference in the culture and values between the contractor and the offshore organization.

Communication barriers

The language of the offshore organization may be different or difficult to comprehend which causes difficulty in communicating the needs and desires of the contractor.

Loss of employee morale and support

Employees who would like to have developed the software may resent the software being developed offshore and thus make it difficult for the offshore developed software to be successful.

Root cause of the contractor IT organization not addressed

Frequently, offshoring is chosen because there are problems in the contractor organization that executives do not want to address. For example, the problems might include a lack of training for the employees in the contractor organization or other perhaps better options for software development were not explored

While the software may be developed by an outside organization, the responsibility for quality of that software cannot be contracted. The contractor is still responsible for the quality of the organization. There must be a process to monitor the development and validate the correct functioning of the software when it is developed by an outside organization.

The quality professional is the individual who should accept the quality responsibility for software developed by an outside organization. This may mean that the quality professional needs to visit periodically or during the entire developmental period of the software to ensure the quality. Many of the same practices used to assure quality of in-house developed software are applicable to software developed by outside organizations. For example, conducting reviews at specific checkpoints should occur on contracted software. Acceptance testing should be conducted on all software regardless of how developed.

The quality professional’s specific responsibility for software developed by outside organizations is to assure that the process for selecting COTS software and contracting with an outside organization for software are adequate.

One of the major responsibilities of the quality assurance activity is to oversee the development and deployment of work processes, and then to assure that those work processes are continuously improved.

Without a process for selecting COTS software and a process for contracting for software those processes would be subject to great variability. One contract may work well, one acquisition of COTS software may work well, while other acquisitions may result in a failure.

The four project variables are scope, schedule, resources, and quality. The management challenge in completing the project can be illustrated as a dashboard of four system attribute dials, which get set according to the project criteria as illustrated in the following figure. The four dials are interconnected, so movement of one dial affects one or more of the other dials.

Rahail HDD:Users:iMac:Desktop:Screen Shot 2015-01-13 at 3.12.48 AM.png

All goes well until one of the variables needs to be changed. For example, the project team agrees to install a new requirement, but if management holds schedule and resources firm while moving the scope, something must give. Since the dials are interconnected, what must give is quality. Reduced quality occurs as less testing, less documentation, or fewer controls. One role of the quality function is to hold the quality dial firm, so that scope changes cause the resources orschedule dials to move, and not cause a reduction in quality.

The maturation of the quality management system can be divided into three phases:

Initial Phase

The initiation point of the quality management system can be considered the formalization of quality control activities. An organization in this phase is results-driven, focusing on defining and controlling product quality. It normally takes at least two years in this phase of maturity for management and staff to recognize that quality cannot be tested into a product; it must happen through process maturity.

Intermediate Phase

In this phase an organization's objectives move from control to assurance. The emphasis is on defining, stabilizing, measuring, and improving work processes. While process improvement occurs before and after this phase, it is during this phase that resources are allocated to make process maturity happen. It takes between two and four years for significant process maturity. At this level products and services achieve consistency in product quality (consistency being the prerequisite to improved quality and productivity).

Final Phase

During this phase, objectives such as consulting, motivating, and benchmarking move the organization toward optimization. The MBNQA program defines such an organization as a “world-class” organization. World-class begins when work and management processes are well defined, are being continually improved, and are producing high-quality results that yield high customer satisfaction. These processes are integrated to obtain maximum customer satisfaction at minimum cost.

Inspection involves a step-by-step reading of the product, with each step checked against a predetermined list of criteria. These criteria include checks for historically common errors. Guidance for developing the test criteria can be found elsewhere. The developer is usually required to narrate the reading product. The developer finds many errors just by the simple act ofreading aloud. Others, of course, are determined because of the discussion with team members and by applying the test criteria.

At the problem definition stage, inspections can be used to determine if the requirements satisfy the testability and adequacy measures as applicable to this stage in the development. If formal requirements are developed, formal methods, such as correctness techniques, may be applied to ensure adherence with the quality factors.

Inspections should be performed at the preliminary and detailed design stages. Design inspections will be performed for each module and module interface. Adequacy and testability of the module interfaces are very important. Any changes that result from these analyses will cause at least a partial repetition of the verification at both stages and between the stages. A reexamination of the problem definition and requirements may also be required.

Finally, the inspection procedures should be performed on the code produced during the construction stage. Each module should be analyzed separately and as integrated parts of the finished software.

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.

From a management perspective, processes are needed to:

Explain to workers how to perform work tasks

Transfer knowledge from more experienced to less experienced workers

Assure predictability of work activities so that approximately the same deliverables will be produced with the same resources each time the process is followed

Establish a basic set of work tasks that can be continuously improved

Provide a means for involving workers in improving quality, productivity, and customer satisfaction by having workers define and improve their own work processes

Free management from their activities associated with "expediting work products" to spend more time on activities such as planning, and customer and vendor interaction

From a worker perspective, work processes are important to:

Increase the probability that the deliverables produced will be the desired deliverables

Put workers in charge of their own destiny because they know the standards by which their work products will be evaluated

Enable workers to devote their creativity to improving the business instead of having to develop work processes to build products

Enable workers to better plan their workday because of the predictability resulting from work processes

If a planning process exists, management should require compliance to that process.

Some guidelines for selecting and sequencing change approaches are:

Select approaches that are most acceptable to the culture (poor approaches that are acceptable may be more effective than optimal approaches that are resisted).

Select approaches that have the highest probability of success, first.

Select approaches that will provide both short-term and long-term results. Select an implementation strategy that will use the best people and the best projects, as opposed to trying to improve the poorest projects with the least effective staff.

Implement the prerequisites to the approach before implementing the approach.

Use tools such as risk ranking, analysis, or return on investment.

In business and accounting literature, the environment is referred to in many different ways. In accounting literature it is sometimes called the “control environment,” other times the “management environment,” and sometimes just the environment in which work is performed.

For the purpose of this skill category, we will refer to it as the “quality environment.” What is important to understand is that the environment significantly impacts the employee’s attitude about complying with policies and procedures. For example, if IT management conveys that they do not believe that following the system development methodology is important, project personnel most likely will not follow that system development methodology. Likewise, if IT management conveys a lack of concern over security, employees will be lax in protecting their passwords and securing confidential information.

Quality Council

A Quality Council is composed of the organization’s top executive and his or her direct reports. It may also be referred to as an Executive Council. The Quality Council acts as the steering group to develop the organization’s mission, vision, goals, values, and quality policy. These serve as critical input to process mapping, planning, measurement, etc. Some large companies opt for more than one level of Quality Council. When multiple levels exist, each organization’s mission and vision tie into that specified by the top council.

Management Committees

Management committees (also called Process Management Committees) are composed of middle managers and/or key staff personnel, and are responsible for deploying quality management practices throughout the organization. One or more committees may be needed depending on the organization’s size and functional diversity. Committees should represent all the skills and functions needed to work on the specific processes or activities.

Teams and Work Groups

Teams are formed under any number of names depending on their purpose. Common names and functions are:

Process Development Teams develop processes, standards, etc.

Process Improvement Teams improve existing processes, standards, etc.

Work Groups perform specific tasks such as JAD, inspection, or testing.

The process teams are composed of a representative group of process owners. Members of work groups will vary depending on the purpose, but suppliers and customers are likely to participateas team members or as reviewers. It may also be desirable for a QA analyst to participate on the team.

Process teams use standard approaches (such as flowcharts, checklists, Pareto analysis) to define, study, and improve processes, standards, procedures, and quality control methods. They may pilot new or revised processes help deploy them to the rest of the organization, and provide process training. They may also serve as process consultants to process owners and others using the process. Approaches and tools used by the team depend on its purpose.

Task 1:Select awareness topic. The topic is usually a problem or a new approach to doing work, and is normally related to accomplishing the organization’s mission. Sample topics include the number-one cause of operational problems, or a new work approach, such as implementing quality principles in the IT group.

Task 2: Identify the topic's customers. Individuals with a vested interest in the topic need to have the awareness training. These are the people who will benefit from or be adversely affected by the topic. For example, for software inspections, customers would be the individuals whose products are being inspected as well as those performing the inspection. Customers could also include users of those products because inspections affect delivery date and quality.

Task 3: Define objectives for awareness training. The objectives relate to the action that is initiated as part of the awareness training, indicating the outcome or results to be accomplished relating to the topic. In the topic of software inspections, the objective may be to initiate software inspections in the systems development process. The training would focus on accomplishing those objectives.

Task 4: Define customer benefits. Defining and selling the benefits to the customer is an important part of the training. To define the benefits, identify each category of customer, and then determine what benefits that customer would receive if the training objectives were accomplished. Some benefits will be negative, in which case the training must be supportive of that loss of benefit.

Task 5: Develop administrative training plan. A plan needs to be developed for conducting the training. The plan contains information related to the awareness topic as well as general administrative activities.

Administrative activities to consider when planning awareness training are: identifying attendees (limit sessions to 25 people), inviting attendees (homogenous groups work best), arranging a training room and equipment, preparing an agenda (limit training to 2 hours maximum), arranging handout materials, soliciting a high-ranking person (i.e., champion) to introduce the topic, and assigning training responsibilities.

A post-implementation audit is conducted to determine any, or all, of the following:

The system objectives were met

The system specifications were implemented as specified

The developmental standards were followed

The IT quality objectives (e.g., maintainability) were achieved

Post-implementation audits are a quality assurance activity. The post-implementation audit is used to assess the ability of the IT organization to perform effective and efficient work. The results of the audit will be used to both improve the software system and to improve the process that builds software systems.

Level 1 -- Product Focus

In this process category, management's focus is on products. The product focus emphasizes management by objective; specifically meeting schedules, managing people and jobs, and using test and control to determine whether those objectives have been met. At this level, status reports, budgets, checkpoints, and meetings are an important component of how management executes their management function.

Level 2 -- Process Focus

Management's emphasis is to bring discipline to their organization through definition and compliance to processes. The processes are usually an accumulation of the best practices currently in use within the information activity. Management creates an environment for discipline by establishing a quality infrastructure, usually a quality council or committee with several lower-level committees such as a standards or process management committee. At this level, management begins quality planning, conducts end user surveys, encourages employees to make suggestions and recommendations for improvement, and changes the methods by which projects are managed to a more scientific method using process management tools with emphasis on managing the process.

Level 3 -- End User Focus

At this level, management is truly able to focus on the end user. This level is achieved by building a competency-based organization. Management has focused the resources of the organization to meeting its mission/objectives. The practices common at this phase are process management practices based on competency, quality incentives based on competency, and end user feedback systems that impact the establishment of competencies. This level formalizes the use of statistical tools in evaluating processes, and formalizes staff’s process improvement teams.

Level 4 -- Team Focus

The emphasis at this level is moving from committees directed and controlled by management to teams empowered to take action on their own. Turning over the day-to-day operation of the team is possible because the quantitative data initiated at Level 4 enables management to manage byfact as opposed to managing people and jobs. The management practices common at this level include team building, team rewards, cross-functional teams, employee surveys, and the widespread use of management tools by the teams.

Level 5 – World-Class Focus

The teams become truly self-directed and motivated through sharing in the gains made by the organization. Management practices now include benchmarking and advanced statistical tools such as quality function deployment.

There are four major uses of quantitative data (i.e., measurement):

1. Manage and control the process.

A process is a series of tasks performed to produce deliverables or products. IT processes usually combine a skilled analyst with the tasks defined in the process. In addition, each time a process is executed it normally produces a different product or service from what was built by the same process at another time. For example, the same software development process may be followed to produce two different applications. Management may need to adapt the process for each product or service built, and needs to know that when performed, the process will produce the desired product or service.

2. Manage and control the product.

Quality is an attribute of a product. Quality level must be controlled from the start of the process through the conclusion of the process. Control requires assuring that the specified requirements are implemented, and that the delivered product is what the customer expects and needs.

3. Improve the process.

The most effective method for improving quality and productivity is to improve the processes. Improved processes have a multiplier effect because everyone that uses the improved process gains from the improvement. Quantitative data gathered during process execution can identify process weaknesses, and, therefore, opportunities for improvement.

. Manage the risks.

Risk is the opportunity for something to go wrong - for example, newly purchased software will not work as stated, projects will be delivered late, or workers assigned to a project do not possess the skills needed to successfully complete it. Management needs to understand each risk, know the probability of the risk occurring, know the potential consequences if the risk occurs, and understand the probability of success based upon different management actions.

Brainstorming

Brainstorming is a technique used to quickly generate a quantity of creative or original ideas on or about a process, problem, product, or service. Brainstorming can be used to:

Develop a vision

Review inputs, outputs, and flows of existing processes

Create a list of products or services

Eliminate wasteful and redundant work activities

Reengineer a process, product, or service

Design a new or improved process

Establish standards, guidelines, or measures

Identify the internal and external customers served

Improve the work environment

Gather data for use with other tools

Affinity Diagram

The affinity diagram is an orderly extension of a structured brainstorming session. Teams use this tool to help create order out of chaos, by categorizing large numbers of ideas. Rather than having teams react logically to a group of ideas, this technique helps to identify more creative solutions or to structure ideas for a cause-and-effect diagram.

Nominal Group Technique

The nominal group technique is a structured, facilitated technique where all team members participate by individually ranking ideas, issues, concerns, and solutions, and then achieve consensus by combining the individual rankings.

Cause-and-Effect Diagram

Teams use cause-and-effect diagrams to visualize, clarify, link, identify, and classify possible causes of problems in processes, products, and services. They are also referred to as "fishbone diagrams," “why-why diagrams,” or "Ishikawa diagrams" (after Kaoru Ishikawa, a quality expert from Japan).