• View
• Edit
• History
• Print

SPSG Links

1. Requirements Materials (pp. 37-39); e.g.:

1. Software Development Plan, (here)
2. SW Project Estimates, (here)
3. Q/A Plan, and (here, section 2.4)
4. Staged Development Plan. (here, section 2.1)

2. Planning Checkpoint; be prepared to answer questions and issues raised on pp. 39-40 (here)
3. Project Description must include (see pp. 92-93):

1. description of project document access (here)
2. version control description. Version Control will be set up when there is something in the Change Board.
3. statistics on LOC per week (here)

4. Project Website

1. Project Log (here)
2. Charts 5.4, 5.5 (here)
3. Map Figure 5-7 onto actual calendar (here, section 2.1)
4. Must schedule, deliver and keep documentation of everything in Table 5-1. (here)

5. Change Board. (here, section 2.3)

1. Includes Prof. Henderson (we did, see above link)
2. Table 6-1 changes must be available and tracked (integrated part of wiki)

6. Planning:

1. Risk Management: Answer questions on p. 100 (here)
2. Develop a mechanism to evaluate individual team members. (here, section 2.4)
3. Name who plays each role. (here, section 2.2)
4. Define the accounting methodology (minimally Table 7-4, pp. 108-109) (here)
5. SW Development Plan (p. 110) (here)

7. Requirements:

1. Document process (here, section 2.1)
2. Include specific responses to issues (p. 120) (here)
3. Specify defect tracking tools and info (here)
4. Give Traceability Matrix (here)
5. Must document reviews/tests specified in Table 9-3 (pp. 138-139) (here)
6. Define measurable Q/A release criteria (here)

8. Architecture and Design:

1. Specify architecture and language(s) (here, section 4.3)
2. Answer questions (pp. 149-150) (here)
3. Discuss issues with architecture risks and staged delivery (here)
4. Explain how SW Architecture document is tied to change and review (here, section 2.3)
5. Define project estimates process and dates (pp. 159-160) (here)
6. Use stage themes. (here)
7. Document each activity (This can be seen in our seperate work logs)
8. Answer questions (p. 192) (here, section 3.4)
9. Use detailed design document formats (p. 196) (here, section 3.2)

9. Construction:

1. Define coding standard (pp. 200-201: describe choice for list) (here)
2. Document integration procedure (p. 203) (here)
3. Define Test Procedure; document use (p. 205) (here)
4. Provide weekly snapshot of Fig. 14-1 (p. 207) (here)
5. Define and use construction tracking method (p. 208) (here)
6. Provide weekly tracking update (p. 209) (here)
7. Track high-defect routines (pp. 218-219) (here)
8. Provide open defects graph (p. 224) (here, as timeline instead of graph)
9. Defect statistics required (p. 225) (here, each ticket has individual information)
10. Document the info on pp. 229-230 (here)
11. Document Release Checklist pp. 232-233 (here)
12. At end of each stage, document estimates (p. 239) (here)

10. Project Review

1. Give performance evaluation criteria (p. 241) (here)
2. Provide SW Project log (p. 244) (here)
3. Use questionaire (provide one early in project) (p. 249) (here)