User Tools
Add this page to your book 
Remove this page from your book 
Manage book (
Help Table of Contents
Overview of the Implementation of the System
Environment
Before implementing the application, an environment for the implementation needs to be defined. Such an environment is needed to separate data between different possible environments such as “Life System”, “Integration System”, “Test System”, “Presentation System”, etc., which could be implemented on the same hardware. Therefore, the bank's “own entity” has to be defined. Administration is carried out by database entries and by separate settings which are handled at a supporter's level.
In order to organize group work, it is possible to define user groups which are responsible for certain business sectors or parts thereof. If no user groups have been defined the definition of the “own entity” is valid for all users.
In addition, information such as addresses of regional offices and branches which should appear on correspondence, printers, etc. can be stored separately in the database.
Finally, the single user has to be introduced to the system. The administration of users facilitates access to defined elements of the application as well as to the database. Defining the user also reflects the user profile associated to the corresponding use such as access rights, the right to release transactions etc.
The structure above can be adapted during implementation to fulfill the requirements and needs of all banks.
Check List
Before going live with the application, we would recommend testing the system first.
The following check list provides an overview of the several steps where decisions need to be made and where preparations need to be made by the bank.
| Item No. | Headline | Remarks |
|---|---|---|
| 1 | System Environment | Hardware configuration, operating system and the database system |
| 2 | Business Sectors | Choice of business sectors available in the application |
| 3 | Interfaces | Defining interfaces (General Ledger, SWIFT, Telex, Trade Connect etc.) that have to be supported by the application |
| 4 | Static Data | Determining the static data to be stored in the application (taking account of auto-updates of the database with external data, and the description of the interface for downloads). |
| 5 | Present Business Transactions | Given the presence of existing business transactions, decisions need to be made about how to proceed with them. |
| 6 | Printing | Defining how printouts are to be handled |
| 7 | Access Rights of Users | Defining the different user profiles, including user group profiles |
| 8 | Timetable | Defining milestones for testing and implementation |
| 9 | Documents | Preparing documents to be created as output correspondence |
Detailed planning and decisions on the different steps are made in collaboration with your support staff.
Modules for Testing Purposes
Since important parts of the system have to be adjusted by the implementation team to meet the requirements of the bank, modules have been developed solely for testing and implementation purposes. These help facilitate such customization. These are described in “Moduls for Testing and Implementation Purposes” and are only to be used in the test system. They are not available in the production system.
Test Data
Data and text definitions have been stored to assist testing. The respective data, text modules and guarantee text definitions should be adjusted to meet the bank's requirements and should not be transferred to the production system of the bank without prior checking.
The precise nature of the data stored can be seen in the MyModelbank documentation.
