SmartCAL
Project Management Plan
COP 4331, Fall 2014
Modification history:
Version |
Date |
Who |
Comment |
v0.0 |
9/06/2014 |
Salim C. Andraos |
First version of the project management plan |
v1.0 |
10/24/2014 |
Salim C. Andraos |
Fixed some bugs. Revised Risk Management section |
v2.0 |
|
|
|
Team Name: TEAM1001
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
Weekly planner is a learning easy-to-use software for the users who want to plan their week easily and improve their choices. The users of this application are able to enter their weekly schedule, see current state of their schedules with different view choices or can put reminders for important events. The users can also select spare times that they are available for multiple suggestions. Furthermore, the users are able to rate their latest activities and the application always stores the history of users in a database for later use. The main idea of this project is deciding which activity the user may desire as activities for specific times. For example, based on the history of a user, the food choices of the user and day of the week, the application should come with a suggested place and food for lunch. The application should also compare the user with other users and find similar users. This feature helps for new suggestions available to the users.
The team is comprised of Salim Andraos, Joseph Burfield, Sacchin Nayee, Paul Perdue, and Carlos Pereda. As Carlos is the most mature team member and is only taking two classes, he was elected to project manager by the group. Not to mention Carlos has previous software development experience.
As far as other duties go, jobs will be divided evenly between all team members. Exposure to all aspects of the software development life cycle to all team members is very important to this group. The group website and the collaboration website was initially https://andraos.visualstudio.com but later switched to GitHub. Both are maintained by the group as a collaborative effort. Communication is done via email until the team is further into project which then will switch to collaboration website.
Artifact |
Due Dates |
Meeting Minutes |
Meetings are held every Tuesday at 12:00 |
Individual Logs |
Each week a new log is added and is available for viewing from the homepage. |
Group Project Management Reports |
N.A. Please see weekly logs. |
ConOps |
September 18, 2014 |
Project Plan |
September 18, 2014 |
SRS |
September 18, 2014 |
High-Level Design |
October 23, 2014 |
Detailed Design |
October 23, 2014 |
Test Plan |
September 18, 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 |
This team is adapting the agile software development model
for its solution. Frequent delivery of small increments of working software
is the goal. All requirements and solutions evolve through collaboration between
all team members.This team is following the Waterfall model. Since we are
on a preset schedule arranged by the intructor and the requirements and specifications
were clear from the onset, waterfall model is aplicable. Furthermore, there was no
need to go back and revise any of the stages.
Tools and Computing Environment
We are using Visual Studio as our IDE, C# as our language,
and most likely SVN GitHub as our software versioning and revision control system.
The reasons for choosing Visual Studio and C# as our language and IDE are
ease of integration and synchronization between Microsoft Project,
Visual Studio, and Visio. Furthermore, collaboration between Visual Studio
and our collaborative website is further enhanced. Also, Visual Studio's
outstanding GUI builder should ease the UI design phase.(see above)
Configuration Management
Each team member is responsible for all changes made to each document. Changes to a document and source code shall be clearly noted in the document itself.
Since the work is divided evenly between all team members and this team intends to expose all its members to all aspects of the development life cycle, each member reviews each document. This has two purposes: 1) Quality Assurance is guaranteed throughout the life cycle since each document gets reviewed by six people, and 2) all team members get to see the workings of each document.
There are many unanticipated events that can occur during the life cycle
of a project. In risk management we make an effort to expect and plan for
each of the predicted scenarios.
There are two factors that can be affected by risk on a school project. The people on the team and the code itself. Since all the code is in the cloud, there is no risk of losing any of the source code. Which is why we notice that the listed risks all involve team members. We have to deal with these risks individually. If we lose a team member, and that team member was currently working on a component of the project, then the rest of the team has to take over and distribute the work load evenly. If the team or team member is unfamiliar with the language or any of the tools used, then a team member familiar with the tool holds an instructional session on the weekend to familiarize the members with the language or tool. The third risk, a team member slacks, shall be treated as if it was a loss and the other team member pick up the slack.
Table of Work Packages, Time Estimates, and Assignments
Please see detailed GANTT chart below
Please see detailed GANTT chart below
Project Management Plan GANTT Chart
Each phase is appropriately divided into deliverables. We shall use the due dates (i.e. days) for our deliverables metrics and as per the industry standard use bytes, instead of lines of code, as our metrics for coding.
Plan for tracking, control, and reporting of progress
The project manager will post the following information weekly: group time and activity log, status information, issues and problems, and group defect log.
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, 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: 1 sentence description of overall status, 1 or 2 sentence of any planned changes to the project plan, graph of planned vs actual time, graph of planned vs actual for each technical progress metric, and update the GANTT chart."
Template created by G. Walton (GWalton@mail.ucf.edu) on Aug 30, 1999 and last updated Aug 15, 2000
This page last modified by Salim C. Andraos (andraos@knights.ucf.edu) on October 24, 2014