1. | Welcome | ToC | FAQ
| Resources | Courses
| Projects | Mail
Lists | Members | Misc |
2. | Participation | Source
of Ideas | Credit/Ownership | MOST SDP | Teams
|
3. | Evolution | Roles
| Phases | Documents |
One of my favorite cartoons hung over my desk while i was in the position i described above at that company. The picture showed a room full of desks with programmers, and one guy standing at the front of the room talking to them. The caption said: "You people start programming while i go upstairs and see what they want done". That really does describe the approach taken by MANY programmers (though few of the SUCCESSFUL ones :-). For MOST Development projects, we suggest approaching the group exercizes with a bit more structure and discipline. In general, a development project should proceed sequentially through the following phases, though some of the middle ones CAN (in fact SHOULD) be done in parallel.
This area is under construction. There is enough in place to get the idea across to allow the first project team to begin to form. The pilot project teams are reminded that the information contained on this page is only a suggestion and that the team may choose to skip or combine phases listed here as appropriate to the needs of their project.
 |
Somebody gets the idea for a program they want. This person is the Product Manager (although they may not know that :-). The Prod Mgr finds someone else who is technically skilled in the related areas (assuming they are not themself so qualified) to help them with the next phase.
They investigate both whether the problem is ALREADY solved by an existing app (making a duplication of the effort wasteful) and whether it is practical to accomplish it with existing technologies and available individuals. [Example: 100% perfect voice recognition input isn't already available, but it also isn't practical to attempt... yet]. If the project IS feasible, a technically qualified Project Manager (possibly the same person ID'd in the previous phase) is assigned to assemble a team and implement it.
A team is formed to implement the project based on the feasibility studies definition of skills required and people available. The Project Manager assigns individuals to the appropriate roles for the project.
The team settles on their communications and reporting protocols to be followed throughout the project.
The team discusses the DETAILS of the requiremenst with the product manager and documents the exact functionality expected from the app. That document is reviewed and approved.
The team, led by the Project Architect, produces an architectural overview of the project. This is best presented as a picture. If you get into a lot of text, you've probably actually started High Level Design (HLD). The team reviews this for holes in the approach. This phase is sometimes combined with the next phase when the two cannot be resolved independently.
The team, led by the Project Architect, decides on tools, languages, and development environments to be used, and reviews the architectural overview of the project to ensure that implementation of the approach within this toolset is feasible.
The architecture is tackled here to provide a more specific implementation plan based on the chosen toolset. If OO, the appropriate classes should be identified and the interactions between them specified. The team should review this document to ensure that the design covers ALL requirements and corresponds to the project architecture.
The appropriate folks can now start creating the UI. This must be reviewed by the team AND approved by the Product manager. You may want some 'cool' graphics for the splash screen or the user windows, so if you have any artists on the team they'll have something to contribute as well. While some of the team is working on THIS stuff, others can be simultaneously working on:
If you can mock up a UI-only version of the app for usability testing at this point that would be optimum. Tools such as SuperCard are well suited for prototyping, and many development environments include facilities that simplify creating user interfaces, thus allowing for early usability testing. While some of the team is working on THIS stuff, others can be simultaneously working on:
The entire project is implemented in pseudocode, which is reviewed by the team for conformance to the HLD AND to ensure that all requirements are met. If doing OO work, ALL class variables should be defined as to type and all methods should be specified (including their parameters). Also simultaneously:
QA lead (and team) produce a test plan that verifies all aspects of the project, including plans to test on a variety of machines, etc.The entire team should review the plan for completeness. ALSO simultaneously:
*Somebody* has to write the user's manual. This should be available during testing.
After the LLD is finished and reviewed, this phase can begin even if TPC & Documentation are still in progress. For complex projects, this phase may be performed iteratively, building up increasing complex subsets of the final product. For simpler projects it is usually sufficient to have only one level of modules defined for the project. Each unit implementation team should translate their LLD into code, have code review that include persons not involved with the coding, and perform unit testing of their module before declaring it ready for project integration.
After the all unit implementation teams are finished, the project architect will perform integration of the project to prepare for the project testing phase.
Implement the test plan. Every member of the project team should help here. Formalize a way to *track* the bugs that are reported and verify every one of them. Do code reviews of the changes to ensure you aren't trading "Bug A" for "Bug B". For larger projects you would do an internal alpha test phase and an external beta test, but those are probably superfluous here.
Make the puppy public after the Prod Mgr agrees it's finished.
Publicize the availability of the product (as appropriate).
Copyright
© 1996, 1997, 1998. Last Update to This Page:
1998/04/29
This Page Maintained by: radar
pangaean * * * Original Author: radar
pangaean
The MOST web site is built and maintained
by the voluntary efforts/donations of our members.