CLASP Password Manager
Project Management Plan
COP4331 - Processes for Object Oriented Software Development - Fall 2014

Modification History:

Team Name: Group 8

Team Website: http://www.cs.ucf.edu/courses/cop4331/fall2014/cop4331-8/

Team Members:

• Nigel Carter (therealnigel@knights.ucf.edu)
  
• Cindy Harn (charn@knights.ucf.edu)
  
• Mathew Church (matchurch@knights.ucf.edu)
  
• Thomas Bergens (tjbergens@knights.ucf.edu)
  
• Michelle Edwards (michie@knights.ucf.edu)
  
• William Pearigen (wapmon@knights.ucf.edu)
  

Contents of this Document

Project Overview
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 Overview

The project is to create a secure password manager, that stores multiple passwords per user. The purpose of the password manager is to assist the user in managing their passwords in a secure and safe way that is easily accessible at any given time and on multiple platforms. These devices may include a local desktop, smartphone, or tablet. Thus, the system encrypts the passwords using high levels of sophisticated cryptography and implements the common main functionalities of a password manager. Examples of main functionalities encompasses the addition or editing of password entries, categorizing the information, using a master password if needed, and so on so forth.

Reference Document

Concept of Operations

Application Standards

Coding Standard: This organization will be expected to conform to the accepted use of grammar and whitespace for all coding involved in the project. Furthermore, most of the artifacts will be coded using standard libraries found in the Java API. Every module created will be commented and coded in such a way that it is reasonably understandable to every stakeholder of the project.

Document Standard: The members of this organization will each be responsible for his or her individual web-page. The rest of the project documentation will be carried out and delivered in a responsible and complete manner and the responsibility for said material will be divided evenly across all six members of the organization.

Artifact Size Metric Standard: The organization will only tolerate a maximum file size of 1MB per class file of the project and a project size of no greater than 250MB. This will be measured by the Windows OS. The maximum lines of code per module will be no greater than 500 unless deemed justifiable by the other members of the organization. This will be measured by the total lines of code listed in the Eclipse development environment minus the whitespace.

Group Standard: The organization will be expected to meet at least once a week to discuss the progress of the project and the current roles of the members within the organization. Any decisions that are needed to be made about the project will be discussed and decided upon. Any member may be absent from a meeting if they have a reasonable reason.

Project Team Organization

Team Members:

• Nigel Carter (therealnigel@knights.ucf.edu)
  
• Cindy Harn (charn@knights.ucf.edu)
  
• Mathew Church (matchurch@knights.ucf.edu)
  
• Thomas Bergens (tjbergens@knights.ucf.edu)
  
• Michelle Edwards (michie@knights.ucf.edu)
  
• William Pearigen (wapmon@knights.ucf.edu)
  

Responsibilities: The democratic approach will be taken for this project, allowing multiple people to function as project managers, quality assurance testers, programmers, architects and designers, documenters, and etcetera. As a result, each team member will be held equally accountable and knowledgeable for each aspect of the project.

Communication: Communication will be performed through WebCourses, e-mail, and in person.

Deliverables

Software Life Cycle Process

The organization will be implementing the Prototype model for the lifeline of the project. The major phases will include:

• Obtain System Requirements - includes meeting with the client as much as possible before starting high level design to make sure all requirements are clear to both parties


• Build a Prototype - includes high level design that will fulfill most of the requirements


• Test Prototype - includes testing most current prototype against the requirements of the client


• Determine if System is Adequate - If the system fails testing then it goes back to the Build step; if the system passes all testing it will be submitted to the client for further testing


• Deliver Product - If the system has passed all requirements it is delivered to the client for further testing and use

The rationale behind the Prototype model is that it will allow for design testing, and allow the client to see the project in progress so that they may suggest changes or alterations. The Prototype model lends itself well to this project, as many of the features are on the backend (and hence invisible to the client). Through the use of multiple prototypes, the client can see progress in the project, and can have a usable though feature-incomplete product that allows the client to experience the main features and judge accordingly.

Tools and Computing Environment

Windows will be the preferred operating system. The coding will all be done in the Java programming language.

Configuration Management

Version control and change control will be handled with Git and Github. Each member in the group will be held responsible for any of the updates to the project source, and the integrity of the project will be maintained by the entire group.

Quality Assurance

This group will be using unit testing for QA purposes, and it will be done throughout the progress of the artifact (at least once a week). The project manager for each artifact will be responsible for ensuring that the unit testing is completed. The results will be reported in the Project Management Reports that must be done at least once a week.

Risk Management

Potential risks can include members of the team becoming sick and missing meetings, or possibly dropping out of the course. For each risk, these will be managed in such a way that the loss of a member will not affect the progress towards the completion of the project. This will be accomplished by carrying out the concept of where multiple people will be held responsible for the artifacts, and can easily fill in a missing member. There could also be conflicts in things like programming languages or compilers or even overall goals, which will be managed through the conduction of team meetings or other means of communication.

Table of Work Packages, Time Estimates, and Assignments

Web Service (72 person-hours)

• Database Control (24 person-hours)
• User Management (24 person-hours)
• Encryption (24 person-hours)

Database Setup (4 person-hours)
Desktop Application (72 person-hours)

• User interface (24 person-hours)
• Encryption Handling (24 person-hours)
• Network connection (24 person-hours)

PERT Chart

Technical Progress Metrics

Requirements Phase:

• Number of requirements (at least 10 solid requirements)
• Number of requirements changes (should revise at least 5 of the requirements)

OO Analysis and Design:

• Number of UML diagrams (one per system)
• Each class under 500 lines of code

Coding Phase:

• Memory (under 250MB)
• Execution speed (no more than 3 seconds to retrieve passwords)
• Number of classes (approximately 5 per work package)

Plan for Tracking, Control, and Reporting of Progress

Each week, all team members will update their individual information, including:

• Individual time
• Individual activity log
• Individual status information
• Individual issues and problems
• Individual defect log

Each week, all project managers will examine the logs and technical content produced up until that point, as well as examine progress and QA results to estimate project risk. If necessary, actions will be taken to lower the total risk.

The project managers will work together to create a Project Management Report at least once every two weeks, containing:

• A description of overall status (minimum one sentence)
• Planned changes to the project plan (one to two sentences)
• A graph comparing planned progress vs. actual progress according to each progress metric
• Updated PERT chart

This page last modified on October 21, 2014.

Please do not reproduce this page.