Challenge Your Friends
Project Management Plan
COP4331 Processes in Object-Oriented Programming | Fall 2014 | Group 12 - Project 17
Modification history:
|
Version |
Date |
Who |
Comment |
|
v0.0 |
08/15/00 |
G. H. Walton |
Template |
|
v1.0 |
9/15/2014 |
Christopher Kovaleski |
Basic creation of the deliverable |
|
v1.1 |
9/17/2014 |
Christopher Kovaleski |
Gantt chart created and added to the template |
|
v1.2 |
9/18/2014 |
Christopher Kovaleski |
Final update for Deliverables 1 |
|
v2.0 |
11/16/2014 |
Alan Birmaher |
Overall update and clean up to the page |
Team Name: The Spungos' Turbo Wall-Hacks
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
Challenge Your Friends is an Android application with a simple objective, creating and sending challenges to friends over social media. By way of Twitter, a user is able to send a challenge that is trending to other users of the application or create their own challenges via a simple rules generator. Upon creating a challenging or challenging a fellow user, the recipient will receive a notification through Twitter detailing how long they have and how many people they have to challenge upon completion.
The code will follow a naming convention as specified in the standards of Android development and will use the Git version control system for all code. The minimal acceptable standard will be in compliance with the Android development standards, including camelCase for non-global variable names. Variables names will strictly consist of alphanumeric characters, no symbols. Documentation for different classes will make use of javadoc comments to specify their uses, parameters, and returns.
Android Standards - here
Java Standards - here
All documents will use the templates found here - including the predefined font sizes, spacing, and headings. A table of contents will have links to all applicable sections of the document. All documentation will be standardized in the HTML format, with submissions being completed by compressing the deliverables into a .RAR file. All documents will have a link to the primary project team page, which will consist of links to every piece of HTML documentation written by our team.
Changes in the documentation will be documented in the modification history of the page being changed. This section will list version number, the name of the person making the change, the date changed, and a brief summary of these changes. The version number will be incremented by 0.1 for minor changes and will be incremented to the next whole number for major changes. With this said, 1.3 would become 2.0 after a major change or 1.4 after a minor change. Changes will be track-able through Git. In addition to this, spell checking will be at the responsibility of the individual making changes to the documentation. We will attempt to follow the IEEE documentation guidelines for Software Engineering located here to the best of our abilities, although this is not considered a "hard requirement" as this level of documentation takes many months of study to learn.
The size of a section of the project will be measured in the number of expected hours that a part of the project will take to complete. Breaking down specific tasks into minimal parts, giving each one an expected time frame and percentage of the overall task, will allow the project manager and team as a whole to measure the progress of the task at hand.
NOTE: Our team is expected to follow to the letter any standards listed in this section.
Group 12 consists of 6 individuals in the COP4331 class. These individuals are to perform the tasks of this project in nearly equal amounts of work for each task as it is important to the development of each student to partake in work in all aspects of the project from start to finish. While every member will have a prominent role in each aspect of the project, members have been given a primary responsibility to perform during the course of the development. These primary jobs are as follows:
|
Artifact |
Due Dates |
|
Meeting Minutes |
2 hours on Friday each week |
|
Individual Logs |
Updated by Sunday on a weekly basis |
|
Group Project Management Reports |
Provided in weekly team logs by the Project Manager, each Sunday |
|
ConOps |
September 18, 2014 |
|
Project Plan |
September 18, 2014 |
|
SRS |
September 18, 2014 |
|
Test Plan |
September 18, 2014 |
|
High-Level Design |
October 23, 2014 |
|
Detailed Design |
October 23, 2014 |
|
User's Manual |
November 25, 2014 |
|
Final Test Results |
November 25, 2014 |
|
Source, Executable, Build Instructions |
November 25, 2014 |
|
Project Legacy |
November 25, 2014 |
The team will use an implementation of the Agile development model, due to its reliance on daily interactions and small deliverables at set times. The agile model is resistant to minor changes in the specifications throughout the development process and this will be important as we meet throughout the semester. Since our group as a whole is learning development, the agile platform provides a forgiving model as long as the due dates are upheld.
Tools and Computing Environment
Configuration Management
Any changes made to any document, source code, or any part of the project will be done with the consent of the entire team. This can be achieved as the group is in constant communication with each other. Tasks will be assigned and responsibilities concerning which documents/code will be updated by each person will be made clear to each member of the team. Also, any of the changes made will be clearly stated on the updated document or source code itself.
As this is a learning experience for each of our team members, each one of us will be responsible for reviewing each document, as well as assuring the quality of our application is up to par with our applicable standards. Having all six members review each part of the project allows for thorough inspection leading to greater overall quality.
The primary potential risks are discussed in the Concept of Operations, please refer to that
document for the most current risk factors at hand.
Table of Work Packages, Time Estimates, and Assignments
View the Gantt chart below for current table of work packages. At the current time there is not a finite understood number of tasks from start to finish, so for this reason we have included up through our meeting for project deliverables 2. During this meeting, new dates will be added and time allocated based on what we learned in time management while completing deliverables 1.
As stated in the previous section, our group chose to use a Gantt chart for project management due to the restrictions and reasons listed prior.
In this stage of the project, we are currently using consistent team meetings to determine the time in days expected for each individual part of the project. As we begin prototyping, we will have a better understanding of how different metrics will come into play. One that we are particularly looking into is RAM efficiency of the program. We are putting check marks on the Gantt chart in order to verify that our planned timings coincides with our actual finish dates.
Plan for tracking, control, and reporting of progress
Each team member will post the following information weekly: individual time and activity log, individual status information, individual issues and problems, and individual meeting points.
Each week, the project manager will: read and analyze the logs; examine the technical content of the work done to date; examine the technical progress metrics; consider the QA results; reassess the potential project risks; and take corrective action if necessary.
The project manager will issue a Project Management Report on the schedule as indicated in the deliverables section above. At a minimum, the Project Management Report will be generated every two weeks and will include the following information: Overall status, work in progress, items not on track, talking points for meeting. This will coincide with an updated Gantt diagram.
Template created by G. Walton (GWalton@mail.ucf.edu) on Aug 30, 1999 and last updated Aug 15, 2000
This page last modified by Alan Birmaher on 11/16/2014