SQA2

2.4 Opportunities for Process

There are some opportunities for process listed in following table.

3. Measure Phase

3.1 Measurement System Analysis

• Lack of visibility is a well-known constraint in software project management.
• Software measurements should bring visibility into processes.
• Typical software measuring instruments: Estimation; Tracking & Monitoring; Audit; Log sheets;
  Data collection; etc.
• Measurements become more meaningful indicators called Metrics. The final choice of metrics has to
  be organization specific.

 3.2 Metrics

A practical metric called Effort-Variance will be used here, which is illustrated as below:

Effort-Variance indicates project implementation status and could signal in both directions (overrun or
better than estimation).
It is also SMART (simple, measurable, actionable, related, and timely).
Here is an example of evaluating the value of Effort-Variance of a given feature development project:

• Estimation: 3 developer-hours (rate: $40/d_h) + 2 tester-hours (rate: $30/t_h)
• Actual Efforts: 4 developer-hours + 3 tester-hours
• Effort-Variance = [(4*40+3*30) – (3*40+2*30)] / (3*40+2*30) = 0.389
• The value as of 0.389 shows that the actual efforts overrun by 38.9% in terms of a combination
  of costs and time.

3.3 Existing Process Capability

Process Capability indexes depend on the assumption that the distribution of output is normal. The data of existing process capability is shown in Figure 4.
Although the output here is skewed distribution by nature, because any output at the right side (<0) is
desirable, so the process here is still under statistical control.
Although for skewed distribution, Cp<1 is possibly acceptable, here Cp (0.21587) is too low (based on
existing data collected).

 

Figure 4 Data of Existing Process Capability

4. Analyze Phase

4.1 Process Mapping

4.2 ANOVA

We applied ANOVA to test the misunderstanding of client's requirements problem in different teams.

• Hypothesis Testing: 
• Root Cause: Misunderstanding of client's expectations/requirements
• Assume all other causes affect the Effort-Variance of different groups equally
• P-value = 0.111198
• F value (2.8315) is smaller than critical F value (4.2565)

The detailed ANOVA testing is shown in Figure 5.

Figure 5 Project Delay by Misunderstanding of client's requirements

Conclusion: From the ANOVA result, we can conclude that there is no big difference exists between different groups when misunderstanding of client's expectations/requirements is the root cause. We cannot reject the hypothesis that means misunderstanding of the client’s expectations/requirements is the main issue.

4.3 Cause-and-effect Diagrams

The Cause-and-effect (fishbone) diagram as shown in Figure 6 identifies the most likely cause of high EV, so that further data collection and analysis can be carried out. We can organize the causes of high EV into 4 categories, which are system analysis, QA team, software resources, and developer team. In each category there are several potential causes. All the causes are mark with x1 to x9.

Figure 6 Cause-and-effect diagram

Identifying all the causes of high EV:
X1 Misunderstanding of client's expectations/requirements.
X2 Poor internal communication between project team members
X3 Faulty systems modeling and design
X4 Delays in Restructuring of EPC database
X5 Rescheduling of documentation & knowledge base updates
X6 Use of inefficient algorithms
X7 Unified programming convention not followed
X8 Delays in preparing test cases & testing software
X9 Limited use of software configuration management/version control tools

4.4 Potential Causes Analysis

X2: 3% of internal communication (email requests, etc.) had to be re-clarified, which resulted in higher EV.

 
X4: 11% of development tasks have been reworked due to restructuring of EPC database after development stage.
X5: 6% of customer complaints resulted from this variable.
X6 & X7: these two variables concern the skills of programmers. 2 out of 20 developers receive below-average annual performance evaluation.
X9: 8% of development & testing tasks have been reworked due to version conflicts.

5 Improve Phase

 6. Control Phase

6.1 Project Schedule (Gantt Chart) (Omitted)

6.2 Result Evaluation

6.2.1 Process Capability and Control Chart (Omitted)

6.2.2 Financial Analysis

 

 6.3 Consolidate the Process Improvement with ISO 90003

The main steps of carrying out ISO IEC 9003 are outlined below, which would be submitted to the management for further approval.

* Develop quality management system documents.
- Develop documents to implement the quality system.
- Develop documents that describe the software processes.
- Develop documents that describe the life cycle models.

* Prepare a quality management system manual.
- Document the procedures.
- Describe how your processes interact.
- Define the scope of your quality system.
- Justify exclusions and reductions in scope.

* Control quality management system documents.
- Approve documents before you distribute them.
- Provide the correct version of documents at points of use.
- Prevent the accidental use of obsolete documents.
- Preserve the usability of your quality documents.

* Maintain quality management system records.
- Prove that requirements have been met.
- Prove that your operations are effective.
- Establish a record retention approach.