Free Practice Questions for Software Certifications CSQA Exam

The plan will be outlined in four steps. Those four steps are:

-Creating Messages

- Understanding Audiences

-Planning Transfer Methods

- Defining Impacts.

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 Test Manager ensures that testing is performed, that it is documented, and that testing techniques are established and developed. The manager is also responsible for:

Planning and estimating tests

Designing the test strategy

Ensuring tests are created and executed in a timely and productive manner

Quality is a multifaceted concept driven by customer requirements. The level of quality can vary significantly from project to project and between organizations. In IT, the attributes of quality are examined in order to understand the components of quality, and as a basis for measuring quality. Some of the commonly accepted quality attributes for an information system are described in the following figure.

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

Static testing is another name for in-process reviewing. It means that the test is being performed without executing the code. Static testing occurs throughout the development life cycle; however, a large part of it takes place during the requirements and design phases in the form of walkthrough inspections, and system reviews. Other examples of static testing include code analyzers or writing analyzers.

There are two types of static tests:

Validation

Validation is testing the software in an operational state. While there are several iterations of testing, they do not occur until the latter part of the system development life cycle. Thus, validation does not take advantage of the control theory stating that the control should be placed as close as possible to where the defect occurs. The most common types of validation are unit testing, integration testing, and system testing. Unit testing tests the smallest operating module ofa system; integration testing tests the connecting logic between the modules/units; and the systemtesting validates that the system executes in the organization's operating environment.

Verification

Verification is the static testing of the system in a nonoperational status. It primarily tests the documentation produced by the project team. The documentation includes requirements, design, code, test, and operating documentation. Verification is performed through a variety of processes, including code analyzers, walkthroughs, reviews, and inspections. These verification processes also interact with the project team, end users, and other interested parties. Level 2 also incorporates acceptance testing, in which the end users define the criteria, which the system must meet in order to, be acceptable, and then test against those criteria.

Generally, a SLA should contain clauses that define a specified level of service, support options, incentive awards for service levels exceeded and/or penalty provisions for services not provided. Before having such agreements with customers the IT services need to have a good quality of these services, Quality management (link is external) will try to improve the Quality of service (link is external), whereas the SLAs will try to keep the quality and guarantee the quality to the customer.

Typical Service Level Agreement Contents:

Services Delivered

Performance

Problem Management

Customer Duties

Warranties & Remedies

Security

Disaster Recovery

Termination

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.

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

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. 

Several procedures are necessary to maintain control over program changes.

The nature of the proposed change should be explained in writing, and formally approved by a responsible individual. Major changes should be approved by the systems-planning steering committee, commonly called the CCB or Configuration Control Board, in the same manner as for new systems. Minor changes may only require the joint approval of the IT manager and senior personnel in the user department. Documenting the proposed change clears up any initial misunderstandings that may arise when only verbal requests are made. In addition, written proposals provide a history of changes in a particular system.

Developers should make the program changes, not the operations group. Any change should be supported by adequate systems documentation. If the operators were authorized to make minor changes, it would greatly increase the difficulty of controlling versions and of maintaining up-to-date documentation.

Someone independent of the person who designed and made the change should be responsible for testing the final revised program. The results should be recorded on program change registers and sent to the IT manager for approval. Operations should accept only properly approved changes.

Finally, the documentation system should be updated with all change sheets or change registers and printouts.

The use of teams is critical in a quality management environment. As a result, understanding the team life cycle is important in order to set proper expectations for the team and to help it communicate and function effectively. Teams go through four phases:

Forming

In this first stage, teams are dominated by feelings of confusion and anxiety, and are not able to focus on their purpose for long. Individuals may come to the team proud to be selected, but wondering why, and wondering about the other members. Information will be solicited and shared, and hidden agendas add to the uncertainty. Key accomplishments of this phase are identifying roles for team members, clarifying responsibilities and accepted behavior, and defining the team's purpose.

Storming

Conflict, defensiveness, and competition are key during this stage. Team members still think individually and wrestle with loyalties outside the team. As ideas emerge, they are attacked and defended. There may be confrontations, disagreements, and fluctuating attitudes over the likelihood of achieving the team's purpose. Barriers will be examined and the team will focus on well-known observations and common beliefs. Some people will not participate to prevent unfavorable responses, and others will test the leader's authority and form cliques.

Norming

In this stage the individuals start to become a team. Personal agendas, concerns, and loyalties are minimized. People are discussed less often than the issues, conflicts are resolved constructively, and the team focuses on its real purpose. As trust develops, riskier ideas are proposed andfeelings exchanged. The willingness to discuss for the sake of the team grows, which results in better communication and cooperation.

Conforming

During this final stage, the team has matured into a cohesive unit. Individual strengths and weaknesses are understood and appreciated, leading to an overall satisfaction with the team membership. As steps are made toward the team's goals, there is individual learning and growth, and people feel satisfied with progress.

Common Causes of Variation

All processes contain some inherent variation, or common causes of variation. The amount of variation in a process is quantified with summary statistics (the mean and standard deviation).

A process is defined as stable when its mean and standard deviation remain constant over time. Processes containing only common causes of variation are considered stable. As a stable process is predictable, future process values can be predicted within the control limits with a certain amount of belief. A stable process is said to be in a state of statistical control.

One researcher1 provides the following thoughts on common causes of variation:

"Process inputs and conditions that regularly contribute to the variability of process outputs.”

“Common causes contribute to output variability because they themselves vary.”

Special Causes of Variation

Special causes of variation are not present in a process. They occur because of special or unique circumstances. In the IT example of abnormal terminations in a computer operation, special causes might include operator strikes, citywide power outages, or earthquakes.

If special causes of variation exist, the process may be unpredictable, and therefore unstable. A state of statistical control is established when all special causes of variation have been eliminated (the operator strike ends, citywide power returns or business returns to normal operations after an earthquake).

Brian Joiner summarized special causes of variation as follows:

"Process inputs and conditions that sporadically contribute to the variability of process outputs.”

“Special causes contribute to output variability because they themselves vary.”

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 concerns that need to be addressed during contract negotiations include the following factors.

Warranty

The guarantees provided by the contractor that the deliverables will meet the specifications. This segment of the contract should state specifically what the contractor warrants, and what the contractor will do if the deliverables fail to meet the warranty guarantees. For example, if the contractor guarantees the application will provide a one-second response, and the implemented application fails to meet those specifications, this contract defines recourse against the contractor.

Installation

The contractor’s and customer’s commitment for installing the application should be specified. If the contractor is to have personnel present to help during the installation, that should be specified. If the contractor is to provide machine time on certain days, that, too, should be specified in the contract.

Penalties

Penalties assessed in the event of failure on the part of either the contractor or the customer to meet contractual obligations should be covered in the contract. Where dollar penalties are to be assessed, the amount should be specified in the contract. For example, if the contractor is late in delivering the product, a per-day dollar penalty can be assessed, as well as a dollar penalty for failure of the customer to make computer time available, etc.

Service discontinuance

If the contractor decides to discontinue service on the application system, the customer’s rights in those instances should be specified. For example, if any of the training material or application system is copyrighted then those copyrights should be passed to the customer in the event that service on the purchased products is discontinued.

When addressing security issues, some general information security principles should be kept in mind, as follows:

Simplicity

Security mechanisms (and information systems in general) should be as simple as possible. Complexity is at the root of many security issues.

Fail Safe

If a failure occurs, the system should fail in a secure manner. That is, if a failure occurs, security should still be enforced. It is better to lose functionality than lose security.

Complete Mediation

Rather than providing direct access to information, mediators that enforce access policy should be employed. Common examples include file system permissions, web proxies and mail gateways.

Open Design

System security should not depend on the secrecy of the implementation or its components. “Security through obscurity” does not work.

Separation of Privilege

Functions, to the degree possible, should be separate and provide as much granularity as possible. The concept can apply to both systems and operators and users. In the case of system operators and users, roles should be as separate as possible. For example, if resources allow, the role of system administrator should be separate from that of the security administrator.