Management Plan: Software Reliability211
3.0 Executing Process Group: Software Reliability213
3.1 Team Member Status Report: Software Reliability215
3.2 Change Request: Software Reliability217
3.3 Change Log: Software Reliability219
3.4 Decision Log: Software Reliability221
3.5 Quality Audit: Software Reliability223
3.6 Team Directory: Software Reliability226
3.7 Team Operating Agreement: Software Reliability228
3.8 Team Performance Assessment: Software Reliability230
3.9 Team Member Performance Assessment: Software Reliability232
3.10 Issue Log: Software Reliability234
4.0 Monitoring and Controlling Process Group: Software Reliability236
4.1 Project Performance Report: Software Reliability238
4.2 Variance Analysis: Software Reliability240
4.3 Earned Value Status: Software Reliability242
4.4 Risk Audit: Software Reliability244
4.5 Contractor Status Report: Software Reliability246
4.6 Formal Acceptance: Software Reliability248
5.0 Closing Process Group: Software Reliability250
5.1 Procurement Audit: Software Reliability252
5.2 Contract Close-Out: Software Reliability255
5.3 Project or Phase Close-Out: Software Reliability257
5.4 Lessons Learned: Software Reliability259
Index261
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. Where do you need to exercise leadership?
<--- Score
2. What do employees need in the short term?
<--- Score
3. Will new equipment/products be required to facilitate Software reliability delivery, for example is new software needed?
<--- Score
4. How do you assess your Software reliability workforce capability and capacity needs, including skills, competencies, and staffing levels?
<--- Score
5. What needs to be done?
<--- Score
6. Do you need to avoid or amend any Software reliability activities?
<--- Score
7. Are there regulatory / compliance issues?
<--- Score
8. How does it fit into your organizational needs and tasks?
<--- Score
9. What are the stakeholder objectives to be achieved with Software reliability?
<--- Score
10. How many trainings, in total, are needed?
<--- Score
11. What vendors make products that address the Software reliability needs?
<--- Score
12. Think about the people you identified for your Software reliability project and the project responsibilities you would assign to them, what kind of training do you think they would need to perform these responsibilities effectively?
<--- Score
13. What is the extent or complexity of the Software reliability problem?
<--- Score
14. Are there Software reliability problems defined?
<--- Score
15. How are you going to measure success?
<--- Score
16. Would you recognize a threat from the inside?
<--- Score
17. Who are your key stakeholders who need to sign off?
<--- Score
18. Are there recognized Software reliability problems?
<--- Score
19. Do you have/need 24-hour access to key personnel?
<--- Score
20. Looking at each person individually – does every one have the qualities which are needed to work in this group?
<--- Score
21. How can auditing be a preventative security measure?
<--- Score
22. What should be considered when identifying available resources, constraints, and deadlines?
<--- Score
23. Will Software reliability deliverables need to be tested and, if so, by whom?
<--- Score
24. What Software reliability capabilities do you need?
<--- Score
25. What is the Software reliability problem definition? What do you need to resolve?
<--- Score
26. Will a response program recognize when a crisis occurs and provide some level of response?
<--- Score
27. What are the minority interests and what amount of minority interests can be recognized?
<---
