sports club is process

Dokumentasi Sistem Informasi Keuangan

Sport Club

Oleh: A. Sasmito Adibowo – 1299000029

Freddy Priyatna - 1299000363 Hansen Wiriadinata – 129900038X

Julius Liman - 1299000525 Jutedy - 1299000533

Tunggul Simbolon - 1299000967

Fakultas Ilmu Komputer

Universitas Indonesia 2001

I. Requirement Analysis Process Karena modul yang akan dikerjakan oleh kelompok kami adalah modul keuangan (financial), kami berasumsi bahwa segala transaksi keuangan yang terjadi di klub olahraga Sport Club adalah berdasarkan pada prinsip akuntansi. Hal ini dilakukan agar laporan keuangan yang disampaikan kepada general manager Sport Club adalah benar adanya, tanpa manipulasi dari pihak-pihak teller yang berhubungan dengan transaksi keuangan di Sport Club. Dengan berdasarkan prinsip akuntansi, laporan keuangan yang disampaikan pun akan bersifat formal dan profesional untuk sebuah klub olahraga di dalam mengimplementasikan sistem informasi secara keseluruhan. Untuk itulah, kami mendatangkan beberapa narasumber dari Fakultas Ekonomi Universitas Indonesia, yang juga merupakan teman dari salah satu anggota kelompok untuk menganalisa kebutuhan sistem informasi keuangan secara lengkap dari proses seseorang melakukan transaksi keuangan sampai bagaimana caranya menghasilkan suatu laporan keuangan yang seimbang. Dari hasil analisa kebutuhan inilah, selain sebagai bahan untuk proses analisa dan model pada tahap selanjutnya, kami juga mendapatkan pengalaman bahwa dalam pengembangan suatu sistem informasi atau perangkat lunak, kami sebagai pengembang tidak dapat berdiri sendiri untuk mengimplementasikan sistem informasi. Contohnya, kami memerlukan komunikasi yang efektif dengan end user untuk mengetahui kebutuhan apa yang mereka inginkan dan diimplementasikan pada sistem informasi yang akan dikembangkan. Inilah hal yang cukup signifikan yang perlu dicamkan dalam tahap analisa kebutuhan dimana kami mengumpulkan semua keinginan dan kebutuhan end user, dalam hal ini klub olahraga Sport Club, untuk di-develop dan diimplementasikan pada sebuah sistem informasi. Kami melakukan beberapa pendekatan yang berbeda di dalam mengumpulkan kebutuhan sistem. Dalam hal ini, yang merupakan narasumber kami adalah teman-teman dari FE UI yang memang mengetahui prinsip akuntansi. Pendekatan yang dilakukan ialah dengan cara:

? Mengajukan pertanyaan-pertanyaan baik melalui e-mail dan pertemuan langsung dengan narasumber tersebut atau wawancara. Wawancara yang dilakukan ialah dengan menanyakan hal-hal yang paling umum sampai pada hal yang men-detail dari prinsip akuntasi dikaitkan dengan sistem informasi. Adapun pertanyaan-pertanyaan yang diajukan misalnya, “Terdiri dari apa saja laporan- laporan keuangan?”, “Kalau seorang pelanggan membayar uang les, uang tersebut dimasukkan ke laporan manakah?”, “Apakah klub olahraga akan mengalami kerugian jika beban lebih besar dari pendapatan, apakah harta-harta tidak bergerak, misalnya klub olahraga dapat dimasukkan sebagai suatu pendapatan juga?”, “Bagaimana caranya suatu transaksi keuangan dapat dikatakan valid?”

? Mengadakan suatu sesi formal dengan narasumber dimana kami berdiskusi tentang prinsip akuntansi dilihat dari sudut sistem informasi yang akan dikembangkan.

Kami merasa dengan melakukan cara-cara tersebut di atas, kami telah berhasil mengumpulkan kebutuhan-kebutuhan sistem yang akan kami analisa selanjutanya pada tahap berikut. Hasil analisa kebutuhan adalah sebagai berikut:

? Di dalam prinsip keuangan, terdapat berbagai laporan yang mempunyai fungsi yang berbeda-beda. Laporan akuntasi tersebut ialah 1. Jurnal keuangan, berguna untuk menampilkan data akuntansi yaitu data

peralatan, hutang, prive, penambahan modal, kas, modal, pendapatan, beban dan pajak pada periode bulan tertentu

2. Neraca keuangan, berguna untuk untuk menampilkan informasi akuntansi berupa neraca keuangan dalam periode bulan tertentu. Terdiri dari 2 jenis data, yaitu data akuntansi aktiva dan tanah dan data akuntasi passiva. Data akuntansi

aktiva terdiri dari kas, gedung, peralatan sedangkan data akuntansi passiva terdiri dari hutang dan modal

3. Laporan rugi laba, berguna untuk menampilkan informasi akuntansi berupa laporan rugi laba dalam periode bulan tertentu. Laporan rugi laba bermanfaat untuk menampilkan data beban dan pendapatan. Jika pendapatan lebih besar dari beban, maka akan mendapatkan laba sedangkan jika beban lebih besar dari pendapatan, maka akan mengalami kerugian

4. Laporan perubahan modal, berguna untuk menampilkan informasi akuntansi berupa laporan perubahan modal dalam periode bulan tertentu

5. Laporan pajak, berguna untuk menampilkan data-data pajak dalam periode tahun tertentu

6. Laporan modal, berguna untuk menampilkan data-data modal dalam periode tahun tertentu. Laporan modal terdiri dari laporan prive dan laporan penambahan modal

7. Laporan depresiasi, berguna untuk menampilkan nilai depresiasi suatu barang pada data keuangan. Syarat untuk melakukan depresiasi adalah pemakaian barang yang mau dilakukan depresiasi harus lebih dari 1 tahun. Setiap kali depresiasi barang mengurangi harga beli dengan 10% dari harga beli. Namun, jika jumlah depresiasi telah mencapai (estimasi pemakaian barang - 1), maka tidak dapat lagi dilakukan depresiasi

? Hirarki-hirarki data-data akuntansi utama beserta constraint yang berlaku pada data tersebut. Hirarki data-data akuntansi beserta constraint adalah sebagai berikut:

Lancar

Tetap

Peralatan

Harta [D]

Tanah

Gedung

Inventory

Land

Building

Supplies

Piutang

Perlengkapan

Kas

Utang [K] Utang Bank

Inventory_Account_Payable

Bank_Account_Paybale

Modal [K] Modal Capital

Beban [D] expense

Pendapatan [K]

Pendapatan di muka

Pendapatan biasa

Pendapatan bunga

Revenue

Money_on_hand

account

Di tahap analisa kebutuhan ini, kami juga menerbitkan sebuah whitepaper yang berisi spesifikasi proyek secara keseluruhan karena proyek ini akan dikembangkan oleh berbagai kelompok. Dalam whitepaper ini dijelaskan secara terperinci hubungan masing-masing modul dengan modul keuangan yang akan kami kembangkan. Whitepaper ini bertujuan sebagai bahan acuan yang akan dipakai untuk integrasi modul pada akhir proyek karena di dokumen ini juga berisi standar-standar bahasa yang dipakai, konfigurasi DBMS dan task set selector yang memberikan gambaran degree of rigor yang akan dipakai. Karena task set selector yang didapatkan adalah 1.9 maka degree yang dipakai ialah pendekatan secara structured. Berikut adalah whitepaper yang dimaksud:

---------------------------------------------------------------------------------------------------------------- Sports Club Information System

Whitepaper Draft Abstract This document serves as a preliminary documentation for the Sports Club Information System project group. It defines standards of practices and project specification. The current version is only a draft and is subject to change during the development process.

Definition of Terms project group The entire set of people working on the system.

module team The set of people working on a primary module. The team is led by a team manager.

t imestamp a unit of time which records year, month, day, hour, minute, and second of a particular instance of time.

primary module one of financial, staff facility, or courses modules.

Goal The goal of the project is to create a commercial-grade entry-level information system for a sports club.

System Structure The system is client/server based with thick clients managing a single database. The database will be an off-the-shelf DBMS while the clients are custom-made. The clients consist of several primary modules, each of which are assigned one module team.

Financial Module The financial module manages most financial-related activities of the sports club. It serves to ease the task of recording and analyzing the club's financial status for a period. It could assess the club's identify profit and losses.

The module consists of several executable programs, each of which are designated for a particular department:

Accounting Department This module will record every events which update accounting entities such as money on hand, account receivable, account payable, etc. The updates are the foundation to generate Journal, Loss-Benefit Balance and Capital Balance. Other modules will interface to the financial modules by using the take_money/give_money protocol : Staff module is concerned with the total of staffs’ salaries and separation pay for fired staff. Staffs’ salaries and separation pay request events will interface financial modules by using take_money protocol. Facility module is concerned with income which is gained from facilities’ fee, facilities’

maintenance costs and total expense to buy these facilities. Income payment events will use give_money protocol. Maintenance costs and expenses to buy facilities request events will use take_money protocol to interface financial modules. Courses Module is concerned with total of trainers’ salaries, separation pay for fired trainer and income from courses. Trainer’s salaries and separation pay request events will interface financial modules by using take_money protocol. Income payment events will use give_money protocol. Membership Module is concerned with income from membership fee. Income payment events will use give_money protocol.

Design Philosophies Documentation Languages All the documentation for clients will be written in Bahasa Indonesia while the developer side will be written in English. The reason for this separation is that the end-user will be a typical nontechnical Indonesian; while technical terms are more expressible in English such that technic al documents can be written without introducing nonstandard terms.

Database Design All entities that have a time attribute by nature will have a timestamp attribute in the database. Examples of such entities are:

$ Member – the member's registration date (also record the time). $ Staff – the enrollment date. $ Equipment – the purchase date. The database consists of two large table entity types which refers to the entities in the club: accounting side and physical side. The accounting side entities records accounting information for the entities, such as purchase price and depreciation accumulation. The physical side records real attributes that are attached to the entity, such as color, weight, etc.

Integration The system will be loosely-coupled. Integration between primary modules will be done at the database level. The primary modules shall share a single database schema and coordinate record sharing/locking among themselves (the modules may or may not share a single user-id/password combination, depending on the DBMS used). Each primary module shall maintain data integrity at each transaction.

User interfaces should be similar among primary modules. The modules should share a same look-and-feel to ease the user's transition between modules. The look-and-feel should also be intuitive and similar to other Windows™ applications to ease the user in learning the system.

The system should share a common logo, a similar splash screen and a similar About Box. The program icons should also be standardized.

Configuration The system should be as configurable as possible. All modules should have the same configuration repository (e.g., same Windows registry path). The configuration information stored are, among others, $ The database connection information (ODBC connect string, user-id/password combination). $ The sports' club name.

Adaptation Criteria Grade Weight EPM Product

Size of project 1 0.90 1 0.90

Number of users 2 0.97 1 1.94

Business critically 4 1.20 1 4.80

Longevity 1 1.20 1 1.20

Stability of requirements 2 0.95 1 1.90

Ease of communication 3 0.90 1 2.70

Maturity of technology 1 1.20 1 1.20

Adaptation Criteria Grade Weight EPM Product

Performance constraints 1 0.80 1 0.80

Embedded/nonembedded 1 0.80 1 0.80

Project staffing 1 1.10 1 1.10

Interoperability 5 1.10 1 5.50

Reengeneering factors 3 1.00 0 0.00

Task set selector 1.90

Development Culture The development will be approached in a structured manner. Team managers shall meet at every week reporting their team's progress and discussing conflicts. Informal communication among project members discussing the project is encouraged.

------------------------------------------------------------------------------------------------------------------------

II. Analysis Process and Modelling Proses analisa yang kami gunakan adalah berdasarkan proses evolutionary atau iterative dimana pengembangan sistem dibagi atas beberapa tahapan, yaitu proses analisa kebutuhan, proses analisa, proses design, proses implementasi dan proses testing. Namun di setiap proses tahapan tersebut, dapat kembali ke tahapan sebelumnya jika dirasakan perlu diadakan revisi atau kebutuhan baru yang akan mempengaruhi keseluruhan sistem. Berdasarkan hasil kebutuhan yang telah dikumpulkan pada tahapan requirement analysis process, maka langkah pertama yang dilakukan adalah mendisain suatu Entity Relationship Diagram (ER diagram) yang merupakan diagram hubungan antara data dan relasi pada sistem informasi keuangan Sport Club. Kemudian juga dihasilkan Data Flow Diagram yang merupakan diagram aliran data-data akuntansi pada sistem informasi keuangan. DFD digambarkan dalam bentuk level 0 dan level 1.

Diagram ER tersebut adalah sebagai berikut:

Secara garis besar, diagram berwarna transparan adalah diagram ER untuk modul keuangan sedangkan diagram berwarna gelap adalah tabel pada diagram ER pada modul lain yang mempunyai hubungan dengan diagram ER kami. Diagram ER ini didapatkan dari hasil analisa kebutuhan yang telah disebutkan di atas. Masing-masing laporan keuangan di-mapping menjadi satu tabel dan di antara tabel- tabel tersebut terdapat hubungan-hubungan yang berkaitan satu dengan yang lainnya. Kemudian, kami juga mendisain Data Flow Diagram dari sistem informasi keuangan Sport Club yang menandakan aliran data-data akuntansi di keseluruhan sistem informasi tersebut.

idtimestampinventory_idvalue

fin_inventory

idtimestampland_idvalue

fin_land

idtimestampbuilding_idvalue

fin_building

idtimestampsupplies_idvalue

fin_supplies

idtimestampamountaccount_typerequester_personrequester_department

fin_money_on_hand

idtimestampvalue

fin_revenue

idtimestampvalue

fin_expense

idtimestampvalueinventory_id

fin_inventory_account_payable

id

fac_land

idtimestampvalue

fin_bank_account_payable

idtimestampvalue

fin_account_receivabe

idpurchase_valueexpected_lifetime

fac_inventory

id

fac_supplies

idpurchase_valueexpected_lifetime

fac_building

idvalue

fin_depreciation_expense

DFD level 0 adalah sebagai berikut:

FacilitySubsystem

Accountancy Subsystem

MemberSubsystem

StaffSubsystem

CourseSubsystem

Accountant

depreciationexp tax

expense

prive

expenseincome

expense

income

non-opincome

expenseincome

Accountant

GeneralManager

financialreport

financialsnapshot

invest-ment capital

changes

DFD level 1 adalah sebagai berikut:

FacilitySubsystem

nonoperational

income

expense

incomedecode

fac income

decodefac

expense

decodefac non-op

income

MemberSubsystem

incomedecode

mbrincome

StaffSubsystem

expense decodestf expense

CourseSubsystem

expense

income decodecrs income

decodecrs

expense

Non - operationalIncome

non-opincomeinsertdebit

decodeacc tax

decodeacc depre-

ciation

decodeacc appre-

ciation

decodeacc prive

decodeacc

investment

decodeacc capitalchanges

Accountant appreciation

tax

depreciation

prive

investment

capitalchanges

Income

incomeinsertcredit

Expense

expenseinsertdebit

Money on hand

moneyon handinsertcredit

moneyon handinsertdebit

Inventory

inventoryinsertcredit

inventoryinsertdebit

Capital

capitalinsertcredit

capitalinsertdebit

data

data

data

data

data

data

data

data

data

c

d

d

c

c

d

c

d

d

c

c

d

d

c

d

c

d

cd

c

c

d

d

c

c

d

Lanjutan DFD Level 1

Non - operationalIncome

Income

Expense

Money on hand

Inventory

Capital

createBalanceSheet

createProfit Loses

Report

createFinancialJournal

createCapital

ChangesReport

assess

assess

assess

assess

assess

assess

assess

assess

assess

report

assess

assess

assess

report

Accountant

GeneralManager

report

report

report

report

report

report

report

report

formatfinancialreport

formatted report

formatfinancialreport

formatted report

III. Design Process Hasil analisa di atas kemudian di-mapping pada tahapan design. Adapun langkah yang pertama kali ditempuh pada tahapan ini adalah mendeklarasikan Data Definition Language (DDL) yang berdasarkan pada diagram ER yang telah dianalisa pada tahapan analisa. DDL tersebut adalah sebagai berikut: CREATE TABLE fin_capital_reinvest ( fin_cap_reinvest_id INTEGER NOT NULL, timestamp DATE NOT NULL, value INTEGER NOT NULL, PRIMARY KEY (fin_cap_reinvest_id) ); CREATE TABLE fac_inventory ( fac_inventory_id INTEGER NOT NULL, fac_name VARCHAR2(40) NOT NULL, timestamp DATE NOT NULL, value INTEGER NOT NULL, lifetime INTEGER NOT NULL, status VARCHAR2(8) NOT NULL, PRIMARY KEY (fac_inventory_id) ); CREATE TABLE fin_inventory ( fac_inventory_id INTEGER NOT NULL, last_depreciation DATE,

current_value INTEGER NOT NULL, fin_dep_counter SMALLINT NOT NULL, PRIMARY KEY (fac_inventory_id), FOREIGN KEY (fac_inventory_id) REFERENCES fac_inventory on delete cascade ); CREATE TABLE fin_capital ( fin_capital_id INTEGER NOT NULL, timestamp DATE NOT NULL, value INTEGER NOT NULL, PRIMARY KEY (fin_capital_id) ); CREATE TABLE fin_prive ( fin_prive_id INTEGER NOT NULL, timestamp DATE NOT NULL, value INTEGER NOT NULL, PRIMARY KEY (fin_prive_id) ); CREATE TABLE fin_account_payable ( fin_accpay_id INTEGER NOT NULL, timestamp DATE NOT NULL, value INTEGER NOT NULL, PRIMARY KEY (fin_accpay_id) ); CREATE TABLE fin_inv_acc_pay ( fin_accpay_id INTEGER NOT NULL, fac_inventory_id INTEGER NOT NULL, PRIMARY KEY (fin_accpay_id, fac_inventory_id), FOREIGN KEY (fin_accpay_id) REFERENCES fin_account_payable on delete cascade, FOREIGN KEY (fac_inventory_id) REFERENCES fin_inventory on delete cascade ); CREATE TABLE fin_expense ( fin_expense_id INTEGER NOT NULL, timestamp DATE NOT NULL, value INTEGER NOT NULL, source_table VARCHAR2(40) NOT NULL, PRIMARY KEY (fin_expense_id) );

CREATE TABLE fin_money_on_hand ( fin_moh_id INTEGER NOT NULL, timestamp DATE NOT NULL, value INTEGER NOT NULL, PRIMARY KEY (fin_moh_id) ); CREATE TABLE fin_moh_inv ( fin_moh_id INTEGER NOT NULL, fac_inventory_id INTEGER NOT NULL, PRIMARY KEY (fin_moh_id, fac_inventory_id), FOREIGN KEY (fin_moh_id) REFERENCES fin_money_on_hand on delete cascade, FOREIGN KEY (fac_inventory_id) REFERENCES fin_inventory on delete cascade ); CREATE TABLE fin_revenue ( fin_revenue_id INTEGER NOT NULL,

timestamp DATE NOT NULL, value INTEGER NOT NULL, source_table VARCHAR2(40) NOT NULL, PRIMARY KEY (fin_revenue_id) ); CREATE TABLE fin_moh_prive ( fin_moh_id INTEGER NOT NULL, fin_prive_id INTEGER NOT NULL, PRIMARY KEY (fin_moh_id, fin_prive_id), FOREIGN KEY (fin_prive_id) REFERENCES fin_prive on delete cascade, FOREIGN KEY (fin_moh_id) REFERENCES fin_money_on_hand on delete cascade ); CREATE TABLE fin_moh_cap_reinv ( fin_moh_id INTEGER NOT NULL, fin_cap_reinvest_id INTEGER NOT NULL, PRIMARY KEY (fin_moh_id, fin_cap_reinvest_id), FOREIGN KEY (fin_cap_reinvest_id) REFERENCES fin_capital_reinvest on delete cascade, FOREIGN KEY (fin_moh_id) REFERENCES fin_money_on_hand on delete cascade ); CREATE TABLE fin_moh_cap ( fin_moh_id INTEGER NOT NULL, fin_capital_id INTEGER NOT NULL, PRIMARY KEY (fin_moh_id, fin_capital_id), FOREIGN KEY (fin_capital_id) REFERENCES fin_capital on delete cascade, FOREIGN KEY (fin_moh_id) REFERENCES fin_money_on_hand on delete cascade ); CREATE TABLE fin_moh_acc_pay ( fin_moh_id INTEGER NOT NULL, fin_accpay_id INTEGER NOT NULL, PRIMARY KEY (fin_moh_id, fin_accpay_id), FOREIGN KEY (fin_accpay_id) REFERENCES fin_account_payable on delete cascade, FOREIGN KEY (fin_moh_id) REFERENCES fin_money_on_hand on delete cascade );

CREATE TABLE fin_moh_rev ( fin_moh_id INTEGER NOT NULL, fin_revenue_id INTEGER NOT NULL, PRIMARY KEY (fin_moh_id, fin_revenue_id), FOREIGN KEY (fin_revenue_id) REFERENCES fin_revenue on delete cascade, FOREIGN KEY (fin_moh_id) REFERENCES fin_money_on_hand on delete cascade ); CREATE TABLE fin_moh_exp ( fin_moh_id INTEGER NOT NULL, fin_expense_id INTEGER NOT NULL, PRIMARY KEY (fin_moh_id, fin_expense_id), FOREIGN KEY (fin_expense_id) REFERENCES fin_expense on delete cascade, FOREIGN KEY (fin_moh_id)

REFERENCES fin_money_on_hand on delete cascade ); CREATE TABLE fin_tax_types ( fin_tax_type VARCHAR2(8) NOT NULL, fin_tax_desc VARCHAR2(40) NOT NULL, PRIMARY KEY (fin_tax_type) ); CREATE TABLE fin_tax_expense ( fin_expense_id INTEGER NOT NULL, fin_tax_type VARCHAR2(8) NULL, PRIMARY KEY (fin_expense_id), FOREIGN KEY (fin_tax_type) REFERENCES fin_tax_types on delete cascade, FOREIGN KEY (fin_expense_id) REFERENCES fin_expense on delete cascade ); CREATE TABLE fin_depreciation_expense ( fin_expense_id INTEGER NOT NULL, fac_inventory_id INTEGER NULL, PRIMARY KEY (fin_expense_id), FOREIGN KEY (fac_inventory_id) REFERENCES fin_inventory on delete cascade, FOREIGN KEY (fin_expense_id) REFERENCES fin_expense on delete cascade ); CREATE TABLE svn_inventory ( svn_inventory_id INTEGER NOT NULL, timestamp DATE NOT NULL, value INTEGER NOT NULL, status VARCHAR2(8) NULL, PRIMARY KEY (svn_inventory_id) ); CREATE TABLE fin_moh_svn ( fin_moh_id INTEGER NOT NULL, svn_inventory_id INTEGER NOT NULL, PRIMARY KEY (fin_moh_id, svn_inventory_id), FOREIGN KEY (svn_inventory_id) REFERENCES svn_inventory on delete cascade, FOREIGN KEY (fin_moh_id) REFERENCES fin_money_on_hand on delete cascade ); CREATE TABLE fin_sold_item ( fin_revenue_id INTEGER NOT NULL, fac_inventory_id INTEGER NOT NULL, PRIMARY KEY (fin_revenue_id, fac_inventory_id), FOREIGN KEY (fac_inventory_id) REFERENCES fac_inventory on delete cascade, FOREIGN KEY (fin_revenue_id) REFERENCES fin_revenue on delete cascade ); CREATE TABLE fin_rev_svn ( fin_revenue_id INTEGER NOT NULL, svn_inventory_id INTEGER NOT NULL, PRIMARY KEY (fin_revenue_id, svn_inventory_id), FOREIGN KEY (svn_inventory_id) REFERENCES svn_inventory on delete cascade, FOREIGN KEY (fin_revenue_id)

REFERENCES fin_revenue on delete cascade ); CREATE TABLE fin_data_cache (

name VARCHAR(8) NOT NULL, timestamp DATE NOT NULL, PRIMARY KEY (name)

); CREATE TABLE fin_income_cache (

timestamp DATE NOT NULL, value INTEGER NOT NULL, primary key (timestamp)

); Kemudian Data Modification Language (DML) juga dideklarasikan sebagai berikut: INSERT INTO fac_inventory values (8001,'BARBEL',sysdate,100000,5,'ACTIVE');

INSERT INTO fac_inventory values (8002,'RAKET TENIS',sysdate,325000,3,'ACTIVE');

INSERT INTO fac_inventory values (8003,'SWIRL POOL',sysdate,4500000,5,'ACTIVE');

INSERT INTO fac_inventory values (8004,'RAKET SQUASH',sysdate,250000,3,'ACTIVE');

INSERT INTO fac_inventory values (8005,'TRACK MILL',sysdate,625000,5,'ACTIVE');

INSERT INTO fac_inventory values (8006,'MAGNETIC HOOLA HOOP',sysdate,125000,3,'ACTIVE');

INSERT INTO fac_inventory values (8007,'ANTI GRAVITATION DUMBEL',sysdate,1250000,6,'ACTIVE');

INSERT INTO fac_inventory values (8008,'BOLA BASKET',sysdate,55000,2,'ACTIVE');

INSERT INTO fac_inventory values (8009,'BOLA TENIS',sysdate,45000,0.5,'ACTIVE');

INSERT INTO fin_tax_types (fin_tax_type,fin_tax_desc) values ('PPn','Pajak Penambahan Nilai');

INSERT INTO fin_tax_types (fin_tax_type,fin_tax_desc) values ('PPh','Pajak Penghasilan');

INSERT INTO fin_tax_types (fin_tax_type,fin_tax_desc) values ('PBB','Pajak Bumi dan Bangunan');

INSERT INTO fin_tax_types (fin_tax_type,fin_tax_desc) values ('KKN','Biaya birokrasi'); Stored procedure yang merupakan script bagaimana modul lain berinteraksi dengan modul keuangan dalam hal pemasukan, penghapusan data dibuat dalam bentuk pseudocode dulu.

Pseudocode dari stored-procedure adalah sebagai berikut: function fac_sell_item { if(sold_amount < 0) { ERROR } update fin_revenue update fin_sold_item update fin_money_on_hand update fin_moh_rev } function fac_buy_item_cash { if(amount < 0) {

ERROR } update fin_money_on_hand update fin_inventory update fin_moh_rev }

function fac_buy_item_credit { if(amount < 0) { ERROR } update fin_account_payable update fin_inventory update fin_inv_acc_pay }

function fac_buy_item_repay { update fin_account_payable update fin_money_on_hand update fin_moh_acc_pay }

function mbr_income { update fin_revenue update fin_money_on_hand update fin_moh_rev }

function stf_pay_salary { if(amount < 0) { ERROR } update fin_expense update fin_money_on_hand update fin_moh_exp }

function svn_income { if(amount < 0) { ERROR } update fin_revenue update fin_money_on_hand update fin_moh_rev }

function crs_income { if(amount < 0) { ERROR } update fin_revenue update fin_money_on_hand update fin_moh_rev }

function fac_input_tax { if(tax_value < 0) { ERROR } update fin_money_on_hand update fin_expense update fin_moh_rev update fin_tax_expense } function svn_buy_souvenir { if(amount < 0) {

ERROR } update fin_money_on_hand update fin_moh_svn } Dengan adanya pseudocode di atas, stored procedure kembali diimplementasikan menjadi: /*===============================================================Oracle PL/SQL Stored Procedures Data manipulation of the system will be done exclusively through the use of stored procedures. This design decision is made to improve data integrity and consistency. ===============================================================*/ /************************************************************************* Used to change an employee's password. Parameters: essn The employee's SSN. oldpassword The employee's current password. newpassword The employee's new password. Return codes: 0 change password success -1 wrong password -2 Data not found */ create or replace function change_password ( essn in employee.ssn%type, oldpassword in employee.password%type, newpassword in employee.password%type ) return binary_integer as ssn_in employee.ssn%type; password_in employee.password%type; begin select ssn, password into ssn_in, password_in from employee where ssn = essn; if (password_in = oldpassword) then update employee set password = newpassword where password = oldpassword and ssn = essn; return 0; else return -1; end if; exception when no_data_found then /* dbms_output.put_line('Data not found'); */ return (-2); end; / show errors; /************************************************************************* Called by the front end system when an employee checks in or checks out.

Parameters: e_ssn the employee's SSN e_password the employee's password Return code 1 Check in success 2 Check out success -1 Wrong password -2 Data not found */ create or replace function check_in_out( e_ssn in employee.ssn%type, e_password in employee.password%type ) return binary_integer as ename_out employee.name%type; essn_out employee.ssn%type; epassword_out employee.password%type; starttime date; endtime date; status_check_in boolean; now date; nowchar char(2); cursor c1 is select emp_ssn, start_timestamp, end_timestamp from work_times where emp_ssn = e_ssn; c_rec c1%rowtype; begin now := SYSDATE; --dbms_output.put_line(SYSDATE); status_check_in := true; for c1_rec in c1 loop if (c1_rec.start_timestamp is not null) and (c1_rec.end_timestamp is null) then status_check_in := false; else status_check_in := true; end if; end loop; select ssn, name, password into essn_out, ename_out, epassword_out from employee where ssn = e_ssn ; if (e_password = epassword_out) then if (status_check_in = true) then insert into work_times values (essn_out, SYSDATE, null); -- dbms_output.put_line('Check in success!!'); return (1); else update work_times set end_timestamp = SYSDATE where emp_ssn = essn_out and end_timestamp is null; -- dbms_output.put_line('Check out success!!'); return (2);

end if; else -- dbms_output.put_line('Wrong password'); return (-1); end if; exception when no_data_found then -- dbms_output.put_line('Data not found'); return (-2); end; / show errors; /************************************************************************* Cleans up the work_times table from old data. After cleanup, the work_times table will only contain data for the current month. */ create or replace procedure clean_up as begin delete from work_times where to_char(end_timestamp, 'MM') != to_char(SYSDATE, 'MM') and end_timestamp is not null;

/* dbms_output.put_line('Clean up success!!'); */ end; / show errors; /* USED TO DELETE AN EMPLOYEE */ create or replace procedure delete_emp( essn in employee.ssn%type ) as begin DELETE FROM PROJECT_ROLES WHERE EMP_SSN=ESSN; DELETE FROM WORK_TIMES WHERE EMP_SSN=ESSN; DELETE FROM EMPLOYEE WHERE SSN=ESSN; end; / show errors; /** END Stored Procedures **/ Tahap design pada kelompok kami menghasilkan DDL, DML dan stored procedure.

IV. Implementation Phase Sebelum memasuki proses implementasi, kami menyadari bahwa sistem informasi ini harus dibagi menjadi sub-modul sesuai dengan prinsip divide and conquer. Sistem informasi keuangan ini dirasakan cukup besar cakupannya sehingga dengan cara membagi kerja antar anggota kelompok dapat meringankan beban kerja keseluruhan. Dan karena kelompok kami terdiri dari 6 orang, maka kami beranggapan bahwa semua sumber daya manusia yang tersedia di kelompok mesti dimanfaatkan dalam pengembangan proyek sistem informasi

ini. Untuk itulah, kami telah menyusun kerangka kerja kelompok beserta milestone-milestone yang harus terselesaikan pada jadwal yang telah ditetapkan. Proses pembagian kerja ini juga mengharuskan kami untuk mendefinisikan sub-modul yang akan diimplementasikan. Adapun referensi yang dipakai di dalam menentukan sub modul adalah DFD level 0 dan level 1 yang kami hasilkan pada proses analisa. Berikut adalah pembagian tugas beserta milestone dan sumber daya yang dialokasikan untuk masing-masing submodul: -------------------------------------------------------------------------------------------------------------- List of milestones to be achieved at the scheduled date Milestone 0 (1 Mei 2001)

? Analysis and design are completed ? API final version ( containing name, input , output and domain ) is released ? Scheduling process ( including other modules ) is cleared ? Whitepaper ( specs docs ) is released ? Prototype is achieved ? Testing process is partially completed ? Manual and documentations is partially completed

Milestone 1 (8 Mei 2001)

? Stored procedure is completed ? Database connection module is completed ? Program skeletons is achieved ? Balance sheet, journal and profit/loss report are completed ? High level authorization is completed ? Testing process is partially completed ? Manual and documentations is partially completed


? Capital changes report , prive input , new investment input and taxes input are completed ? Testing process is partially completed ? Manual and documentations is partially completed


? Depreciation input , appreciation input , profit prediction and charts ? Help session is completed ? Testing process is completed ? Manual and documentations is completed

Job allocation to each milestone Milestone 1 Human Resources Stored procedures: sen199 & fred199 Database connection module: sas199 Program skeletons: juli199 & tung199 Balance sheet, journal and profit/loss report sub modules: juli199 & jute199 Manual & documentation: jute199 Milestone 2 : Prive and new investment input sub modules: sen199 & fred199 Capital changes sub modules: juli199 & jute199 Taxes input sub modules: sas199 & tung199 Manual & documentation: jute199 Milestone 3 : Profit prediction: sen199 & fred199

Appreciation input: sas199 Depreciation input: tung199 Charts: juli199 & jute199 Help: jute199 Manual & documentations: jute199

------------------------------------------------------------------------------------------------------------------------------------- Dengan adanya kerangka kerja di atas, masing-masing anggota kelompok berkewajiban untuk menginplementasikan submodul yang telah dialokasikan. Pembagian kerja dilakukan secara demokratis artinya tidak ada anggota kelompok yang merasa dirugikan dalam hal pembagian sub-modul ini. Mereka yang merasa dapat mengerjakan suatu sub-modul dapat langsung “mengambil” submodul tersebut. Berikut adalah cuplikan code algoritma yang dipakai pada sistem informasi keuangan Sport Club:

--------------------------------------------------------------------------------------------------------------- ‘ Modul Neraca Keuangan Option Explicit Dim report As String Dim rsReport As Recordset Dim myYear Dim thisYear Dim cmd As New ADODB.Command Dim rs As ADODB.Recordset Dim laba As Long Private Sub CmdProfitLosesRefresh_Click() thisYear = ListYear.Text If (lbUpdate.Caption = "") Then cmdUpdate.Enabled = True ElseIf (Right(lbUpdate.Caption, 4) >= Val(thisYear)) Then cmdUpdate.Enabled = True Else: cmdUpdate.Enabled = False End If createReport 'Download blank page WebBrowser1.Navigate2 "about:blank" End Sub Private Sub cmdUpdate_Click() On Error GoTo handle

cmd.CommandText = "insert into fin_data_cache values ('LABA',to_date('" + thisYear + "','yyyy'))"

cmd.Execute handle: If Err.Number = -2147217900 Then cmd.CommandText = "update fin_data_cache set timestamp = to_date('" +

thisYear + "','yyyy') where name = 'LABA'" cmd.Execute

End If lbUpdate.Caption = thisYear

cmdUpdate.Enabled = False End Sub Private Sub WebBrowser1_DocumentComplete(ByVal pDisp As Object, URL As Variant) WebBrowser1.document.body.innerHTML = report End Sub Private Sub Form_Load() Set cmd.ActiveConnection = dbc

cmd.CommandType = adCmdText cmd.CommandText = "SELECT to_char(trunc(timestamp),'yyyy') year FROM

fin_data_cache where name = 'LABA'" Set rs = cmd.Execute Dim myDate myDate = Now Dim year myYear = DatePart("yyyy", myDate) year = myYear If Not (rs.EOF) Then Dim temp temp = rs.Fields("year").Value thisYear = Right(temp, 4) lbUpdate.Caption = temp If (Val(myYear) >= Val(thisYear)) Then cmdUpdate.Enabled = True End If Else thisYear = Str(myYear) thisYear = Right(thisYear, 4) End If Dim myYear1 myYear1 = myYear Dim ctr For ctr = year To 2001 Step -1 ListYear.AddItem (myYear1) myYear1 = myYear1 - 1 Next ctr ListYear.ListIndex = myYear - 2001 rs.Close createReport 'Download blank page WebBrowser1.Navigate2 "about:blank" End Sub Public Sub createReport() Set cmd.ActiveConnection = dbc cmd.CommandType = adCmdText report = "<Table><TR><TD width=350>Laporan Rugi Laba</TD><TD

width=90> </TD><TD width=90> </TD></TR>" report = report + "<TR><TD></TD><TD align=right>Debit</TD><TD

align=right>Kredit</TD></TR>" report = report + "<TR><TD> Pendapatan</TD></TR>" laba = 0 cmd.CommandText = "SELECT sum(value) total FROM fin_revenue where

to_char(trunc(timestamp),'yyyy') = '" + thisYear + "' and upper(source_table) = 'FAC_SELL_ITEM'"

Set rs = cmd.Execute report = report + "<TR><TD> Pendapatan non

operasional</TD>" If Not IsNull(rs.Fields("total").Value) Then laba = laba + rs.Fields("total").Value report = report + "<TD></TD><TD align=right>" +

Str(rs.Fields("total")) + "</TD></TR>" Else report = report + "<TD></TD><TD align=right>0</TD></TR>" End If cmd.CommandText = "SELECT sum(value) total FROM fin_revenue where

to_char(trunc(timestamp),'yyyy') = '" + thisYear + "' and (upper(source_table) = 'MBR_PAYS' or upper(source_table) = 'NMB_PAYS')"

Set rs = cmd.Execute report = report + "<TR><TD> Pendapatan

operasional</TD>" If Not IsNull(rs.Fields("total").Value) Then laba = laba + rs.Fields("total").Value report = report + "<TD></TD><TD align=right>" +

Str(rs.Fields("total")) + "</TD></TR>" Else report = report + "<TD></TD><TD align=right>0</TD></TR>" End If cmd.CommandText = "SELECT sum(value) total FROM fin_revenue where

to_char(trunc(timestamp),'yyyy') = '" + thisYear + "' and upper(source_table) = 'SVN_SALES'"

Set rs = cmd.Execute report = report + "<TR><TD> Pendapatan

souvenir</TD>" If Not IsNull(rs.Fields("total").Value) Then laba = laba + rs.Fields("total").Value report = report + "<TD></TD><TD align=right>" +

Str(rs.Fields("total")) + "</TD></TR>" Else report = report + "<TD></TD><TD align=right>0</TD></TR>" End If report = report + "<TR><TD> </TD></TR>" report = report + "<TR><TD> Beban</TD></TR>" cmd.CommandText = "SELECT sum(value) total FROM fin_expense where

to_char(trunc(timestamp),'yyyy') = '" + thisYear + "' and upper(source_table) = 'FIN_DEPRECIATION_EXPENSE'"

Set rs = cmd.Execute report = report + "<TR><TD> Beban

depresiasi</TD>" If Not IsNull(rs.Fields("total").Value) Then laba = laba - rs.Fields("total").Value report = report + "<TD align=right>" + Str(rs.Fields("total")) +

"</TD><TD></TD></TR>" Else report = report + "<TD align=right>0</TD><TD></TD></TR>" End If cmd.CommandText = "SELECT sum(value) total FROM fin_expense where

to_char(trunc(timestamp),'yyyy') = '" + thisYear + "' and upper(source_table) = 'STF_PAYS'"


gaji</TD>" If Not IsNull(rs.Fields("total").Value) Then laba = laba - rs.Fields("total").Value report = report + "<TD align=right>" + Str(rs.Fields("total")) +

"</TD><TD></TD></TR>" Else report = report + "<TD align=right>0</TD><TD></TD></TR>" End If cmd.CommandText = "SELECT sum(value) total FROM fin_expense where

to_char(trunc(timestamp),'yyyy') = '" + thisYear + "' and upper(source_table) = 'FIN_TAX_EXPENSE'"


pajak</TD>" If Not IsNull(rs.Fields("total").Value) Then laba = laba - rs.Fields("total").Value report = report + "<TD align=right>" + Str(rs.Fields("total")) +

"</TD><TD></TD></TR>" Else report = report + "<TD align=right>0</TD><TD></TD></TR>" End If

cmd.CommandText = "SELECT sum(value) total FROM fin_expense where to_char(trunc(timestamp),'yyyy') = '" + thisYear + "' and upper(source_table) = 'FAC_EQUIPMENT'"


perlengkapan</TD>" If Not IsNull(rs.Fields("total").Value) Then laba = laba - rs.Fields("total").Value report = report + "<TD align=right>" + Str(rs.Fields("total")) +

"</TD><TD></TD></TR>" Else report = report + "<TD align=right>0</TD><TD></TD></TR>" End If On Error GoTo handle cmd.CommandText = "insert into fin_income_cache values (to_date('" +

thisYear + "','yyyy')," + Str(laba) + ")" Set rs = cmd.Execute handle: If Err.Number = -2147217900 Then cmd.CommandText = "update fin_income_cache set value = " + Str(laba) + "

where timestamp = (to_date('" + thisYear + "','yyyy'))" Set rs = cmd.Execute End If report = report + "<TR><TD> </TD></TR>" report = report + "<TR><TD> Laba</TD><TD></TD><TD

align=right>" + Str(laba) + "</TD></TR>" End Sub ---------------------------------------------------------------------------------------------------------------

Berikut adalah cuplikan manual operasional sistem informasi Sport Club --------------------------------------------------------------------------------------------------------------- Neraca Keuangan Neraca keuangan yang ditampilkan dapat dilihat pada kedua browser yang tersedia pada form neraca keuangan. Browser di sebelah kiri menampilkan data akuntansi aktiva dan browser di sebelah kanan menampilkan data akuntansi passiva. Aktiva terbagi 2 bagian yaitu aktiva lancar berupa kas dan aktiva tetap berupa gedung, peralatan dan tanah. Yang termasuk data akuntansi passiva adalah hutang dan modal.

Jumlah nilai yang berada di sebelah debit dan kredit haruslah selalu sama.

Informasi keuangan yang ditampilkan pada neraca ini adalah berdasarkan pada periode tahun tertentu, jadi pengguna dapat menampilkan neraca keuangan tahun yang sebelumnya. Neraca keuangan yang ditampilkan pada saat form ini ditampilkan adalah neraca keuangan tahun sekarang. Cara Penggunaan

1. Setelah menekan tombol "Neraca Keuangan" pada form Utama, maka form Neraca Keuangan akan menampilkan neraca keuangan pada browser yang tersedia.

2. Untuk menampilkan neraca keuangan yang pada tahun yang lampau, isi tahun yang bersesuaian yang terdapat di sebelah label "Periode" pada form 3. Tekan tombol "Tampilkan" untuk melihat neraca keuangan yang bersesuai dengan tahun yang dipilih pada langkah 2

----------------------------------------------------------------------------------------------------------------

V. Testing Phase Testing terhadap sistem informasi Sport Club dilakukan oleh dua orang, yaitu Hansen (sen199) dan Julius Liman (juli199) selama satu hari. Tester melakukan black-box testing, yaitu berfokus pada fungsi dari setiap modul. Black-box testing ini bertujuan untuk menemukan error pada beberapa hal berikut ini:

? Fungsi yang salah / hilang. ? Kesalahan interface. ? Kesalahan pada data structure. ? Kesalahan pada saat run-time. ? Kesalahan pada inisialisasi dan terminasi program.

Metode black-box testing yang digunakan adalah Equivalence Partitioning, yaitu metoda yang membagi domain input data dari suatu program menjadi dua, valid dan invalid. Pendekatan yang dilakukan dalam black box testing adalah sebagai berikut:

? Jika suatu kondisi input memerlukan suatu range tertentu, satu valid dan dua invalid set data digunakan.

? Jika suatu kondisi input memerlukan suatu nilai tertentu, satu valid dan dua invalid set data digunakan.

? Jika suatu kondisi input memerlukan suatu anggota dari set tertentu, satu valid dan satu invalid set data digunakan.

? Jika kondisi inputnya boolean, satu valid dan satu invalid set data digunakan. Kami juga melakukan white-box testing, yaitu melakukan testing pada fungsi internal, mengecek semua keputusan logical pada sisi true dan false, menjalankan semua loop pada batasannya dan validasi struktur data internal. Setelah dilakukan integrasi dengan kelompok lain, dilakukan integration testing. Karena pada integrasi ini yang dilakukan hanya sebatas integrasi pada database maka tidak dilakukan testing lagi pada setiap modul. Jadi hanya dilakukan validasi pada struktur data internal, yaitu melakukan semua operasi yang berhubungan dengan database dengan membuat sample data dan juga melakukan validasi pada setiap operasi yang mengupdate data base.

sports club is process

Documents