Software Certifications CSQA Dumps Questions Answers

A process can be measured by either of the following:

Attributes of the process, such as overall development time, type of methodology used, or the average level of experience of the development staff.

Accumulating product measures into a metric so that meaningful information about the process can be provided. For example, function points per person-month or LOC per person-month can measure productivity (which is product per resources), the number of failures per month can indicate the effectiveness of computer operations, and the number of help desk calls per LOC can indicate the effectiveness of a system design methodology.

There is no standardized list of software process metrics currently available. However, in addition to the ones listed above, some others to consider include:

Number of deliverables completed on time

Estimated costs vs. actual costs

Budgeted costs vs. actual costs

Time spent fixing errors

Wait time

Number of contract modifications

Number of proposals submitted vs. proposals won

Percentage of time spent performing value-added tasks

Using defects to improve processes is not done by many organizations today, but it offers one of the greatest areas of payback. NASA emphasizes the point that any defect represents a weakness in the process. Seemingly unimportant defects are, from a process perspective, no different from critical defects. It is only the developer’s good luck that prevents a defect from causing a major failure. Even minor defects, therefore, represent an opportunity to learn how to improve the process and prevent potentially major failures. While the defect itself may not be a big deal, the fact that there was a defect is a big deal.

Based on the research team findings, this activity should include the following:

Go back to the process that originated the defect to understand what caused the defect

Go back to the verification and validation process, which should have caught the defect earlier

Not only can valuable insight be gained as to how to strengthen the review process, these steps make everyone involved in these activities take them more seriously. This human factor dimension alone, according to some of the people the research team interviewed, can have a very large impact on the effectiveness of the review process.

The steps below describe a sample defect tracking process. Depending on the size of the project or project team, this process may be substantially more complex.

1. Execute test and log any discrepancies.

The tester executes the test and compares the actual results to the documented expected results. If a discrepancy exists, the discrepancy is logged as a “defect” with a status of “open.” Supplementary documentation, such as screen prints or program traces, is attached if available.

2. Determine if discrepancy is a defect.

The Test Manager or tester reviews the defect log with an appropriate member of the development team to determine if the discrepancy is truly a defect, and is repeatable. If it is not adefect, or repeatable, the log should be closed with an explanatory comment.

3. Assign defect to developer.

If a defect exists it is assigned to a developer for correction. This may be handled automatically by the tool, or may be determined as a result of the discussion in step 2.

4. Defect resolution process.

When the developer has acknowledged the defect is valid, the resolution process begins.