Pass the Software Certifications Software Certification CSQA Questions and answers with CertsForce

Lack of involvement by management

Management's unwillingness to accept full responsibility for all defects

Failure to determine the cost associated with defects (i.e., poor quality)

Failure to initiate a program to "manage defects"

Lack of emphasis on processes and measurement

Failure to enforce standards

Failure to reward people for following processes

Lack of knowledge about quality

Lack of a quality vocabulary, which makes it difficult to communicate quality problems and objectives

Lack of knowledge of the principles of quality (i.e., what is necessary to make it happen)

No categorization scheme for defects (i.e., naming of defects by type)

No information on the occurrence of defects by type, by frequency, and by location

Unknown defect expectation rates for new products

Defect-prone processes unknown or unidentified

Defect-prone products unknown or unidentified

An economical means for identifying defects unknown

Proven quality solutions are unknown and unused

Organizations choose to adopt a model for any or all of the following reasons:

Satisfy business goals and objectives

If the current infrastructure and processes are not meeting business goals and directives, adopting a model can refocus the IT organization to meet those goals and objectives.

Requirements are imposed by customer(s)

In an effort to improve efficiency and effectiveness, key customers may direct the IT organization to adopt a model.

For competitive reasons

External customers may only do business with an IT organization that is in compliance with a model.

As a guide (roadmap) for continuous improvement

A model usually represents the combined learning of leading organizations, and, as such, provides a roadmap for improvement. This is particularly true of continuous models.

While there is no one best way to develop a security awareness program, the process that follows is an all-inclusive process of the best security awareness training program. This example includes these three steps:

IT management creates a security awareness policy.

Develop the strategy that will be used to implement that policy.

Assign the roles for security and awareness to the appropriate individuals.

Step 1 – Create a Security Awareness Policy

The CIO and/or the IT Director need to establish a security awareness policy. The policy needs to state management’s intension regarding security awareness. Experience has shown that unless senior management actively supports security awareness, there will be a lack of emphasis on security among the staff involved in using information technology and information.

Management support for security awareness begins with the development and distribution of a security awareness policy. Once that policy has been established, management makes security awareness happen through supporting the development of a strategy and tactics for security awareness, appropriately funding those activities, and then becoming personally involved in ensuring the staff knows of management’s support for security awareness.

Step 2 – Develop a Security Awareness Strategy

A successful IT security program consists of: 1) developing an IT security policy that reflects business needs tempered by known risks; 2) informing users of their IT security responsibilities, as documented in the security policy and procedures; and 3) establishing processes for monitoring and reviewing the program.

Security awareness and training should be focused on the organization’s entire user population. Management should set the example for proper IT security behavior within an organization. An awareness program should begin with an effort that can be deployed and implemented in various ways and is aimed at all levels of the organization including senior and executive managers. The effectiveness of this effort will usually determine the effectiveness of the awareness and training program. This is also true for a successful IT security program.

An effective IT security awareness and training program explains proper rules of behavior for the use of an organization’s IT systems and information. The program communicates IT security policies and procedures that need to be followed. This must precede and lay the basis for any sanctions imposed due to noncompliance. Users first should be informed of the expectations. Accountability must be derived from a fully informed, well-trained, and aware workforce.

This step describes the relationship between awareness, training, and education – the awareness training-education continuum. An effective IT security awareness and training program can succeed only if the material used in the program is firmly based on the IT security awareness policy and IT issue-specific policies. If policies are written clearly and concisely, then the awareness and training material – based on the policies – will be built on a firm foundation.

Step 3 – Assign the Roles for Security Awareness

While it is important to have a policy that requires the development and implementation of security and training, it is crucial that IT organizations understand who has responsibility for IT security awareness and training. This step identifies and describes those within an organization that have responsibility for IT security awareness and training.

Some organizations have a mature IT security program, while other organizations may be struggling to achieve basic staffing, funding, and support. The form that an awareness and training program takes can vary greatly from organization to organization. This is due, in part, to the maturity of that program. One way to help ensure that a program matures is to develop and document IT security awareness and training responsibilities for those key positions upon which the success of the program depends.

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.

The quality professional should not allow COTS or contracted software to be placed into operation without some acceptance testing. If the COTS software is acquired by the internet or from a business college its reliability is questionable, and it may contain viruses. Many organizations do not permit their employees to acquire software from unapproved sources such as the internet.

The quality professional may or may not be involved in the actual acceptance testing. However, the quality professional must determine that acceptance criteria are developed. It has been demonstrated extensively that the cost of not acceptance testing is normally much greater than the cost of acceptance testing. It only takes a few problems in acquired software to far exceed the cost of acceptance testing.

Acceptance testing of software will be dependant upon the risk associated with the use of that software. As the use and importance diminishes so does the amount of acceptance testing.

Likewise, the greater assurance the quality professional has in the ability of a contractor of software to produce high quality, defect-free software, the fewer acceptance testing that needs to be conducted.

In this planning process, a response or strategy is developed for each item in the prioritized risk listing. It may include a primary choice and a backup option.

Responses to risk can be categorized in one of three ways:

Accepting the consequences if the event occurs

Active acceptance would involve developing a contingency plan that would be executed if the risk occurs

Passive acceptance would allow the risk event to occur (e.g., making less money if the project is a few weeks late)

Avoiding the consequences by eliminating possibility of the event occurring

Mitigating the risk (reducing it's expected value) by:

Minimizing the probability of occurrence

Minimizing the value of the impact

Deflecting (or transferring) the risk elsewhere (in a software project this might mean passing the risk onto a subcontractor or to the customer).

The objective of this phase is to create an environment in which the use of quantitative data is an accepted component of the management process. The four steps for accomplishing this are:

Define the objectives for the measurement program- how it is to be used. Consider how to implement the four uses of measurement, given the maturity level of the organization. The use of measurement should be tied to the organization’s mission, goals and objectives.

Create an environment receptive to measurement.Begin with the prerequisites listed earlier in this section. Establish service level agreements between IT and the users to define quality and productivity that must be defined before they can be measured. People involved with the measurement should help develop the measure. Establish a quality management environment and ensure the work processes being used have been implemented.

Define the measurement hierarchy, which has three levels of quantitative data: measures, metrics, and a strategic results dashboard (also called key indicators). This measurement hierarchy maps to a three-level IT organizational tier: staff, line management and senior management. IT staff collects basic measures, such as product size, cycle time, or defect count. IT line management uses fundamental metrics, such as variance between actual and budgeted cost, user satisfaction or defect rates per LOC to manage a project or part of the IT function. Senior management uses a strategic results dashboard, where the metrics represent the quantitative data needed to manage the IT function and track to the mission, vision, or goals. For example, a mission with a customer focus should have a customer satisfaction metric. A metric of the number of projects completed on time gives insight into the function's ability to meet short and long-term business goals.

Define the standard units of measurement.

Requirements Tracing is defined as the ability to describe and follow the life of a requirement, in both a forward and backward direction, ideally through the whole systems life cycle. Requirements tracing should capture all levels of requirement engineering. These levels can be defined as the technical, cognitive, and social levels. The technical level can be described as taking the customer’s interests and needs and applying them to the product’s goals, constraints, and outcomes. The cognitive level is developing an understanding between the customer and the supplier on the functionality, non-functionality, and possible side effects of the technical level. Finally, the social level is documenting the technical and cognitive levels in a comprehensive manger.

Requirement traceability is important to the project in many ways.  The CMM covers requirement traceability primarily in Software Configuration Management, but activity 10 of Software Product Engineering states the specific need for consistency and traceability between software work products.  The Requirement Management KPA states the need to manage requirements so they can be easily mapped to a specified requirement in the later steps of the software development life-cycle.  ISO also requires the ability to trace each requirement from the beginning to the end of the development phases. 

Subjective baseline studies will be the most commonly conducted studies in measuring quality and productivity. Subjective means that judgment is applied in making the measure. We noted in the discussion on objective measures that when the individual involved in recording time has the option of applying judgment, then the measure becomes subjective.

Baselines should be quantitative even if it is a subjective measure, but quantitatively subjective. For example, because quality conformance and nonconformance must be defined by people, we are looking for ways to put this information into a quantifiable format. This does not convey a lot of information, but it is indicative of a problem. However, if we develop a five-point scale for unresponsiveness, and ask your dissatisfied customer to complete that scale, we now have conveyed a lot more information. If our scale rates “1” as very poor service, and “5” as very good service, there is a great deal of difference between a “1” rating and a “3” rating for dissatisfaction.

Examples of products/services that can be measured subjectively for developing a baseline include:

Customer satisfaction

Effectiveness of standards/manuals

Helpfulness of methodologies to solve problems

Areas/activities causing the greatest impediments to quality/productivity

Causes for missed schedules/over-budget conditions

Understandability of training materials

Value of tools

Importance of activities/standards/methods/tools to individual activity

Baselines can be conducted for any one of the following three purposes:

Planning: To determine where detailed investigation/survey should be undertaken.

Internal analysis: To identify problems/areas for quality improvement. Once the problem/area has been identified, then no additional effort need be undertaken to formalize the results.

Benchmarking: Comparison against external organizations.

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

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.

Processes should be mapped to mission and goals, to functional units (people), and to deliverables in separate matrices. The following generic process can be used for each mapping:

Create a matrix.

List processes across the top of the matrix.

On the left side of the matrix, list the goals, functional units or roles or deliverables.

Identify the linkages between the rows and columns, as follows:

A process may support multiple goals. Put an X in the intersection to acknowledge a linkage only if the stability or quality of the process could influence meeting goals. If all processes contribute to all goals, decompose the mission and goals further. The resulting Manage-by-Process matrix is a process map.

Processes have primary owners, suppliers and customers. Identify a linkage in this matrix by using “O”, “S” or “C” in the intersection to distinguish between the roles.

Deliverables can be internal such as design specifications, or external such as user manuals. In this matrix indicate the usage of the deliverable by placing a “C”, “R”, “U” and/or “D” in the intersection. “C” is used when the deliverable is created, or the service is provided through the process. “R” indicates the deliverable is referenced or used as input to the process. “U” indicates the deliverable is updated or revised in the process. “D” means the deliverable is deleted, or retired, etc.

For mission and goal mapping, look for gaps where goals are not supported by processes. Consider removing any processes that do not support goals, as they do not add value. Forfunctional unit mapping, look for gaps where units do not have processes. For deliverable mapping, look for gaps where deliverables do not have processes or vice versa.

If the mapping identified any new processes, add them to the inventory.

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.

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.

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.