Free and Premium Software Certifications CSQA Dumps Questions Answers

Verification requires several types of reviews, including requirements reviews, design reviews, code walkthroughs, code inspections, and test reviews. The system user should be involved in these reviews to find defects before they are built into the system. In the case of purchased systems, user input is needed to assure that the supplier makes the appropriate tests to eliminate defects. The following table shows examples of verification. The list is not exhaustive, but it does show who performs the task and what the deliverables are. For purchased systems, the term “developers” applies to the supplier’s development staff.

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

Validation is accomplished simply by executing a real-life function (if you wanted to check to see if your mechanic had fixed the starter on your car, you’d try to start the car). Examples of validation are shown in the following table. As in the table above, the list is not exhaustive.

Determining when to perform verification and validation relates to the development, acquisition, and maintenance of software. For software testing, this relationship is especially critical because:

The corrections will probably be made using the same process for developing the software. If the software was developed internally using a waterfall methodology, that methodology will probably be followed in making the corrections; on the other hand, if the software was purchased or contracted, the supplier will likely make the correction. You’ll need to prepare tests for either eventuality.

Testers can probably use the same test plans and test data prepared for testing the original software. If testers prepared effective test plans and created extensive test data, those plans and test data can probably be used in the testing effort, thereby reducing the time and cost of testing.

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

Level 1 – 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 of a system; integration testing tests the connecting logic between the modules/units; and the system testing validates that the system executes in the organization's operating environment.

Level 2 – 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.

Level 3 -- Defect Management

This level involves naming defects, counting defects, recording defects in a database, analyzing them, and then managing them throughout the entire life cycle of software. There are two types of defects, just as there are two types of quality. One defect is a variance from requirements/specifications, and the second defect is anything that dissatisfies the end user. For example, if the system was to add A plus B to get C, but in fact added A to X that would be a variance from specification defect. If the output was correct, but hard to use from an end user viewpoint, it would be an ease of use defect. Defects are generally only considered to be defects when they are uncovered in a task beyond the task in which the defect occurred. If the individual who makes the defect finds it during the same task, it is generally not considered to be a defect.

Level 4 -- Statistical Process Control

To be effective, statistical process control needs stabilized processes and defect recording. Some statistical process control techniques will be introduced at Level 3, but their use will be confined more to process improvement than for process management. Good statistical process control techniques require the type of measurement data that is only produced at Level 4. The statistical process control techniques will expand on root cause analysis, use sophisticated statistical tools and analysis, and create dashboards to be used in managing processes.

Level 5 - Preventive Management

This level is focused on preventing defects. It uses the lessons learned from the previous four levels of control/test to address the problems before they can become defects. During the previous four levels, the causes of defects are available and some addressed through process improvement. This level accelerates that trend and in addition provides the professional information staff with methods to modify the way work is performed so that the root causes of defects will not be built into software. This involves building risk models, developing defect expectation charts and/or defect profiles, and processes to customize processes so that the do component of processes can build software that is almost defect free.

A baseline study is one designed to quantitatively show the current status of an activity, program, or attitude. It both shows “how you are doing” and provides a quantitative base from which change can be measured.

Objectives/Goals Planning

Setting the project objectives/goals is an important component of the planning cycle. Goals and objectives should be measurable and achievable. If goals are not measurable it will be difficult to determine whether or not the project is successful. If the goals are not achievable the assigned staff are in a “no win” situation. However, some management philosophies believe in using stretch goals to push people to achieve a higher level of performance. Specifically, this activity should address:

Project objectives and goals expressed in quantitative terms

Any qualifications for objectives that can impact the sequence of work, or alternative strategies can be determined

Quality and productivity goals

Assumptions/Potential Planning

This planning activity identifies those probable developments that will affect the ability to achieve the project objectives. These developments should be as specific as possible in terms of how much and when. In this activity the planners are trying to describe what will happen in the next month or years so that implementation can seize any new opportunities that may develop. Specifically, this planning activity should address:

Assumptions which if not correct will impact the success of the project

Current opportunities received from implementing the project

How future opportunities will be identified during the implementation and operation timeframe of the project.

The workbench transforms to the input to produce the output. The workbench is comprised of two procedures: Do and Check, which correspond to the Do and Check phases of the PDCA cycle. If the Check procedure determines that the standards for the output product are not met, the process engages in rework until the output products meet the standards, or management makes a decision to release a nonstandard product. People, skills, and tools support the Do and Check procedures. A process is defined by workbench and deliverable definitions. A process is written with the assumption that the process owners and other involved parties possess certain skill and knowledge levels (subject matter expertise).

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

Level 1 – Constraint Requirements

This level involves staffing, budget, and schedule. The business requirements are frequently defined as a set of objectives described on several pages of narrative description. Thus, it becomes the role of the project team to expand the initial definition and build the software. However, management and the end user of the software will manage more by the constraint requirements than by the business requirements. The result is that the software put into production on the scheduled date may miss many key requirements, which will need to be installed after the operational date but under new budgets and schedules.

Level 2 – Business Requirements

This level places its emphasis on the functional and operating requirements. Level 2 establishes the criteria that the deliverables must meet in order to be accepted by the end user. At this level, standards are established for the requirements document which specifies the totality of requirement attributes that must be included for the requirements to be considered complete. These often include defining how the requirements will be tested, the objective of therequirement, the problem that the requirement is designed to solve, a detailed description of the requirement, and how the requirement is related to the objectives to be accomplished. Many information organizations at this level introduce uniquely identifying requirements, and then utilize processes that trace requirements through the entire software-building process.

Level 3 – Relational Requirements

This level emphasizes relationships within an information system and between information systems. Level 2 defines relationships, but normally at a much lower level than Level 3. Level 2 relationship specifications tend to be within an individual application system. Level 3 relationships focus on organizational databases, processing sequences and priorities, intersystem relationships, and processing cycle relationships. Data relationships help eliminate data redundancy and help assure consistency of use of data throughout an organization. Processing relationships address processing priorities and processing sequences. The system relationships deal with interfaces between systems and changes to systems. The larger challenge is assuring that all systems are changed concurrently when they are impacted by a common change(s). The processing cycle or timing relationship assures that all data that belongs in a particular accounting processing cycle is processed during that cycle.

Level 4 – Quality Requirements

Quality requirements are the characteristics surrounding the functional requirements that facilitate end user satisfaction. An example of quality requirements is ease of use. The functional requirements deal with the data specified for a particular product, but if it is very difficult to use (i.e., not meeting the quality ease of use requirement); the end user tends to be dissatisfied.

Level 5 – Reliability Requirements

Reliability primarily deals with mean time between failures. To achieve reliability requirements necessitates building a database of processing information and performing adequate statistical analysis on that data. Then a statistical prediction of reliability can be made. While the end user needs to specify reliability requirements, they can only be measured and achieved through the use of statistical tools. Figure 44 shows the best practices for deliveries process.

There are several concerns that need to be addressed when one of the methods of implementation is contracting for software development. These review concerns are:

Control specification- The controls desired in the application should be specified in enough detail during the feasibility study so that the individual negotiating for an application can include those control specifications in the contract negotiation.

Needed installation date- The date on which the application is to go into production should be specified. Many applications lose a large portion of their benefits if the application is not installed when needed. For example, an application designed to provide special promotions for Christmas shopping would be of little value if it is not completed in time for Christmas purchasing. Specifying this date may indicate whether an application needs to be purchased, or whether it can be developed in-house.

Value of applications- The benefits to be obtained from an application should be specified. These are the benefits above and beyond what is currently being obtained from the existing method of performing the tasks. The benefits need to be quantified. For example, benefits like improved customer service are of limited aid in making business decisions on installing or purchasing new applications. The objective of having a stated dollar value.

Useful life- The expected life of the application should be stated. For example, if it is expected that the requirements and technology needed will satisfy the needs of the organization for an eight-year period, that should be stated. Where it is difficult to estimate a specific useful life, a range such as 5-10 years is often sufficient.

Confidentiality of application- Feasibility studies should state the confidentiality of the application to the organization. This importance would deal with the need to keep the processing rules confidential. For example, the application may include the formula used in creating products for production. Since the application contains those formulas, it contains the trade secrets of the organization, which must be adequately protected.

In the prioritization process, risks from the analysis process are ranked from highest to lowest. When possible, they should be ranked quantitatively; otherwise, it is done qualitatively. Items that have similar ranks may need to be ranked separately.

If the high-medium-low method was used to calculate risk, the analyst would need to determine how to rank the two scores of 5, the three scores of 4 and the two scores of 3. In other words, determine whether the value of the frequency or the value of the impact would be more important.

Risks may also be prioritized using a question-and-answer technique to filter out unimportant risks. Four filters are typically used: impact (significant or insignificant), likelihood of occurrence (very likely or not likely), time frame (short-term or long-term), and program control (within control or not within control).

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.

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.

Dynamic testing (also known as program testing) implies that the code is being executed on a machine.

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.

The starting point in new product development is the decision of what to build for whom. This requires determining customers, finding out what they want, and identifying whatcapabilities can be provided to them. In QFD, the fundamental deployments of customers and quality address this.

Customer Deployment involves determining which types of customers for which the organization is trying to provide a product or service. It precedes the determination of requirements in quality deployment. Customers must be identified first in order to know to which voices to listen. The customer deployment component of QFD is particularly important for software, as a single software product must often satisfy many types of customers.

Quality Deployment has tools and techniques for the exploration and specification of high-value customer requirements (or "demanded quality"). Once captured, the customer requirements are translated and deployed into technical requirements (or “quality characteristics”) in the House of Quality matrix. (The House of Quality is the first matrix that a product development team uses to initiate a Quality Function Deployment (QFD) process.) This can be done at various levels of sophistication, ranging from four matrices to a dozen.

These fundamental deployments are the foundation for downstream design-and-development decisions about “how” the product will work (the horizontal deployments) and 'how well' it will be designed and developed (the vertical deployments). Both horizontal and vertical deployments are required to appropriately handle this complexity.

An evaluator can use the six steps below to assess the climate of a specific organization, group, committee, task force, etc.

1. Look at the organization (group, committee, task force, etc.)

Assess the mission and goals of the organization, what it is supposed to produce, and the overriding principles by which it operates.

2. Examine the jobs

Examine each job in the organization. Ask whether the job is necessary, whether it makes full use of the employee’s capabilities, and whether it is important in accomplishing the mission and goals of the organization.

3. Assess employees’ performance

Evaluate each employee’s performance in relation to the organization’s mission and goals. For each job being performed, ask if the employee is doing what should be done, is using his or her skills effectively, likes his or her job, and has enthusiasm and interest in performing the job.

4. Evaluate how employees feel about their manager or leader

Good organizational climate requires good leadership. Determine whether each employee within the group likes his or her manager, whether they follow or ignore the requests of their manager, and whether they attempt to protect their manager (i.e., make their manager look good).

5. Create a dialog with the members of the group

Interact with each employee asking a series of hypothetical questions to identify the employee's true feelings toward the organization. Questions such as, “do you feel the organization supports your suggestions”, can help draw out the true feelings of each employee.

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 Category 2 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.

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