1.1 Project Overview
Project Objectives: Create an eWallet system where a smart card which can hold information for driver's license, credit cards, cash balance, medical information, and more. Create software for supporting systems.
Product to be Delivered: Functional eWallet smart cards and supporting software.1.2 Definitions, Acronyms, and Abbreviations
Term Definition C++ a general-purpose programming language closely associated with the UNIX operating system eWallet Electronic Wallet HTML a set of tags and rules (conforming to SGML) for using them in developing hypertext documents; hypertext markup language Java programming language designed to develop applications, especially ones for the Internet, that can operate on different platforms SDS Software Design Specification SRS Software Requirement Specification SQL an industry-standard language for creating, updating and, querying relational database management systems; structured query language VVP Verification & Validation Plan VVR Verification & Validation Report 1.3 References
- Henderson, Tom - CEO; professor for CS 4500 Software Engineering Laboratory
- Henderson, Tom - CS 4500 Project Plan Outline, 27 January 2005. Available WWW: http://www.cs.utah.edu/classs/cs4500/guidelines/project-plan.html
- Team Silent Mission, BID Version 1.0, 21 January 2005. Available WWW: http://www/cs/utah.edu/~zdouglas/4500/bid1.htm
1.4 Overview of Document
This is the Project Plan for the eWallet by Team Silent Mission.
- Section 1.0 of the document introduces the purpose of the document, presents terminology and references that will be used in the project documentation, and defines the scope of the project.
- Section 2.0 of the document gives information about the team structure, the process model, and the responsibilities of each team member.
- Section 3.0 of the document explains the team name, lists our possible meeting times, and outlines the team's range of skills.
- Section 4.0 of the document outlines an overview of the preliminary project requirements as well as the data requirements, constraints, and assumptions made about the end users' systems.
2.1 Process Model
We plan on following a modular model by breaking up the project into smaller more manageable pieces. This will help to organize our team's effort in focused areas. After all modules are complete, the team plans on going through an integration process where we will make sure all modules work appropriately with each other.
The following table represents our tentative plan for completion of certain milestones, reviews, work products, and deliverables:
Assignment or Activity Date to be Completed Project Bid v1.0 January 14 Project Bid v2.0 January 21 Project Plan v1.0 January 24 SRS v1.0 January 28 SDS v1.0 Feburary 4 SDS v2.0 Feburary 18 VVP v1.0 Feburary 21-25 VVR v1.0 March 7-11 Stage 1 Release March 7-11 VVR v2.0 March 28-April 1 Stage 2 Release March 28-April 1 VVR v3.0 April 11-15 Stage 3 Release April 11-15 Product Release April 18-22 Legacy Turn-In April 25-29 Final Report April 25-29 Demo April 28 2.2 Organizational Structure and Responsibilities
Throughout the semester we will rotate our roles when necessary.
- Brittney: Lead Designer, Lead Developer, Code Reviewer, Java Programmer, Web Developer
- Zack: Webmaster, HTML Programmer, User Interface, Graphic Design, Developer, Testing and Verification
- Jenny: Team Leader, User Interface, Tech Writer, Documentations Reviewer, Client Relations.
- Shannon: Lead Developer, Programming Leader, Developer, Head Programmer, HTML Programmer, Graphic Design, User Interface, Code Reviewer
2.3 Organizational Boundaries and Interfaces
- Thomas Henderson, CEO - Professor Henderson will guide the team by setting deadlines and due dates. He will also provide advice and comments to help the team with the product implementation and management of the team.
- Brandt Erickson, VP - Brandt will guide the team. He will be mainly responsible for providing the team with feedback on the documentation and several audits throughout the semester.
- Thomas Henderson, Client - Since we are doing a project of our choosing, Professor Henderson will act as the client. He will provide us with input about the direction and design of the project and suggest additions and changes that could benefit the system.
2.4 Reviews, walkthroughs, inspections, and audits
We will periodically have meetings, walkthroughs, and audits. We will review previous documentation and results from weekly changes to examine our progress. We will compare this progress to the mandated milestones and adjust accordingly. During the meetings, we will also evaluate the quality of current products.
2.5.1 Procedures for reviews, walkthroughs, inspections, and audits
Before a document is due, our team will meet to review content and provide feedback to each other. This will help ensure the best quality document that we can provide. When possible we will utilize outside sources to review our documentation.
When we begin to develop the software, our technical leader will provide all team members with a walkthrough of his/her work. After a walkthrough, a review team will run inspections on the product. The review team will record the results and inform the technical leader weekly of new defects.
There are three scheduled releases for our team project.
2.5.2 Schedule of reviews, walkthroughs, inspections, and audits
Reviews for our documents will take place within a week prior to the due date. If need be, we will schedule more reviews to ensure a quality product.
Walkthroughs will take place about every two weeks. This schedule is very tentative however due to unforeseen technical problems that could arise. More walkthroughs may be needed as required by the technical leader.
Inspections of the software will initially take place about every two weeks. As with the walkthroughs, more inspections may be run if the team feels fit.
There are three scheduled releases of the project throughout the semester. The first release will be conducted by March 11. The second release of the project will be audited by April 1. The last release will be conducted on the final version of the project by April 15. The final audit will be scheduled April 28.
Back to Table of Contents
3.1 Management Objectives and Priorities
Our team will have a team leader. The team leader will mainly act to coordinate the group. As members of the group complete aspects of the project the team leader will help to integrate these changes. When a decision is needing to be made about certain aspects of the project, the team will vote and all team members will have equal say.
3.2 Team name
Team Silent Mission - This name was actually generated by a random name generator found on the internet. We felt it represented the nature of our project, as our smart cards have a mission to get done, and this is completed silently.
3.3 Possible Meeting Times
Our best possible meeting times will be on Monday and Wednesday after 7:00 pm and weekends except Saturday Night!
Brittney:
Mon, Wed, Fri: anytime except 10:30-11:30am and 2:00-3:00pm
Tues, Thurs: anytime before 3:30 pm
Sat, Sun: anytimeZack:
Jenny:
Mon, Wed, Fri: before 10:45 am
Mon-Fri: around 7:00 pm (prefer not Thursday or Friday)
Sat, Sun: anytime except Saturday night
Mon, Wed, Fri: before 10:45 am and after 4:00 pm
Tues, Thurs: after 6:30 pm
Sat, Sun: anytimeShannon:
Mon-Fri: after 7:00 pm
Sat, Sun: anytime3.4 Team's Range of Skills and Experience
On a scale of 1 = Very Experienced to 3 = Some Experience to 5 = No Experience, the following table reflects each team member's capability:
Brittney Brown Zack Douglas Jenny Greenwood Shannon Whitaker C++ 2 1 3 1 Java 1 2 1 3 SQL 3 2 3 2 Web Development 2 1 1 2 Smart Card Technology 1 4 5 5 Writing Skills 3 2 1 1 Management Skills 4 2 1 2
4.1 Overview of Functional Requirements
eWallet Functions:
- Enrollment: store photo, personal information, fingerprint on eWallet
- User can authenticate to eWallet with a fingerprint or PIN number
- Make purchases with electronic cash (stored value) or credit card account stored on the eWallet
- Store / read back insurance & medical information
- Store / read back drivers license information
- Add / Modify credit cards saved onto eWallet
- Transfer funds to and from bank account and eWallet via the Internet
4.2 Overview of Data Requirements
The eWallet can store the following data on the microprocessor chip: compressed digital photo, fingerprint image, text data including name, driver’s license, birthday, address, expiration date, medical insurance plan information, credit card numbers and exp dates, and a numeric amount representing how much cash is available/stored on the card.
Assuming a user has correctly authenticated him/herself via a fingerprint scan or PIN, the eWallet will read back any of the previous data.
The eWallet card system will also maintain a backup database of issued cards and their current states (cash value stored, personal information, etc) to allow for replacement of lost / stolen / deactivated cards.
4.3 General Constraints, Assumptions,Dependencies, Guidelines
The interactions between the eWallet and a banking system and credit card system will be simulated (we do not have real access to these systems or their standards of communication). Adding checking account funds to the eWallet must be done via a Web-based interface. It is assumed that card issuance is done in a networked environment so that data may be backed up, as well as electronic cash transactions so that the current stored value amount can be constantly backed up. Assuming appropriate drivers are available for the various hardware pieces, the system can run in either a Windows or Linux environment.
4.4 User View of Product Use
Scenario: Card Enrollment
Back to Table of Contents
The user is at a trusted card issuing facility. A technician will take user’s photograph and capture a scan of their fingerprint. User will see a screen where they are prompted to enter their personal information including: full name, social security number, current address, phone number, credit card information, gender, deposit amount, account number, username, password and pin. The technician will validate this information and then generate an eWallet with the user’s information stored on it. The user can then use the card to make purchases and show information
| January 24, 2005 | Initial version | v1.0 |
| March 4, 2005 | Updated References | v1.1 |
| April 24, 2005 | Updated User View of Product | v1.3 |