Development Steps

These are the steps needed to design, implement and test a program "deliverable." A deliverable is a module, or part of a module, that implements specified functionality. The development steps needed to produce the deliverable have estimates of effort and scheduled completion dates.

Completion dates are more important than estimates. In other words, estimates are used to determine when a module should be complete. The overall project plan depends on tasks being finished on schedule. As a developer, you must keep your sub-system manager informed about anticipated changes in completion dates. By knowing that a completion date may not be met, project management may re-allocate resources or revise the schedule.

The Application Support Team consists of three roles: DB-Access (Jim Etheridge), User-Interface (Max Rahder), and Program Logic (Fredrik Pettersson). This team is involved in review steps 3 and 6. There may be cases where parts of your deliverable are re-assigned to the Application Support Team. (This will happen when some aspect of your deliverable should be implemented for re-use throughout the application.)

The "user" may be a IS supervisor or an end-user (although you should involve the end-user as much as time permits).

1. Determine requirements, scope of deliverable, effort for each step, and milestone dates
   • This task may take several hours over several meetings
   • Iterate until the estimate for each step is forty hours or less
   • Assign completion dates for each step
   • Requirements not clearly within project scope should be referred to the Applications Manager
2. Sketch implementation
   • The goal of the task is to do a high-level design of implementation details
   • This task may take from several hours to several days
   • Sophisticated implementations may have to be prototyped
   • Resolve questions and refine estimates by iterating to step 1
3. Review implementation with Application Support personnel: DB-access, UI, Program Logic
   • The goal of the task is to find opportunities for reuse, improve designs, and better enforce consistency before a lot of time is spent in implementation
   • Each review should take from one-half to one hour
   • Implementation details of use to all developers will sometimes be off-loaded to Application Support
   • Features not clearly within project scope should be referred to the Applications Manager
   • Resolve questions by iterating to an earlier step
4. Review with user
   • The goal of the task is to verify that the proposed implementation from step 2 jibes with the user's requirements from step 1
   • This review should take from one-half to one hour
   • Resolve questions by iterating to an earlier step
5. Implement the design
   • This task may take several days
   • Seek the help of Application Support as needed
6. Review the implementation with Application Support
   • The goal of the task is to ensure good program structure and reuse before time is spent unit testing the implementation
   • This task may take one or two hours
   • The review will often lead to revisions, and therefore, iterating to a previous step
7. Unit test
   • Test all program logic - i.e., all branches are tested
   • Talk to data conversion to see if conversion data exists that meets unit test requirements
   • Manually create test data as needed
   • Record information on the purpose of the different test data records to make regression testing easier (i.e., if the module is revised, the same test data should be used in the same way to re-test the module)
   • This task may take several days
8. Review the implementation with the end-user
   • A mini-user test where the developer formally demonstrates the implemented module and verifies the implementation of each requirement with the user
   • The user must formally "accept" the implementation by signing a sign-off form

-- Anonymous, July 08, 1998