Source Selection Criteria: Software Test Engineering212
2.38 Stakeholder Management Plan: Software Test Engineering214
2.39 Change Management Plan: Software Test Engineering216
3.0 Executing Process Group: Software Test Engineering218
3.1 Team Member Status Report: Software Test Engineering220
3.2 Change Request: Software Test Engineering222
3.3 Change Log: Software Test Engineering224
3.4 Decision Log: Software Test Engineering226
3.5 Quality Audit: Software Test Engineering228
3.6 Team Directory: Software Test Engineering231
3.7 Team Operating Agreement: Software Test Engineering233
3.8 Team Performance Assessment: Software Test Engineering235
3.9 Team Member Performance Assessment: Software Test Engineering237
3.10 Issue Log: Software Test Engineering239
4.0 Monitoring and Controlling Process Group: Software Test Engineering241
4.1 Project Performance Report: Software Test Engineering243
4.2 Variance Analysis: Software Test Engineering245
4.3 Earned Value Status: Software Test Engineering247
4.4 Risk Audit: Software Test Engineering249
4.5 Contractor Status Report: Software Test Engineering251
4.6 Formal Acceptance: Software Test Engineering253
5.0 Closing Process Group: Software Test Engineering255
5.1 Procurement Audit: Software Test Engineering257
5.2 Contract Close-Out: Software Test Engineering259
5.3 Project or Phase Close-Out: Software Test Engineering261
5.4 Lessons Learned: Software Test Engineering263
Index265
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. How do you assess your Software test engineering workforce capability and capacity needs, including skills, competencies, and staffing levels?
<--- Score
2. Who needs to know about Software test engineering?
<--- Score
3. Are employees recognized or rewarded for performance that demonstrates the highest levels of integrity?
<--- Score
4. Are there recognized Software test engineering problems?
<--- Score
5. What needs to stay?
<--- Score
6. Are problem definition and motivation clearly presented?
<--- Score
7. How much are sponsors, customers, partners, stakeholders involved in Software test engineering? In other words, what are the risks, if Software test engineering does not deliver successfully?
<--- Score
8. What information do users need?
<--- Score
9. What are the expected benefits of Software test engineering to the stakeholder?
<--- Score
10. What is the problem or issue?
<--- Score
11. What is the smallest subset of the problem you can usefully solve?
<--- Score
12. Who needs to know?
<--- Score
13. Are there any specific expectations or concerns about the Software test engineering team, Software test engineering itself?
<--- Score
14. What needs to be done?
<--- Score
15. Does the problem have ethical dimensions?
<--- Score
16. How does it fit into your organizational needs and tasks?
<--- Score
17. What does Software test engineering success mean to the stakeholders?
<--- Score
18. What extra resources will you need?
<--- Score
19. Are there regulatory / compliance issues?
<--- Score
20. Which information does the Software test engineering business case need to include?
<--- Score
21. To what extent would your organization benefit from being recognized as a award recipient?
<--- Score
22. What prevents you from making the changes you know will make you a more effective Software test engineering leader?
<--- Score
23. Looking at each person individually – does every one have the qualities which are needed to work in this group?
<--- Score
24. What are the timeframes required to resolve each of the issues/problems?
<--- Score
25. How do you recognize an Software test engineering objection?
<--- Score
26.
