CS 3 2 5

1. Managing Your Time Software Development Time Allocation When working with a firm deadline, it’s important to allocate your time wisely and to learn from your previous time management mistakes. CS 325 43 Humphrey

2. Managing Your Time Time Prioritization Recognize that some project tasks are required, while others are discretionary. In a video game, GUI design would be considered essential, while completely accurate computation (e.g., collision detection) might be considered discretionary. In an industrial CAD/CAM system, however, accurate collision detection would be required, while an optimally designed GUI might be considered discretionary. CS 325 44 Humphrey

3. Managing Commitments Biting Off More Than You Can Chew When asked to deliver complete, high-quality software in an short, aggressive amount of time, sometimes one commitment or the other must be sacrificed. Delivering low-quality or incomplete software could result in client mistrust and reluctance to continue a work relationship. Missing your scheduled deadlines might cause your client to question your competence, and might result in a cascade of schedule slippages. CS 325 45 Humphrey

4. Managing Schedules Gantt Charts A convenient tool for scheduling a software development effort is a Gantt chart. Reasonably sized tasks are listed, along with their planned calendar duration and the primary developer responsible for accomplishing them. CS 325 46 Humphrey

5. All three team members have initial four-day tasks, which should be broken into smaller tasks to facilitate effective startup. Myers is joining the project just as Zimmerman leaves it, but they only have one scheduled day of overlap, potentially making the transition less smooth. Tasks 4 and 11 begin after tasks 5 and 12, respectively, making the chronology of the schedule somewhat less clear. Anderson has a five-day task at the end of the project, which should not only be split into smaller tasks, but should not be the only active task as the project winds down. Anderson’s overlapping tasks occur just as Myers joins the project, potentially making Anderson less available to help Myers ease into the project. CS 325 47 Humphrey

6. The Project Plan Project Phases Using our process, project tasks are loosely categorized into seven (not necessarily consecutive) phases. Implement the design; document all code; integrate modules from all team members; record LOC counts and time. Describe program functions; estimate planned time & size for developing program; formally record all plans. Determine program modules; model using UML; assign modules to team members; formally record all design time. Develop unit and system test cases that include normal and extreme cases; test all test cases; document results. Study source code before compiling or testing; identify defects in own and others’ code; record review time. Compile program and identify errors; fix syntax until program compiles completely; record defects and compile time. Complete all project documents, including recording estimated and actual times and sizes; include postmortem time. CS 325 48 Humphrey

7. Defects Defect Types Each defect discovered in your project development must be categorized. CS 325 49 Humphrey

8. Defects Defect Recording Log During each (pre-postmortem) phase of the project, record the defects that you discover, indicating the phase in which they were injected, the phase in which they were removed, and the amount of time it took to fix them. CS 325 50 Humphrey

9. Finding Defects Rationale for Modeling & Code Reviews The later in the software development process that defects are discovered, the more costly it is to fix them. By expanding the design phase to include formal modeling of the planned implementation, and by including formal code reviews at the end of the implementation phase, developers aspire to eliminate most defects early in the process. CS 325 51 Humphrey