2.36 Procurement Management Plan: Software Reliability Testing212
2.37 Source Selection Criteria: Software Reliability Testing214
2.38 Stakeholder Management Plan: Software Reliability Testing216
2.39 Change Management Plan: Software Reliability Testing218
3.0 Executing Process Group: Software Reliability Testing220
3.1 Team Member Status Report: Software Reliability Testing222
3.2 Change Request: Software Reliability Testing224
3.3 Change Log: Software Reliability Testing226
3.4 Decision Log: Software Reliability Testing228
3.5 Quality Audit: Software Reliability Testing230
3.6 Team Directory: Software Reliability Testing233
3.7 Team Operating Agreement: Software Reliability Testing235
3.8 Team Performance Assessment: Software Reliability Testing237
3.9 Team Member Performance Assessment: Software Reliability Testing240
3.10 Issue Log: Software Reliability Testing242
4.0 Monitoring and Controlling Process Group: Software Reliability Testing244
4.1 Project Performance Report: Software Reliability Testing246
4.2 Variance Analysis: Software Reliability Testing248
4.3 Earned Value Status: Software Reliability Testing250
4.4 Risk Audit: Software Reliability Testing252
4.5 Contractor Status Report: Software Reliability Testing254
4.6 Formal Acceptance: Software Reliability Testing256
5.0 Closing Process Group: Software Reliability Testing258
5.1 Procurement Audit: Software Reliability Testing260
5.2 Contract Close-Out: Software Reliability Testing262
5.3 Project or Phase Close-Out: Software Reliability Testing264
5.4 Lessons Learned: Software Reliability Testing266
Index268
CRITERION #1: RECOGNIZE
INTENT: Be aware of the need for change. Recognize that there is an unfavorable variation, problem or symptom.
In my belief, the answer to this question is clearly defined:
5 Strongly Agree
4 Agree
3 Neutral
2 Disagree
1 Strongly Disagree
1. Will it solve real problems?
<--- Score
2. Who else hopes to benefit from it?
<--- Score
3. Are there Software reliability testing problems defined?
<--- Score
4. What are the expected benefits of Software reliability testing to the stakeholder?
<--- Score
5. What are the minority interests and what amount of minority interests can be recognized?
<--- Score
6. What are your needs in relation to Software reliability testing skills, labor, equipment, and markets?
<--- Score
7. What situation(s) led to this Software reliability testing Self Assessment?
<--- Score
8. Consider your own Software reliability testing project, what types of organizational problems do you think might be causing or affecting your problem, based on the work done so far?
<--- Score
9. What information do users need?
<--- Score
10. Do you recognize Software reliability testing achievements?
<--- Score
11. Are employees recognized or rewarded for performance that demonstrates the highest levels of integrity?
<--- Score
12. Is it clear when you think of the day ahead of you what activities and tasks you need to complete?
<--- Score
13. Which needs are not included or involved?
<--- Score
14. Why the need?
<--- Score
15. Which issues are too important to ignore?
<--- Score
16. Will Software reliability testing deliverables need to be tested and, if so, by whom?
<--- Score
17. What needs to be done?
<--- Score
18. Is the need for organizational change recognized?
<--- Score
19. When a Software reliability testing manager recognizes a problem, what options are available?
<--- Score
20. Who needs to know about Software reliability testing?
<--- Score
21. Does the problem have ethical dimensions?
<--- Score
22. Who defines the rules in relation to any given issue?
<--- Score
23. What Software reliability testing problem should be solved?
<--- Score
24. What does Software reliability testing success mean to the stakeholders?
<--- Score
25. As a sponsor, customer or management, how important is it to meet goals, objectives?
