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

Modification History:

Version Date Who Comment
v0.0 10/24/2014 Cindy Harn Created Template / Empty Document
v1.0 11/19/2014 Cindy Harn Set up the tables for the Roles section
v1.1 11/21/2014 Cindy Harn Updated the tables for the Roles section
v1.2 11/25/2014 Cindy Harn Updated the tables and uploaded the other sections

Team Name: Group 8

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

Team Members:

Roles

Group Meetings / Documentation

Document Contributors
Meeting Minutes
  • Cindy Harn: created, proof-read, and maintained to keep it up-to-date and uploaded any relevant documents from meetings (100%)

Deliverables I

Document Contributors
Concept of Operations
  • Nigel Carter: filled out part of Analysis section (10%)
  • Cindy Harn: created, filled-out Operational Features and Impacts and part of Analysis and Modes section, proof-read, and maintained (50%)
  • Mathew Church: filled-out Current System and part of the Needs and Operational Features and Modes section (30%)
  • William Pearigen: filled-out part of the Needs section (10%)
System Requirements Specification
  • Nigel Carter: filled-out part of Section II (15%)
  • Cindy Harn: created, filled-out Section IV and part of Section II, proof-read, and maintained the document (35%)
  • Mathew Church: filled-out part of Section I and Section II (25%)
  • Thomas Bergens: filled-out part of Section III (10%)
  • William Pearigen: filled-out part of Section III (15%)
Project Management Plan
  • Nigel Carter: filled-out Work Packages, PERT Chart, QA, Technical Progress, and Plan section (30%)
  • Cindy Harn: created, filled-out Project Overview and Deliverables section, proof-read, and maintained the document (30%)
  • Mathew Church: filled-out Team Organization, Standards, Software Life Cycle, and Risk Management section (30%)
  • Thomas Bergens: filled-out Tools and Computing and CM section (10%)
Test Plan
  • Cindy Harn: created, proof-read, and maintained the document (20%)
  • Thomas Bergens: filled-out all four sections of the document (80%)

Deliverables II

Document Contributors
High-Level Design
  • Nigel Carter: filled-out part of Detailed Issues section (15%)
  • Cindy Harn: created, filled-out part of Design Issues section, proof-read, and maintained the document (40%)
  • Mathew Church: filled-out High-Level Architecture section (30%)
  • Thomas Bergens: filled-out part of Detailed Issues section (15%)
Detailed Design
  • Cindy Harn: created, filled-out Design Issues plus part of Detailed Design and Trace of Requirements section, proof-read, and maintained (45%)
  • Mathew Church: filled-out part of Detailed Design section (10%)
  • Thomas Bergens: filled-out part of Detailed Design and Trace of Requirements section (35%)
  • Michelle Edwards: filled-out part of Detailed Design section (5%)
  • William Pearigen: filled-out part of Detailed Design section (5%)
Presentation
  • Nigel Carter: created the CLASP Password Manager icon and the slides for the Concept of Operations and Prototype (25%)
  • Cindy Harn: created the slides for the Project Management Plan and edited and proof-read the entire presentation to ensure it's uniform (35%)
  • Mathew Church: created the slides for the High-Level Design (10%)
  • Thomas Bergens: created the slides for the Test Plan (10%)
  • Michelle Edwards: created the slides for the Detailed-Design (10%)
  • William Pearigen: created the slides for the System Requirements Specification (10%)

CLASP Product

Document Contributors
Code
  • Nigel Carter: worked on the front-end of the CLASP Password Manager (30%)
  • Mathew Church: worked on the back-end of the CLASP Password Manager (20%)
  • Thomas Bergens: worked on the back-end of the CLASP Password Manager (30%)
  • William Pearigen: worked on the front-end of the CLASP Password Manager (20%)
Quality Assurance
  • Nigel Carter: performed testing for quality assurance (15%)
  • Cindy Harn: performed testing for quality assurance (15%)
  • Mathew Church: performed testing for quality assurance (15%)
  • Thomas Bergens: performed testing for quality assurance and the test cases (25%)
  • Michelle Edwards: performed testing for quality assurance (15%)
  • William Pearigen: performed testing for quality assurance (15%)

Deliverables III

Document Contributors
Test Results
  • Cindy Harn: created, filled-out the results of the test cases, proof-read, and maintained the document (45%)
  • Mathew Church: filled-out the results of the test cases (15%)
  • Thomas Bergens: filled-out the results of the test cases (35%)
  • Michelle Edwards: filled-out the results of the test cases (5%)
User's Manual
  • Cindy Harn: wrote, proof-read, and modified the document to keep it up-to-date and relevant with the actual CLASP product (100%)
Source Code
  • Nigel Carter: cleaned and commented the source code for a more presentable download (22%)
  • Cindy Harn: created, uploaded the source code, project link, and JAR file, proof-read, and maintained the document (12%)
  • Mathew Church: cleaned and commented the source code for a more presentable download (22%)
  • Thomas Bergens: cleaned and commented the source code for a more presentable download (22%)
  • William Pearigen: cleaned and commented the source code for a more presentable download (22%)
Build Instructions
  • Nigel Carter: filled-out the Front-End Build Instructions (40%)
  • Cindy Harn: created, proof-read, and maintained the document (20%)
  • Thomas Bergens: filled-out the Back-End Build Instructions (40%)
Project Legacy
  • Cindy Harn: created, proof-read, and maintained the document (35%)
  • Mathew Church: filled-out the sections of the document (35%)
  • William Pearigen: filled-out the sections of the document (30%)
Final Presentation
  • Cindy Harn: created, wrote the requirements slide proof-read, and made sure the presentation was uniform (60%)
  • Thomas Bergens: verified and wrote the slide on the cryptography procedure (40%)

Analysis

Assessment of the Quality of the Final Product

The final product is a 100% functional client-server application. We have yet to find a test case that breaks or crashes the program. The entire group is very satisfied with the final program because of its effectiveness and reliability. The program does require Java 7 and a stable internet connection to work.


Recommended Use of the Final Product

Recommended use would be for a client who has a large number of accounts across a multitude of sites and locations. Our password manager allows the client to store them all in one, portable place that is completely secure. Since the passwords are stored on a server, the client will be able to access their database from any machine with an active internet connection and the desktop application installed.


Known Problems

Text fields should be empty upon logout, but as of now it remembers the last user. Furthermore, the error handling could be more specific and the formatting for Linux could be better.


Adherence to Project Plan

Our financial project estimates were right on. We estimated that we would have no financial cost and we did in fact have no financial cost. The project took longer than we had estimated due to responsibilities from other classes and work. In addition, we had some members who did less work than they were assigned and required other members of the group to pick up the slack, which required more time than anticipated. Also the prototype model worked perfectly with the way we developed the final program. It started out as a user interface with the data stored locally and then slowly evolved into the client user-interface with the server database with full encryption implemented.


Defect Analysis

A big defect noticed early on in the development phase was the inability to safely recover passwords. To allow recovery of passwords, the master passwords would be stored on the server in a decryptable format because the keys to those passwords would also be stored on the server. The group resolved this conflict by opting for more security and just removing the functionality from the final product.

Another defect that was noticed during the QA phase was the main server hard disk failing. This was solved by moving the database to the amazon.aws ec2 instance. Furthermore, all references to the old server in code had to be changed to the new server. After the changes were made the defect was resolved.

Other small defects were present but nothing outside of the usual programming syntax and grammatical errors.


Quality Assurance

Testing activities proved to be very extensive and quick. Since we have placed constraints on most of the textboxes, most of the instances that could cause a crash had been covered. Based on the test cases provided above, we have checked for the obvious reasons for a crash, such as internet connectivity, incorrect credentials, and foul play.


Configuration Management

Github worked for the most part. It was wonderful to manage the various versions of code so simply. The issues function of github was utilized as a to-do list for the group. Not only did it contain fixes that needed to go into the code, but it also held functionality that still needed to be added to the code. On the other hand, the group had several issues when pulling and pushing from git. Several times the .classpath would not be ignored resulting in dirty tress and hard resetting before being allowed to pull and push again.


Suggestions for the Future

To improve the technical process of the group, we recommend more common face-to-face meetings and a more organized assignment of tasks to group members. In the future, planning is one of the most important pieces. Milestones are very useful, for example, knowing you want to have a prototype finished and ready to present by a certain date is a good goal to work up to. If the project was 10 times or 100 times bigger, the planning and assignments would have to be much clearer and communication would have to be much higher. It is easy to step on one another's toes and get in the way on source code when there is a lack of information.

This page last modified on November 25, 2014.

Please do not reproduce this page.