Unless all members of the project are highly motivated to follow a rigorous software process, it is likely that a standard waterfall process would fail. For initial development, the process should focus on the elements that are needed to make it easy for new members to contribute to the project while achieving a high-level of quality with our work.
To enable new members to join and contribute, additional effort needs to be placed on documentation and testing. Tasks must also be well-defined and manageable so that they can be accomplished in the spare time available by project members.
Another issue to watch closely is the overall interest level of the group. It is crucial that the project remain focused on tasks that people want to do or it will fail. This project plan should be updated over time to ensure that it is accurately tracking the desires of the development team.
After an initial product has been developed, released and is shown to be relatively stable, a more rigourous software development model might be more appropriate and should be reviewed then.
The project team is made up of individuals filling the following roles.
| Role | Responsibilities |
|---|---|
| Project Coordinator | Responsible for the overall project goals and direction; facilitates e-mail discussions and coordinates activities of the project team. |
| Programmer | Responsible for the design and implementation of software. |
| Tester | Responsible for the validation and verification of code produced by programmers. |
| Technical Writer | Responsible for writing API documentation and developing examples. |
| Webmaster | Responsible for the website organization, structure, and design; |
The following project team members have been assigned to these roles as follows:
[This subsection should contain a high-level Work Breakdown Structure, itemizing the tasks, by phase, to be performed. Identify the project team member and/or role assigned to each task.]
[For discussion: what should we do to control the scope of the project? How do we want to capture requirements and approve modifications to those requirements?]
[For discussion: What kind of poicies do we want to have to identify, track, and release deliverables? Define naming conventions. What expectations can a user have for backwards compatability?]
[For discussion: Would status tracking be useful for members of the project? I am willing to gather information and collect it together into a report on a regular basis.]