Project Management Plan Template

The basis of the project as a whole is to create a computer based soccer team that can perform on the level of a human soccer team. The team will contain all the components of a real soccer team, including forwards, midfielders, defenders, a goalie and also a coach. Several different groups are working on each of these parts separately. More specifically, our part of the project entails the design and implementation of the forwards of this soccer team. The forwards will behave in an organized manner, and will behave like 'real-life' forwards. In this case, this entails acting as the offensive of the team. Once basic implementation is completed the forwards may also be able to run plays and other more complicated behaviors.

Reference Documents

Applicable Standards

Coding Standard: All coding implementation for this project will be done in C++. Any modifications that will be done will be commented in our specified format. Variable names and function names will be used consistently, and any other new functions or variables will be named in a similar fashion.
Document Standard: The documentation will include a team webpage with links to all the pertinent documents, such as the concept of operations and software requirements specification. Fonts and their sizes will adhere to basic html. The headings used in the various reference documents will use the template headings. Version history will be updated accordingly as additional information is available. The team members names will be listed in the version history, everywhere else we would be referred to as Killer Forwards which is the team name, or just simply team. Figures will be drawn in DIA, a linux based diagram creation tool.

Project Team Organization

The project team consists of Kip Carr, Kristen Cannava and Rob Pescatore. Everyone will be working on the documentation artifacts together. This ensures agreement amongst the team members of their contents. Updates will always be done with the consent of the other team members. Updating the team website will be done in alternating fashion, however the team website will always be kept on Kip Carr's ftp server. Communication is done on a regular basis. This involves lab team work, hallway conversations, as well as email. As a team we are contact on a daily basis and setting up meetings is not necessary ahead of time.

Deliverables:

Artifact	Due Dates
Meeting Minutes	Applicable only if team member is absent from meeting. To be done the day after meeting takes place.
Individual Logs	N/A
Group Project Management Reports	As progress is made, or a request from customer, a GPMR update will be produced.
ConOps	Initial update complete. Additional information or progress will warrant updates.
Project Plan	Initial update complete. Additional information or progress will warrant updates. As work on actual implementation begins, better estimates of the timeline will be available.
SRS	Initial update complete. Additional information or progress will warrant updates. Requirements are unlikely to change, however.
High-Level Design	Initial update complete. Additional information or progress will warrant updates. Implementation of the high-level design may vary as more progress is made and actual code is designed.
Detailed Design	Detailed Design information is sparse at the moment, as we do not have access to the initial player class. Design Issues will be addressed as they are found.
Test Plan	Testing is not in the near future. Code has not been designed as of yet.
User's Manual	A user manual will be created via the template once it is designed and tested. There should be minimal instruction, due to the fact that an executable will be the main deliverable.
Final Test Results	These results will be obtained once the code has been completed and we are able to test it under the exact circumstances that it is expected to run under.
Source, Executable, Build Instructions	Build Instructions will be available once the functions are designed and implemented. As of yet, we are only designing at a high-level, and this information is not yet available.
Project Legacy	Legacy information will be obtained upon completion of the project.

Software Life Cycle Process

We will be following the spiral method of the software life cycle. Here is the diagram of one iteration of the cycle.

Tools and Computing Environment

The software will be developed under the Linux OS. C/C++ will be used as the main language that this software will be developed on. The gcc compiler will be used in order to compile and find errors. Basic C++ libraries will be utilized, in addition to any communication packages that are necessary.

Configuration Management

All group members will be present for 90% of the changes being done to the code. This allows for minimal version conflict and helps to keep things consistent. No individual group memeber will be responsible for version and change control. We are all going to be organized and have consistent enough meetings to where changes are not made without the consent of the other group memebers. These same standards will apply to the changes made to document artifacts to ensure consistentcy and reliablilty.

Quality Assurance

Quality Assurance will be an ongoing process for this project. It's best to continue to check the reliablity of the software as it is developed rather than wait till the very end and find many errors originating from various areas of the code. The quality of the project will be tested function by function within the code itself. If one certain function or portion of the code is not functioning it will be found soon after its design and can be corrected at this point. As the code becomes more complex and more and more functions rely on the other systems, Quality Assurance will be ramped up appropriately. A log or an update to the Project Management report will properly document Quality Assurance as the project progresses.

Risk Management

There are not many associated risks involved with this project. As of now at the high-level design phase, forseeable risks are ensuring we understand all the standards that are imposed upon the project. These are imposed by the Robocup as well as the customer.

Table of Work Packages, Time Estimates, and Assignments:

Code Work Package:

The finished code work package is expected to be completed by or near the end of the semester. All team members are responsible for the completion and delivery of a functioning code package.

Documentation Work Package:

The complete documetation work package is also expected to be handed in at or near to the end of the semester. This includes all necessary updates as progress is made throughtout the project. All team members are responsible for delivery of a complete documentation package.

PERT Chart

Technical Progress Metrics

Requirement Analysis Phase:

For the requirement analysis phase the Concept of Operations and the Software Requirement Specifications documents have been completed. Further updates to either will be done as necessary during the following phases.
Initial requirement analysis is complete, 22 requirements so far have been completed. Final updates will coincide during development of other phases.
This phase will truely be complete when the Software Requirement Specifications and Concept of Operations properly reflect our final design requirements.

Design Phase

For the design phase initial high-level design has been completed. We have completed one UML diagram as well as a functional diagram for the high-level design.
Further, more detailed design must still take place in order for this phase to be complete. A complete knowledge of the basic functions and methods needed should be obtained before moving on to the next phase.

Implementation

The implementation phase has not yet been reached, therefore nothing pertaining to this phase has been completed as of yet.
The completion of this phase will involve complete implementation of everything that has been designed in the previous phase.

Testing

The testing phase will begin once all of the necessary requirements and designs have been implemented.
Performance metrics for this phase will be the program running consistently, as well as being able to communicate with the robocup server in a stable fashion. The code must also run error free along side the rest of the teams clients.

Plan for tracking, control, and reporting of progress

During each phase, status updates will be done on a regular basis. As major milestones are met, updates will be made to appropriate documents. In addition to milestones, changes and complications may also warrant the editing of various documents.

For the tracking of progress during the various phases, meetings will be held on at least a weekly basis. These meetings will be held to discuss progress made thus far as well as furthering progress in that particular phase. These meetings will be held on such a regular basis, that a need for separate reporting of progress is not necessary. If a member is absent from these meetings, the results will also be posted onto the main team webpage.

Template created by G. Walton (GWalton@mail.ucf.edu) on Aug 30, 1999 and last updated Aug 15, 2000

This page last modified by Rob Pescatore (E-mail) on February 3, 2004