1.1 Purpose of this Document
The Verification and Validation Results document's purpose is to evaluate and describe the outcomes of the various activities in the Verification and Validation Plan document. A careful review of these results will allow us to give an accurate overview of the completeness of our product as well as outline tasks that are essential to the completion of the project.
1.2 Scope of the Development Project
This project implements an electronic wallet. A smart card is used to electronically implement various functions of a normal wallet. It can contain driver's license information, credit card account information (so that credit card purchases may be made with it), an electronic cash purse that functions similar to the University of Utah ID card, medical insurance information, and more. In order to view information on the eWallet or use the eWallet to make a purchase, the cardholder will first need to authenticate via a biometric or PIN.
Along with consolidating all your cash, credit cards, drivers license, medical insurance cards, etc onto one card - all of the functionality is now protected with a fingerprint or PIN number. If the eWallet is lost or stolen, the theif will not be able to gain access to any of the stored information. This is a huge advantage to carrying a conventional wallet where cash, credit card numbers, and personal information (ssn, address) are easily aquired when the wallet is lost or stolen.
1.3 Definitions, Acronyms, and Abbreviations
Term Definition eWallet Electronic Wallet Java programming language designed to develop applications, especially ones for the Internet, that can operate on different platforms POS A business or place where a product or service can be purchased. Smart Card A plastic card containing a computer chip and enabling the holder to purchase goods and services, enter restricted areas, access medical, financial, or other records, or perform other operations requiring data stored on the chip. SRS Software Requirements Specification SSN Social Security Number 1.4 References
- Henderson, Tom - CEO; professor for CS 4500 Software Engineering Laboratory
- Henderson, Tom - CS 4500 VVR Outline, 27 January 2005. Available WWW: http://www.cs.utah.edu/classes/cs4500/guidelines/VVR.html
- Team Silent Mission, BID Version 1.0, 21 January 2005. Available WWW: http://www.cs.utah.edu/~zdouglas/4500/bid1.htm
- Team Silent Mission, Project Plan Version 1.0, 14 January 2005. Available WWW: http://www.cs.utah.edu/~zdouglas/4500/ProjectPlan.html
- Team Silent Mission, Verification and Validation 2.0, 14 January 2005. Available WWW: http://www.cs.utah.edu/~zdouglas/4500/VVP.html
1.5 Overview of Document
This is the Software Requirements Specification for eWallet by Team Silent Mission.
Back to Table of Contents
- 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 assesses the overall success of the V&V activities. It discusses problems encountered and how they were resolved.
- Section 3.0 discusses what was planned for in the Project Plan and VVP. It explains what was done, what worked as planned, what we were unable to execute as described.
- Section 4.0 refers to what was planned for in the VVP. It explains what was done, what worked as planned, what we were unable to execute as described in the VVP.
- Section 5.0 reflects on how well our team's testing process worked.
- Section 6.0 addresses the outcome of acceptance tests and delivery.
- Section 7.0 addresses any open issues from the defect reports.
- Section 8.0 captures information that was relevant to the verification and validation process but that we did not feel was appropriate for any of the earlier sections.
The results from testing prove very useful in verifing the quality of our product. The format is laid out in detail by the Verification and Validation Plan for this product. All of the components have been tested thoroughly to meet their functions. All the links on each component have been verified to work correctly.
Back to Table of Contents
Reviews: The team used reviews of documents to check for spelling and grammatical errors. Reviews were also used to check to ensure that content was correct and up-to-date. Walkthroughs: The walkthroughs kept the team members up-to-date on project/code structure and progress.
4.1 Summary of component test
Items Description Component Test Photo is taken and placed on the eWallet Tester Brittney Successes None Problems Compression is too big to fit on card Time 30 hours Incomplete Compresssion is bad Pass/Fail Pass
Items Description Component Test A photo is successfully taken from the card and put into and application. Tester Jenny Successes The photo is taken from the card along with personal information then displayed in an applicaton for view. Problems The photo compression is not small enough. Time 40 hours Incomplete Complete Pass/Fail Pass
Items Description Component Test The camera connects to the code Tester Shannon Successes The camera connect to the code Problems None Time 5 hours Incomplete Nothing Pass/Fail Pass
Items Description Component Test The photo capture is integrated with enrollment Tester Zack Successes A button allows you to bring up the photo in enrollment Problems None Time 7 hours Incomplete Nothing Pass/Fail Pass
4.2 Summary of integration test/testing product as a whole
Testing the product as a whole was conducted when major components were complete. Transitions among various components were verified to all be correct. The product as a whole has passed the team's quality assurance standard.
5.1 Evaluation of test cases
For the most part, the test cases were designed rather well. Overall, however, the individual test cases may have been too general and could have used some more detail. Also, many of the comments produced by inspection were somewhat subjective. Some individual test cases could have been combined with others, while at the same time, other test cases could have been created to more carefully test individual parts of major components.
5.2 Results from defect tracker
Most of our defects fell into the medium to trivial range but then again the hard stuff is still to come. Had some problems with lost of server host name which caused major setback. Finally able to resolve and continue with work.
5.3 Lessons learned
Testing the product was generally somewhat simple even with the complexity of the complete product. More detailed descriptions of expected results as well as dividing up some individual tests would have been helpful for testing some components. Testing worked well for the most part through simple inspection due to the easy nature of the product, which demonstrated a successful user interface.
The product is designed according to the specifications in the SDS and SRS documents. Each component was tested initially by the individual(s) who designed it, and then tested by the rest of the group. The pieces of the project were integrated. Integration was tested to insure that all pieces of the project worked together smoothly. Newly added pieces of project (fingerprint & PIN) integrated smoothly.
The replication of system and component tests generated correct results. Original requirements are met and represented by all test cases listed in the VVP. The webpage and applications function properly across multiple platforms (multiple browers,etc).
Currently, there are no defects to report. All systems were designed as specified.
No additional information on verification and validation process.
| March 24, 2005 | Initial version | v1.0 |
| March 26, 2005 | Second version | v2.0 |
| April 7, 2005 | Third version | v3.0 |