Robocup Midfield Lab 2
Project Management Plan
EEL4884, Spring 2004
Modification history:
|
Version |
Date |
Who |
Comment |
|
v0.0 |
08/15/00 |
G. H. Walton |
Template |
|
v1.0 |
February 3, 2004. |
Group |
Baseline |
Team Name: Midfield Lab 2
Team Members:
Contents of this Document
Tools and Computing Environment
Table of Work Packages, Time Estimates, and Assignments
Plan for tracking, control, and reporting of progress
The goal of this project is to have a fully functional Robocup midfielder client by the end of the semester. The Robocup initiative has as its goal creating artificially intelligent soccer players that can compete against humans by 2050. Our player(s) will be realized totally in software, there will be no mechanical parts. As a consequence of creating a midfielder client, we should also gain valuable experiance in planning and executing a fairly large software project. There will also be gains in programming and AI knowledge in general. Our midfielder client will interface with clients created by other groups in the lab, with the ultmate goal of having a team that can play effectively together.
Our group consists of Marshal Blessing, Jimmy Secretan, and Jesse Rome. For now, the responsibility of project management will be shared by all group members. All artifacts will be completed by the group as a whole, although individual sections might be split up. Functional sections of the code will have seperate managers, who will be determined once the project is further along. The website will be maintained by Jimmy Secretan since it is on his webspace.
Communications between group members will take place at the scheduled lab meetings, and through e-mail as necessary. Additional ad-hoc face-to-face meetings will take place as needed.
Deliverables
Artifact Due Dates Meeting Minutes TBA Individual Logs TBA Group Project Management Reports TBA. ConOps January 20, 2004. Project Plan February 10, 2004. SRS February 3, 2004. High-Level Design February 10, 2004. Detailed Design February 17, 2004. Test Plan March 2, 2004. User's Manual TBA Final Test Results March 16, 2004. Source, Executable, Build Instructions TBA Project Legacy TBA
Our group plans to follow the spiral model for software design.
This iterative approach will allow us to go back and correct problems that are
found after an artifact has been thought to have been completed.
Tools and Computing Environment
Configuration Management
Modules will be produced individually and compiled together at group meetings. New versions will therefore be released roughly every week, with a set of previous versions stored in a safe location. Updates to the primary source code will only be made in the presence of all group members, or when all group members have given permission for it to be updated.
Quality assurance will be performed for each module by each module's respective manager. When the modules are finally integrated, all participants will be involved in producing test cases to ensure quality.
Risk: Inadequate programming experience.
Solution: Obtain
reference material for programming.
Risk: Inadequate AI
experience.
Solution: Keep AI relatively simple, make use of reference
material.
Risk: Incorrect or unmanageable system design.
Solution:
Weekly evaluations of progress and system manageability.
Table of Work Packages, Time Estimates, and Assignments
Software Requirements Elicitation:
Project Administration Planning:
Design:
Implementation:
Testing:
Specification Phase:
Number of specifications created.
Number of bugs in code.
Number of bugs removed from code.
Ratio of successfully completed test phases to unsuccessfully completed test phases.
Number of practice games completed as part of a team.
Plan for tracking, control, and reporting of progress
Each week the group members will meet face-to-face in order to discuss the status of their individual tasks. Progress will be evaluated by the group as a whole , in a peer-review type manner. Any problems will be discussed and possible solutions explored.
Each week the current status of the project will be posted on the group website. Group members will compare the current state of the project to the projected project status and identify and correct any deviations. An action plan will be formed for the next week, based on the assesment of current progress.
Template created by G. Walton (GWalton@mail.ucf.edu) on Aug 30, 1999 and last updated Aug 15, 2000
This page last modified by Jesse Rome (je458125@pegasus.cc.ucf.edu) on February 5, 2004.