* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
The following figures are missing: See Errors
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Financial Information System (FIS) Environment
Overview
UC Davis FIS consists of five functional environments:
Development All development and unit testing take place in this environment
Testing SA, QA/QC and End-User testing take place in this environment
System Integration Additional SA and QA/QC testing take place in this environment
Training End User training take place in this environment
Production Production processing take place in this environment
Within each functional environment are four application areas:
Transaction Processing One (TP1 )
Accounts Receivable - AR
Chart of Account - CA
General Ledger - GE
Transaction Processing Two (TP2 )
Accounts Payable - AP
Purchasing
Decision Support System (DSS)
General Ledger Engine (GLE)
Each application will consists of five data base instance which corresponds to the five functional environments:
Devel All development and unit testing will be done in this instance.
Test SA, QA/QC and End-User testing will be done in this instance
Intg Additional SA and QA/QC testing will be done in this instance
Trng End-User training will be done in this instance
Prod Production processing will be done in this instance
Each environment will have its own set of data, users, privileges and security. Each environment must stand alone and be protected from other existing environments. A protocol has been established to control movement between environment.
Development Environment
The Development Environment allows developers to make modifications to the system without effecting the end-users.
Two Archives have been established to control completed objects. Uniface objects will be stored in the Uniface Version Control System, UVCS, on Delorean. All other objects will be stored in the Unix Revision Control System, RCS, on Shelby. See appendix for discussion of RCS or look at the man pages on a Unix machine. See Uniface's Project Managers' Guide for a discussion of UVCS.
Developers do not move objects (programs, scripts, data) between environments . This step is performed by the Code Migration Coordinator. A Code Migration Form (CMF) must be completed to indicated to the Code Migration Coordinator the changes or new development objects which need to be moved into the various environments for SA, QA/QC and End-User testing , training and production. Once testing is complete the CMF is used to coordinate the movement of changes or new development to the various production environments.
image95.gif
s:\shardata\sharsis\forms\cmf.doc
Version
1 April
26, 1996
image95.gif
image96.gif
image97.gif
***********************************************************
s:\shardata\sharsis\forms\cmf.doc Version 1 April 26, 1996
Footer information:
s:\shardata\sharsis\forms\cmf.doc Document
Name
Version 1 Version
April 26, 1996 Print
date (automatic)
image98.gif
image99.gif
image100.gif
\\rollsroyce\fis\detdsgn\tp\srf61cmf.doc Version
1 April
26, 1996
Revision Control System Revision Control System (RCS) automates the storing, retrieval, logging, identification, and merging of revisions of ASCII text files on a Unix system.
The basic user interface is extremely simple. The novice only needs to learn two commands: ci and co.
ci, short for "check in," deposits the contents of a text file into an archival file called an RCS file. An RCS file contains all revisions of a particular text file. co, short for "check out", retrieves revisions from an RCS file.
Suppose you have a file f.pco that you wish to put under control of RCS. Fisrt log on to Shelby. f.pco should be in your current working directory. Invoke the check in command: ci /opt/fis/cob/coblib/f.pco,v
This command creates the RCS file f.pco,v, stores f.pco into it as revision 1.1 in the directory /opt/fis/cob/coblib and deletes f.pco from your working directory. It also asks you for a description. The description should be a synopsis of the contents of the file. All subsequent check-in commands will ask for a log entry, which should summarize the changes that were made.
Files with names ending with ",v" are called RCS files ("v" stands for "versions"), all other files are presumed to be working files. To get back the working file f.pco in the previous example, use the check out command: co /opt/fis/cob/coblib/f.pco,v This command extracts the latest revision from f.pcp,v in the /opt/fis/cob/coblib directory and writes it into f.pco your current working directory. You can now edit f.pco and check it back in by invoking: ci /opt/fis/cob/coblib/f.pco,v ci increments the revision number properly. If ci complains with the message: ci error: no lock set by You should have locked the revision during the previous check out. Your last check out should have been: co -l /opt/fis/cob/coblib/f.pco,v Of course, it is too late now to do the check out with locking, because you probably modified f.pc already, and a second check out would overwrite your modifications. Instead, invoke: rcs -l /opt/fis/cob/coblib/f.pco,v This command will lock the latest revision for you, unless somebody else has already locked it. In that case, you will have to negotiate with that person.
Locking assures that you, and only you, can check in the next update, and avoids nasty problems if several people work on the same file. Even if a revision is locked, it can still be checked out for reading, compiling, etc. All that locking prevents is a check in by anybody but the locker.
RCS files will be in the following directories on She
Overview : Table of Contents