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.

Force field analysis is a visual team tool used to determine and understand the forces that drive and restrain a change. Driving forces promote the change from the existing state to the desired goal. Opposing forces prevent or fight the change. Understanding the positive and negative barriers helps teams reach consensus faster. Following are sample processes that could benefit by a force field analysis:

Implementing a quality function

Implementing quality management in IT

Developing education and training programs

Establishing a measurement program/process

Selecting a new technique or tool

Implementing anything new

Establishing meaningful meetings

Empowering the work force

The steps below show how a team uses force field analysis:

1. Establish a desired situation or goal statement.

2. Brainstorm and list all possible driving forces.

3. Brainstorm and list all possible restraining forces.

4. Determine the relative importance of reaching consensus on each force.

5. Draw a force field diagram that consists of two columns, driving forces on one side and restraining forces on the other.

6. Select the most significant forces that need to be acted upon using the nominal group technique to prioritize and reduce the number, if there are too many.

7. Proceed to a plan of action on the forces selected in the previous step

In order to participate in the various aspects of contracting for software development, it is necessary to establish an acquisition life cycle for contracted software. This life cycle contains the following three activities:

Selecting an Outside Organization

Selecting a contractor is similar to systems design. It is a time of studying alternative contractors, costs, schedules, detailed implementation design specifications, and the specification of all the deliverables, such as documentation. The selection of an outside organization may involve the following individuals in addition to the quality control reviewer:

Systems analysts

User personnel

Internal auditor

Purchasing agent

Legal counsel

Contract Negotiations

In some organizations, the purchasing agent conducts all the negotiations with the contractor; the other parties are involved only in the needs specification. In other organizations, there is no purchasing agent, so the data processing department deals directly with contractors for the acquisition of application systems.

Operations and Maintenance

The maintenance and operations of purchased applications may be subject to contractual constraints. For example, some contracts limit the frequency with which an application can be run without paying extra charges, and limit an organization’s ability to duplicate the application system in order to run it in a second location. In-house personnel can maintain some purchased applications, but others do not come with source code and thus are not maintainable by in-house personnel. There may also be problems in connecting a purchased application from one contractor with purchased or rented software from another contractor. It is important that software from multi contractors be evaluated as to its capability to work in the same operating environment.

Assure Completeness of Needs Requirements

This step determines whether you have adequately defined your requirements. Your requirements should be defined in terms of the following two categories of outputs:

1. Output Products and Output Reports -Output products and output reports are specific documents that you want produced by the computer system. In many instances, such as the previous payroll check example, the style and format of these output products is important. This does not mean that the specific location of the check has to be defined but, rather, the categories of information to be included on the check. Computer-produced reports may also be important for tax information (e.g., employee withholding forms sent to governmental units), financial statements where specific statements are wanted (e.g., balance sheets or statements of income and expense), or customer invoice and billing forms which you might want preprinted to include your logo and conditions of payment.

2.Management decision information. This category tries to define the information needed for decision-making purposes. In the computer product/report category you were looking for a document; in this case you are looking for information. How that information is provided is unimportant. Thus, the structure of the document, what the documents are, or their size, frequency, or volume are not significant. All you need is information.

Define Critical Success Factor

This step tells whether the COTS software will be successful in meeting your requirements. Critical success factors (CSFs) are those criteria or factors that must be present in the acquired software for it to be successful. You might ask whether the needs are the same as the critical success factors. They are, but they are not defined in a manner that makes them testable, and they may be incomplete. Often the needs do not take into account some of the intangible criteria that make the difference between success and failure. In other words, the needs define what we are looking for, and the critical success factors tell us how we will evaluate that product after we get it. They are closely related and complementary, but different in scope and purpose.

The following list indicates the needs or requirements for the automobile, and is then followed by the CSFs on which the automobile will be evaluated:

Seats six people

Four doors

Five-year guarantee on motor

Gets 20 miles per gallon or greater

Costs under $12,000

Critical success factors:

Operates at 20.5 cents or less per mile

Experiences no more than one failure per year

Maintains its appearance without showing signs of wear for two years

Some of the more common critical success factors for COTS you may want to use are:

Ease of use - The software is understandable and usable by the average person.

Expandability - The contractor plans to add additional features in the future.

Maintainability - The contractor will provide support/assistance to help utilize the package in the event of problems.

Cost-effectiveness - The software package makes money for your business by reducing costs, and so on.

Transferability - If you change your computer equipment the contractor indicates that they will support new models or hardware.

Reliability - In computer language, the system is friendly, meaning that it will help you get your transactions entered into the system so that you can produce your results readily.

Security - The system has adequate safeguards to protect the data against damage (for example, power failures, operator errors, or other goofs that could cause you to lose your data).

Determine Compatibility with Hardware, Operating System, and Other COTS Software

This is not a complex step. It involves a simple matching between your processing capabilities and limitations, and what the contractor of the software says is necessary to run the software package. The most difficult part of this evaluation is ensuring the multiple software packages can properly interface.

This step is best performed by preparing a checklist defining your compatibility needs. Software contractors are generally good about identifying the needed hardware and operating system compatibility. They are generally not good in identifying compatibility with other software packages.

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.

Management needs to develop quantitative, measurable "standards" for each of these quality criteria for their development projects. For example, management must decide the degree of maintenance effort that is acceptable, the amount of time that it should take for a user to learn how to use the system, etc.

Rahail HDD:Users:iMac:Desktop:Screen Shot 2015-01-11 at 2.39.38 PM.png

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.