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

Project 0verview

Reference Documents

Applicable Standards

Project Team Organization

Deliverables

Software Life Cycle Process

Tools and Computing Environment

Configuration Management

Quality Assurance

Risk Management

Table of Work Packages, Time Estimates, and Assignments

PERT Chart

Technical Progress Metrics

Plan for tracking, control, and reporting of progress


Project 0verview

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.


Reference Documents


Applicable Standards


Project Team Organization

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.


Deliverables

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


Software Life Cycle Process

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.


Quality Assurance

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.


Risk Management

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


PERT Chart

Please see detailed GANTT chart below

 


GANTT Chart

Project Management Plan GANTT Chart

 


Technical Progress Metrics

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