Project Management Plan
Project Overview
The goal of this project is to provide a web application which allows users to find other users within the UCF campus community interested in organizing and playing sports on the various courts and fields of the UCF campus. Users can schedule games, find people, and get notifications when a new game is created. This allows people on campus to play a pickup game whenever their schedule permits it. This web application aims to make finding pickup games on campus for various sporting events an easy process.
Reference Documents
- Concept of Operations
- Test Plan
- Software Requirements Specification
Applicable Standards
- Coding Standards
- Document Standards
- Artifact Size Metric Standard
Project Team Organization
- Group Members
- Tyler Dixon - Database Design/Support Graphic Design/Support Developer
- Patrick Delva - Project Manager/Supporting Documentor/Support Developer
- Zachary Kirby - Lead Documentation Manager/Support Developer
- Alex Horan - Graphic Design/Support Developer
- James Choi - Lead Developer
Webcourses Discussions will be used for communication of complex topics, ideas and code snippets. GroupMe application will be used for short/quick communication between the group. Google Docs will be used for editing documents. Weekly meetings will be held over teleconferencing applications such as Google Hangouts.
Deliverables
Artifact | Due Dates |
---|---|
Meeting Minutes | Weekly |
Individual Logs | Monthly |
Team Reports | Monthly |
Concept of Operations | June 12th |
Project Management Plan | June 12th |
Software Requirements Specification | June 12th |
Test Plan | June 12th |
High-Level Design | July 3rd |
Detailed Design | July 3rd |
Test Results | July 31st |
Build Instructions | July 31st |
User’s Manual | July 31st |
Source Code | July 31st |
Software Life Cycle Process
Tools and Computing Environment
- Operating Systems
- OS X 10.9.3+ , WIndows 8.1, iOS, Android
- Programming Languages
- Javascript, PHP, HTML, SCSS(CSS), mySQL
- Libraries
- jQuery, encryption for login
- Frameworks
- Optional FuelPHP, Laravel, Symfony frameworks.
Configuration Management
We will be using Git version control protocol through a GitHub Organization account, which all members have read/write access to, for managing the source code to the application. All team members on the team will make contributions to the project by creating a branch from the master branch (ie make a copy of the master copy of the source code) of the repository and making changes to it (“committing” at every minor milestone) to implement required features of the application.
When a team member believes that the copy of their code is good enough to become part of the master copy (merge), they will have to submit a “pull request” through the GitHub application. Peers will see this “pull request” and accept it through the GitHub application where it is then available for testing on the peer’s computer. The peers will test/review the team member’s code and upon agreement between members, the copy will be “merged” into the master branch. Bug reports can be filed and documented through the GitHub website. Resolution to the bugs can also be filed through the site as well.
Using this system, all aspects of source code management history will be self documenting, and any catastrophic additions to the project source code can be reverted and averted.
Quality Assurance
- The team will perform stress testing on each unit of code that is meant to perform a particular purpose as each deliverable is released. Patrick Delva will perform all testing.
Risk Management
- Time Management
- Beforehand scheduling
- Completion of Tasks
- Prioritization based on criticality of functionality
Table of Work Packages, Time Estimates, and Assignments
- Graphic Design
- 2 weeks (Tyler Dixon, Alex Horan)
- Front End Development
- 4 weeks (James Choi, Alex Horan, Zak Kirby, Tyler Dixon)
- Back End Development
- 4 weeks (James Choi, Patrick Delva, Alex Horan)
- Database Design
- 1 week (Tyler Dixon)
- Documentation
- 8 weeks (Patrick Delva, Zak Kirby)
Technical Progress
Metrics | Measure |
---|---|
Requirements Phase | |
Number of Requirements | |
Number of Requirement Changes | |
Specification Phase | |
Number of Specifications | |
Number of Specification Changes | |
Design Phase | |
Number of Packages Added, Deleted and Changed | |
Number of Classes Added, Deleted and Changed | |
Number of Methods Added, Deleted and Changed | |
Implementation | |
Number of Packages Added, Deleted and Changed | |
Number of Classes Added, Deleted and Changed | |
Number of Methods Added, Deleted and Changed | |
Lines of Code Added, Deleted and Changed | |
Number of Test Cases Added, Deleted and Changed | |
Integration | |
Number of Test Cases Added, Deleted and Changed | |
Number of Defects |
Plan for tracking, control, and reporting of progress
Each Thursday a meeting between group members will take place to discuss group individual goals and progress towards each phase. Meeting notes and length will be collected and given to the Project Manager. This will be done for purposes of preparing a project management report which will be delivered to the team privately for the checking of project status and progress.
Monthly, all developers will provide a technical document describing their progress of their work packages for metric data and milestone confirmation. QA assessment will be done with each project release and will contain stress tests for all modules within the code as decided by the lead developer. Reports will be handled through the completion of phase documents and their submission to the professor and TA.