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

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.

1 – The major advantages are”

Relinquishment of control -The software is developed by individuals who are not employees of the organization,and thus it is difficult to oversee the development process. The contractingorganization cannot direct the employees of the other organization, nor have controlover the many day-to-day decisions that are made in developing software.

Loss of control over reallocation of resources -If work needs to be done to correct problems and/or speed up development, thecontractor cannot take workers off one project and assign them to another project.

2 – The major disadvantages are:

Cultural differences -There may be a significant difference in the culture and values between the contractorand the offshore organization.

Communication barriers -The language of the offshore organization may be different or difficult to comprehendwhich causes difficulty in communicating the needs and desires of the contractor.

If an organization is not ready, and also lacks the sales skills to convince the management group, the probability of success is so low that it is best not to bother with implementation at this time. A ready organization with good salesmanship can take care of itself. The other scenarios present different challenges. Organizations that are not ready, but have the salesmanship, are referred to as

“Challenge 1.” Organizations that are ready, but lack the salesmanship, are referred to as

“Challenge 2.” Each challenge is analyzed separately.

Challenge 1

The solution is to get ready. To get ready, an organization needs the following:

The presence of a competent, trained staff that is capable of performing quality work when building and maintaining systems. Additionally, there must be backup for these individuals. In a moderate-size organization, quality initiatives might be assigned to one person. With the substantial effort to get it going, it can be traumatic if that individual becomes promoted or should leave.

A good IT management team that is capable of setting up the quality function, monitoring it, and making it work. The existence of good management tools, especially project management and systems development methodologies that spell out what to do when,and are specific about where the quality review functions belong in the development cycle and in maintenance.

A limit on the number of internal improvement projects to be done at once.

Good credibility. If there has been a history of not doing things that were promised it may be premature to initiate a quality function until a track record of satisfying promises has been accomplished.

To be mentally prepared for the length of time (measured in months and years, not weeks) to get a new and important function like this into operation and stabilized.

Challenge 2

The process of selling a new quality function is similar to the process of selling anything associated with internally improving an organization. Some items to consider include the following:

To be an issue of real value to the total organization, the quality function must be heartfelt to the salesperson. Without a very strong belief in quality, no one can sell it.

When the proposition is taken to the management group, it is essential for the salesperson to speak the language of the listener.

Management values their time, which places a burden on the presenter to think the proposition through, present the case, ask for a clear decision, and then leave the room when receiving an affirmative answer. Most executive managers will buy into any well thought-out plan that has the necessary controls built in and where they can conceptually see the logic of how the pieces fit together.

It is essential to present a realistic picture. Extreme benefits should not be promised, nor should the salesperson claim that problems could be solved in a very short period of time. Most executive managers are astute enough to see through the unrealistic claims rapidly, weakening the total case.

There is an important principle of getting some things accepted, which is referred to as the Mafia Rule. This is an offer that management can't refuse. Offer that the management group can make all of the decisions on quality issues, while the proponents of the quality function will handle the administrative details.

Ideas are typically accepted only after the person presenting the ideas is accepted. If the salesperson’s personal relationship with management is weak, some "fencemending" should be done before asking management for a major decision.

Using outsiders can sometimes help in getting the right decision. The simple process of paying for advice somehow makes that advice seem more important.

Size

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.

Lines of Code

This is probably the most widely used measure for program size, although there are many different definitions. The differences involve treatment of blank lines, comment lines, nonexecutable statements, multiple statements per line, multiple lines per statement, and the question of how to count reused lines of code. The most common definition counts any line that is not a blank or a comment, regardless of the number of statements per line. In theory, LOC is a useful predictor of program complexity, total development effort, and programmer performance (debugging, productivity). Numerous studies have attempted to validate these relationships.

Function Points

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.

Complexity

More metrics have been proposed for measuring program complexity than for any other program characteristic. Two examples of complexity metrics are:

Cyclomatic Complexity -- v(G)

Given any computer program, draw its control flow graph, G, where each node corresponds to a block of sequential code and each edge corresponds to a branch or decision point in the program. The cyclomatic complexity of such a graph can be computed by a simple formula from graph theory, as v(G)=e-n+2, where e is the number of edges, and n is the number of nodes in the graph.

Knots

Calculate program knots by drawing the program control flow graph with a node for every statement or block of sequential statements. A knot is defined as a necessary crossing of directional lines in the graph. The same phenomenon can be observed by drawing transfer-of control lines from statement to statement in a program listing

The most important prerequisite for successful implementation of any major quality initiative is commitment from executive management. It is management’s responsibility to establish strategic objectives and build an infrastructure that is strategically aligned to those objectives. This Skill Category describes the management processes used to establish the foundation of a quality-managed environment including leadership concepts, the quality management infrastructure, and the quality environment.

The primary concern of the user during acceptance testing is that the deliverables meet the user requirements. The specific concerns during this phase are:

Meets specifications

All of the deliverables provided by the contractor meet the user requirements as specified in the contract.

On time

The delivered products will be in the hands of the user on the date specified on the contract.

Adequate test data

The customer should prepare sufficient test data so that the deliverables can be adequately tested. For application systems, this may be test transactions to verify the processing performed by the application. The acceptance test criteria for training courses and manuals may be review and examination. For example, the contractor may be asked to put on a training class in order to determine the adequacy of the material.

Preparation for operation

Any supporting activities should be completed in time for acceptance testing. This may involve the ordering of forms, making changes to existing operating systems, and other application systems, developing procedures to use the application, etc. The customer should have identified these needs during the feasibility phase, and worked on meeting those requirements while the contractor was preparing the application system.

User training

The users of the application should be trained prior to the acceptance test phase. This training may be provided by the organization itself, or it may be done by the contractor.

When can it begin

Acceptance testing should occur on the date which was specified in the contract.

Conversion to production

The procedures and steps necessary to put the application into production should be tested during the acceptance testing phase. These are normally customer obligations to prepare files, schedule production, etc. These procedures should be tested just as vigorously as the contractor’s application system.

IT organizations cannot protect the confidentiality, integrity, and availability of information in today’s highly networked systems environment without ensuring that all the people involved in using and managing IT:

Understand their roles and responsibilities related to the organizational mission

Understand the organization’s IT security policy, procedures, and practices

Have at least adequate knowledge of the various management, operational, and technical controls required and available to protect the IT resources for which they are responsible

Fulfill their security responsibilities.

As cited in audit reports, periodicals, and conference presentations, it is generally agreed by the IT security professional community that people are the weakest link in attempts to secure systems and networks.

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:

1. IT management creates a security awareness policy.

2. Develop the strategy that will be used to implement that policy. (Note that this practice focuses on that strategy. Other practices will explain how to implement the steps in that strategy.)

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

Total quality management (TQM) is the term used by many to indicate an organization-wide effort of continuous process improvement. The Federal Quality Institute defines TQM as a strategic, integrated management system for achieving customer satisfaction, which involves all managers and employees and uses quantitative methods to continuously improve an organization's processes.

Some additional thoughts on TQM include:

The improved performance is directed toward satisfying such cross-functional goals as quality, cost, schedule, mission, need and suitability.

TQM is a process of controlled change.

Central to the TQM approach is the change in management philosophy regarding the "responsibility for quality." Formerly it rested with a separate group of individuals in a department/directorate/division often designated as quality assurance. Under TQM, the responsibility rests with every employee, beginning with top management. Skill Category2 provides additional insight into the change in management philosophy, new behaviors for management and leadership.

TQM is accomplished using a team organization; both management and the employees are members of "quality teams" (also called process improvement or process action teams), that focus on continuous process improvement. Suggestions to improve the quality of a particular process should come from the employees and the managers who work in the process, as they know it best.

Communication must be encouraged to allow employees and management to work together to reach the mutual goal of continuous process improvement.

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.

Developing a cause-and-effect diagram requires this series of steps:

1. Identify a problem (effect) with a list of potential causes. This may result from a brainstorming session.

2. Write the effect at the right side of the paper.

3. Identify major causes of the problem, which become “big branches”. Six categories of causes are often used: Measurement, Methods, Materials, Machines, People, and Environment, but the categories vary with the effect selected.

4. Fill in the “small branches” with subcauses of each major cause until the lowestlevel subcause is identified.

5. Review the completed cause-and-effect diagram with the work process to verify that these causes (factors) do affect the problem being resolved.

6. Work on the most important causes first. Teams may opt to use the nominal group technique or Pareto analysis to reach consensus.

7. Verify the root causes by collecting appropriate data (sampling) to validate a relationship to the problem.

8. Continue this process to identify all validated causes, and, ultimately the root cause.