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 1.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 Credit eWallet Cash Tester Brittney Successes Money can successfully be transferred to the eWallet from an account and the amount on the eWallet can successfully be retrieved Problems We experienced some problems concerning security. Determining how to log into a remote database, successfully and securely debit money from an account an make sure it is safely deposited onto a local smart card caused a few problems. We were able to fix the problem by changing some java security files. Time 15 hours Incomplete There are several items in this component that are not scheduled until a later release. Pass/Fail Pass
Items Description Component Test Database Connection - Applet connects to remote database Tester Brittney Successes Hey, it works Problems Getting an applet to connect to a remote database and how to make it do it fast. No one knew how to do this really. But this was the only way to make it secure. Time 4 hours Incomplete Complete Pass/Fail Pass
Items Description Component Test Database Connection - Correct username and password will successfully log into db Tester Shannon Successes Only a valid username and password will log in the database Problems For a while any username and password would log into the database Time 5 hours Incomplete Nothing Pass/Fail Pass
Items Description Component Test Database Connection - Incorrect username and password will give error message and not log in Tester Shannon Successes You cannot log in with an incorrect password Problems For a while any username and password would log into the database Time 5 hours Incomplete Nothing Pass/Fail Pass
Items Description Component Test Database Connection - Once logged in, account data can be successfully queried via the browser applet Tester Brittney Successes Accout balance information is queried by the browser applet Problems Learning to work with a browser applet to accomplish this Time 10 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.
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.
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.
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 |