66
BAB 4
RANCANGAN SISTEM YANG DIUSULKAN
4.1 Problem Domain
4.1.1 Cluster
Gambar 4-1 Cluster
4.1.2 Structure
1. CR/Project Development
Terdiri dari URF, proposal, addendum proposal, working party, steering commitee dan source person. URF memiliki hubungan assosiation dengan proposal, proposal dan addendum proposal memiliki hubungan aggregation
dengan working party, steering commitee dan source person. Satu URF pasti hanya mempunyai satu proposal, satu proposal mempunyai nol atau banyak
addendum proposal. Proposal mempunyai satu atau banyak working party, steering commitee dan source person. Sementara addendum proposal
mempunyai nol atau banyak working party, steering commitee dan source person. Hubungan antara URF, proposal, addendum proposal, working party, steering commitee dan source person dapat dilihat pada gambar berikut ini:
67 URF Source Person Steering Commitee Working Party Proposal Addendum Proposal 1 1 0 ..* 1 1 1 1 ..* 1 ..* 1 ..* 0 ..* 0 ..* 0 ..*
Gambar 4-2 Struktur untuk CR/Project Development
2. CR/Project Completion
Terdiri dari UAT, completion form, score dan test scenario. UAT mempunyai hubungan test scenario, UAT juga mempunyai hubungan association dengan
completion form dan completion form mempunyai hubungan association dengan
UAT mempunyai satu atau lebih test scenario, UAT mempunyai satu completion form dan completion form mempunyai satu score. Hubungan antara UAT,
completion form, score dan test scenario dapat dilihat di gambar berikut ini:
69 4.1.3 Class Diagram URF Source Person Steering Commitee Working Party Proposal Addendum Proposal 1 1 0 ..* 1 1 1 1 ..* 1 ..* 1 ..* 0 ..* 0 ..* 0 ..* UAT Completion Form Score Test Scenario 1 1 1 1 1 1..* 1 1
4.1.3.1 Definition
Class URF
Attibutes : key field, status project, nomor urf, tgl create urf, judul urf, nama dept requester, nama requester, email requester, account requester, tgl aplikasi digunakan, nama pengguna, text request, text benefit, attach urf, attcah proposal, type urf, category urf, priority urf, jenis/modul sap, status urf, tgl approval owner, tgl approval operation, tgl approval spv, tgl approval mgr, nama owner, avvount owner, email owner, nama it operation, account (idem), email (idem), kode section, nama it spv, account (idem), email (idem), nama it pic, account (idem), email (idem), nama it maint, email it maint, account it maint, nama it mgr, account it maint, email it maint, tgl estimasi, jumlah revisi, text update owner.
Operations : Membuat, mengubah, menganalisa URF, menyetujui URF, melihat URF.
Class Proposal
Attributes : key field, nomor reverensi, nomor proposal, tgl create proposal, tgl expanse, kode kpi, no sk, tgl digunakan, nama pm, email pm, co pm, email co pm, nama spv, account spv, email spv, status accept spv, tgl accept spv, nama sys maint pic, account sys maint pic, email sys maint pic, accept sys maint pic, tgl accept sys maint pic, nama
71 operation spv, account operation spv, status accept operation spv, tgl accept opr spv, email opr spv, nama opr maint pic, email opr maint pic, account opr maint pic, status accept maint pic, tgl accept opr maint pic, text requester background, text object, text procedure, text system teknik, text system maint, text document, text benefit, text policy, Rp hardware, ext hardware, Rp software, text software, Rp cosultant, text consultant, Rp others, text others, tgl start, tgl finish, status approve proposal, tgl approve spv, nilai /bobot proposal, tgl approve opr, tgl approve mgr, text update oleh spv, tgl update spv, text update opr, tgl update opr, text update mgr, tgl update mgr, text update owner, tgl update owner, tgl create score, status score, score plan /pm, score coop /pm, score result /pm, score document /pm, tgl score update.
Operations : Membuat, mengubah, menganalisa proposal, menyetujui proposal, melihat proposal.
Class Addendum Proposal
Attributes : key field, no urut addendum, no reverensi add, nomor addendum, tgl create addendum, tgl expend, text object, text alasan, text update SPV, tgl update spv, text update opr, tgl update opr, text update mgr, tgl update mgr, text update owner, tgl update owner, status addendum, tgl approval spv, tgl approval opr, tgl approval mgr, tgl approval owner, Rp software, text software, Rp hardware, text
hardware, Rp consultan, text consultan, Rp others, text others, tgl start, tgl finish.
Operations : Membuat, mengubah, menganalisa addendum proposal, menyetujui
addendum proposal, melihat addendum proposal.
Class Score
Attributes : key filed, judul, tipe, weight, tanggal scoring, account, plan, coop, result, doc.
Opeartions : Membuat score
Class Working Party
Attributes : key field, no urut sbg WorkParty, account Working Party, nma (idem), email (idem), score plan, score coop, score result, score document, status accept, Tgl Accept, status working party.
Opeartions : Menyetujui proposal, menyetujui addendum proposal, mendevelop
CR atau project.
Class Steering Commitee
Attributes : key field, account dr steering committee, nama (idem), email (idem), status accept, tgl accept, status steering committee.
73
Opeartions : Menyetujui proposal, menyetujui addendum proposal, mendevelop
CR atau project.
Class Source Person
Attributes : key field, account dari source person, nama (idem), email (idem), status accept, tgl accept, status source person.
Opeartions : Menyetujui proposal, menyetujui addendum proposal, mendevelop
CR atau project.
Class UAT
Attributes : key field, nomor uat, no reverensi uat, tgl create uat, status uat, text update spv, text update opr, text update maint.
Operations : Membuat, mengubah, menganalisa UAT, menyetujui UAT, melihat UAT.
Class Test Scenario
Attributes : key filed, no urut, judul, deskripsi test, hasil test, catatan, tanggal penambahan.
Class Completion Form
Attributes : key field, nomor completion, nomor reverensi, tgl completion, tgl actual start, tgl actual finish, text result, text procedure, text security, text document, Rp software, text software, Rp hardware, text hardware, Rp consultan, text consultan, Rp others, text others, nama spv, account spv, email spv, nama system maintenance, account (idem), email (idem), nama operation SPV, account (idem), email (idem), nama operation PIC, account (idem), email (idem), status approval, tgl approve spv, tgl approve opr, tgl approve mgr, text update pic, text update spv, text update opr, text update maint spv, text update maint PIC, tgl update.
75
4.2 Application Domain
4.2.1 Usage
Gambar 4-5 Use Case Diagram Sistem IT Collaboration Suite
4.2.1.1 Mengajukan Request
Pada use case ini user requester akan mengajukan request apabila ada perubahan atau ada kebutuhan untuk melakukan pengembangan. Pengajuan ini akan dilakukan analisis oleh Process Owner dan setelah masuk ke IT kembali akan dilakukan analisis oleh IT Operation. Deskripsi detil terlihat dalam tabel 4-1.
Tabel 4-1 Use Case Specification untuk Mengajukan Request
Pre-Condition Ada perubahan atau permintaan baru pada sistem yang berjalan
Flow of Event Basic Path:
1. User Requester membuka aplikasi melalui
intranet dan mengisi URF.
2. URF ini kemudian akan dianalisis untuk disetujui, diminta perubahan ataupun di tolak oleh Process Owner.
3. Jika Process Owner menolak maka URF tidak layak untuk diajukan, jika Process Owner setuju maka URF akan masuk ke IT dan IT Operation
akan melakukan analisis. Jika tidak setuju, IT Operation akan membuat rejection form. Tetapi jika setuju maka akan di-assign ke IT Development Supervisor (untuk kategori project) atau IT Maintenance Supervisor (untuk kategori
change request).
4. Dari IT Supervisor ini akan dilakukan analisis dan
assign URF ke IT PIC.
5. Setiap proses yang dilakukan terhadap URF maka akan terkirim reminder melalui email ke semua orang-orang yang terlibat dalam URF.
77
Gambar 4-6 Sequence Diagram Mengajukan Request
4.2.1.2 Mengerjakan Request
Setelah IT PIC menerima URF, maka akan langsung membuat dan mengajukan proposal. Dalam proposal ini akan mencakup mulai dari tujuan bisnis, kebutuhan budget
jika ada, deskripsi global pengerjaan, kebutuhan resource yang terdiri dari working party, source person, steering committee dan akan dianalisis dan disetujui oleh IT Supervisor, IT Operation, IT Manager, dan Process Owner. Deskripsi detil terlihat pada tabel 4-2.
Tabel 4-2 Use Case Specification untukMengerjakan Request
Pre-Condition URF sudah disetujui. Flow of Event Basic Path:
1. IT PIC membuka aplikasi melalui intranet dan membuat proposal, meminta persetujuan dari
working party, source person, dan steering committee jika memang membutuhkan.
2. IT Supervisor akan menganalisis, meminta perubahan jika perlu, dan melakukan approval.
3. Proses berikutnya IT Operation akan menganalisis, meminta perubahan jika perlu dan melakukan approval.
4. Demikian juga untuk proses berikutnya, IT Manager akan menganalisis, meminta perubahan jika perlu dan melakukan approval
5. Kemudian Process Owner juga akan menganalisis, meminta perubahan jika perlu dan melakukan
approval.
6. Setiap proses pada proposal akan mengirimkan email notifikasi kepada setiap actor yang terlibat. Post Condition Proposal disetujui.
79
Gambar 4-7 Sequence Diagram Mengerjakan Request
4.2.1.3 Melakukan Testing
IT PIC akan langsung membuat skenario testing sekaligus mengajukan UAT jika sekiranya pengerjaan request sudah selesai. Skenario testing akan diajukan ke IT Supervisor, dan IT Operation untuk dicek. Dan selanjutnya hasil dari UAT akan di setujui oleh user requester, IT Supervisor, IT Operation.
Testing ini akan dilakukan oleh user requester dan IT PIC, tetapi tidak menutup kemungkinan apabila diperlukan maka source person, working party, IT Supervisor
akan terlibat. Apabila request tersebut dalam bentuk project maka proses testing ini harus melibatkan juga PIC Maintenance, dan IT Supervisor Maintenance karena nantinya setelah project selesai akan diserah terimakan ke IT Maintenance. Deskripsi detil terlihat di tabel 4-3.
Tabel 4-3 Use Case Specification untuk Melakukan Testing
Pre-Condition Requirement sudah selesai dikerjakan oleh IT PIC.
Flow of Event Basic Path:
1. IT PIC membuka aplikasi melalui intranet dan membuat UAT dan skenario testing.
2. IT Supervisor dan IT Operation akan mengecek skenario testing.
3. User Requester dan IT PIC akan melakukan testing berdasarkan skenario.
4. Setelah selesai testing, IT PIC akan melengkapi hasil dari testing dalam UAT.
5. Kemudian pertama kali akan dicek dan disetujui oleh PIC Maintenance selanjutnya dicek dan disetujui oleh IT Supervisor jika request dalam bentuk project, tetapi jika dalam bentuk change request akan langsung di cek oleh IT Supervisor.
6. IT Operation selanjutnya akan mengecek dan menyetujui UAT tersebut.
7. Jika testing tidak berhasil maka akan dilakukan testing ulang tetapi sebelumnya UAT akan dicek ulang.
8. Setiap proses yang terjadi pada form UAT akan memberikan email notifikasi kepada setiap actor
yang terlibat.
81
Gambar 4-8 Sequence Diagram Melakukan Testing
4.2.1.4 View Status
Setiap user requester akan dapat melihat status dari request yang telah diajukan, sampai sejauh mana request tersebut sudah dikerjakan dan PIC yang bertanggung jawab terhadap request tersebut. Detil deskripsi terlihat pada tabel 4-4.
Tabel 4-4 Use Case Specification untuk View Status
Pre-Condition User requester mengajukan request, dan belum ada status.
Flow of Event Basic Path:
1. User requester membuka aplikasi melalui intranet. 2. Ketika request sudah masuk di Process Owner
maka pada tampilan layar aplikasi akan menampilkan status:
• Inprogress artinya status URF menunggu respon dari Process Owner.
• Analisa artinya status sedang dalam proses analisis oleh Process Owner.
• Reject artinya request tersebut ditolak.
3. Ketika request sudah masuk di IT maka pada tampilan akan menampilkan judul requestnya, tahap yang sudah dilalui misal: URF, proposal, UAT, dan completion dan IT PIC yang menangani sekaligus status:
• Inprogress artinya menunggu respon dari IT Operation.
• Waiting approval artinya sudah direspon dan menunggu approval.
• Analisis artinya dalam tahap analisis.
• Reject artinya penolakan.
• Done artinya selesai dikerjakan.
83
Gambar 4-9 Sequence Diagram View Status
4.2.1.5 Scoring
IT PIC setelah selesai mengerjakan change request atau project dan mngajukan
completion form maka diberikan penilaian oleh IT Supervisor. Detil deskripsi terlihat pada tabel 4-5.
Tabel 4-5 Use Case Specification untuk Scoring
Pre-Condition Request selesai dikerjakan dengan adanya completion form
Flow of Event Basic Path:
1. Setelah completion form selesai dikerjakan, IT Supervisor membuka aplikasi melalui intranet.
2. IT Supervisor akan mengisikan nilai berdasarkan nomor completion form dan penentuan nilai berdasarkan bobot dari URF yang telah dikerjakan oleh IT PIC.
3. Setelah itu IT Operation dan IT Manager akan melakukan approval.
Post Condition Score diberikan.
Gambar 4-10 Sequence Diagram Scoring
4.2.2 Functions
Tabel berikut ini menunjukan fungsi-fungsi yang ada didalam sistem IT Collaboration Suite.
85 Tabel 4-6 Daftarfungsi
Nama Fungsi Complexity Type
Create, update URF Medium Update
Create, update Proposal Medium Update
Create, update Addendum Proposal Medium Update
Create, update UAT Form Medium Update
Create, update Completion Form Medium Update
Create, update, delete score Medium Update
Read URF Simple Read
Read Proposal Simple Read
Read Addendum Proposal Simple Read
Read UAT Form Simple Read
Read Completion Form Simple Read
Read Score Simple Read
Approval URF Medium Update
Approval Proposal Medium Update
Approval Addendum Proposal Medium Update
Approval UAT Form Medium Update
4.2.3 User Interface
87 4.2.3.1 Menu Utama
Menu utama terdiri dari dua bagian yaitu Menu Transaction dan Menu User Guide. Rancangan layar untuk menu Transaction adalah:
Gambar 4-12 User Inetrface Menu Transaction
Pada menu Transaction terdapat 8 sub menu yang terdiri dari: 1. Home, digunakan untuk kembali ke halaman utama.
2. URF, akan menampilkan halaman yang berisi semua daftar URF yang ada. 3. Proposal, akan menampilkan halaman yang berisi seluruh daftar proposal
yang telah dibuat.
4. Addendum, akan menampilkan halaman yang berisi daftar addendum proposal yang telah dibuat.
5. UAT, akan menampilkan halaman yang berisi seluruh daftar UAT yang telah dibuat. 1 2 3 4 5 6 7 8 a d c b
6. Completion, akan menampilkan halaman yang berisi seluruh daftar
completion yang telah dibuat.
7. Scoring, akan menampilkan permintaan masukan nomor completion yang nantinya akan diisi score-nya.
8. Report, akan menampilkan sub-sub menu yang terdiri dari:
a. Budget, akan menampilkan halaman yang berisi laporan keuangan yang digunakan dalam penanganan change request atau project.
b. List of User Requirement, akan menampilkan halaman yang berisi laporan URF beserta statusnya.
c. Project, menampilkan halaman yang berisi seluruh laporan project
dan change request dan PIC yang bertanggung jawab.
d. Score, menampilkan halaman yang berisi penilaian dari setiap PIC yang bertanggung jawab terhadap project dan change request.
Gambar 4-13 User Interface Menu User Guide
Pada menu User Guide terdapat sub menu:
1. User Guide, menampilkan petunjuk penggunaan aplikasi bagi pengguna. 1
89 2. Workflow, menampilkan aliran proses pada setiap proses, antara lain proses
URF, proses proposal, proses addendum, proses UAT, proses completion,
dan proses scoring.
4.2.3.2 Halaman Utama
Halaman utama ini menampilkan seluruh requirement yang terdiri dari:
Gambar 4-14 User Inetrface Main Menu
1. No Proposal, menampilkan nomor proposal, dengan format penomoran lihat di tabel 4-7.
2. Project Name, menampilkan judul dari URF yang telah diajukan user requester, baik berupa kategori project ataupun change request.
3. Owner, menampilkan nama dari process owner.
4. Status, menampilkan status dari project atau change request. Untuk status lihat pada tabel 4-8.
Tabel 4-7 Format Penomoran Dokumen
Dokumen Format Deskripsi
URF XXXXXXXX/IT/RF/M/YYYY XXXXXXXX : nomor urut IT : Dokumen divisi IT RF : Request Form
M : bulan dalam abjad romawi YYYY : tahun
Proposal XXXX/IT/M/YYYY XXXX : nomor urut
IT : Dokumen divisi IT
M : bulan dalam abjad romawi YYYY : tahun
Addendum XXXX/IT/M/YYYY-ZZ XXXX : nomor urut
IT : Dokumen divisi IT
M : bulan dalam abjad romawi YYYY : tahun
ZZ : nomor urut addendum
UAT XXXX/UAT/nomor proposal XXXX : nomor urut UAT : dokumen UAT
Nomor proposal : mengambil nomor proposal dengan format xxxx/IT/M/YYYY
91
Completion XXXX/COMP/nomor proposal XXXX : nomor urut
COMP : dokumen completion
Nomor proposal : mengambil nomor proposal dengan format XXXX/IT/M/YYYY
Tabel 4-8 Status Project
Status Keterangan
Waiting for approval Proposal sudah dibuat oleh IT PIC dan sudah diajukan untuk proses approval tetapi approval masih menunggu bisa dari IT Supervisor, IT Operation, IT Manager, atau
Process owner.
In progress Proposal belum dibuat ataupun sedang dibuat oleh IT PIC dan belum diajukan ke proses approval.
Done Project atau change request sudah selesai dikerjakan
dan completion sudah dibuat dan approval sudah sampai pada level IT Manager.
4.2.3.3 URF List
Sub menu URF digunakan untuk melihat daftar URF yang telah masuk ke IT. Pada sub menu ini akan menampilkan:
Gambar 4-15 User Interface List URF
Ketarangan:
1. Daftar URF lengkap dengan nomor URF, judul URF, nama requester dan
process owner, tanggal pembuatan dan tanggal penggunaan, approval
terakhir, status URF, dan PIC yang bertanggung jawab.
2. Tombol create URF, digunakan untuk masuk ke halaman pembuatan URF.
4.2.3.4 User Request Form (URF)
User Requirement Form digunakan untuk mendefinisikan secara detil kebutuhan user.Didalam URF terdiri dari:
1
93 1. Header URF, berisi:
Request number : Akan terisi secara otomatis setelah URF ini diisi dengan lengkap, di-submit dan di-approve oleh
process owner
Title request : Judul dari requirement yang menjelaskan
requirement secara umum
Request date : Request date akan terisi sendiri sesuai dengan
current date
Request by : Nama key user/PIC Departemen/Requester (by log
on)
Used date : Tanggal perkiraan requirement akan digunakan.
Used date bisa dipilih dengan mengklik tombol disampinya, maka akan tampil layar kalender
Used by : Requirement ini akan digunaakan oleh user
Departement : Nama departemen yang meminta (mengikuti nama
key user/PIC Departemen/Requester-by log on) 2. Field Request . Berisi request yang diajukan.
Gambar 4-16 User Interface User Request Form (URF)
1. Header Data
2. Tombol <<Pilih>>, digunakan untuk memilih nama process owner yang mengajukan request.
3. Field Request. 4. Business benefit
5. Tombol-tombol yang ada dilayar URF.
a. Send URF, untuk mengirimkan URF kepada processowner
b. Reset, untuk mengosongkan kembali form form URF
c. Insert Lampiran, untuk memasukkan file sebagai lampiran.
2 3
4
1
95 4.2.3.5 Proposal
Proposal digunakan untuk mendefinisikan secara detil rencana kerja untuk menyelesaikan permintaan dari user.
Gambar 4-17 User Interface Layar Utama Menu Proposal
Gambar 4-18 User Interface Input Nomor URF
Keterangan :
1. Tombol execute, akan masuk ke halaman proposal dan akan men-generate
nomor proposal secara otomatis.
1 Diisikan Nomor URF yang akan dibuatkan proposal
97
Gambar 4-19 User Interface Proposal
1
2
3
Keterangan :
1. Proposal header, semua field harus diisi kecuali nomor proposal yang akan tampil secara otomatis.
2. Project team, adalah harus diisi dan digunakan untuk melakukan permintaan bantuan dari mulai working party, source person, steering committee.
3. Isi proposal, dimana informasi mengenai project atau change request sangat penting, oleh karena itu sebisa mungkin diisi secara detil.
4. Plan Start, diisi sesuai dengan saat dimulainya pekerjaan dan finished date
adalah perkiraan pekerjaan itu selesai dikerjakan. Beberpa tombol untuk menjalankan fungsi antara lain save untuk menyimpan proposal, submit untuk mengirimkan proposal kepada atasan untuk dimintakan approve, dan insert
lampiran dimana tombol ini berfungsi untuk menyisipkan lampiran apabila diperlukan.
99 4.2.3.6 Addendum Proposal
Gambar 4-20 User Interfacce Layar Utama Menu Addendum Proposal
Gambar 4-21 User Interface Input Nomor Proposal
Daftar proposal lengkap dengan statusnya
Nomor Proposal yang akan dibuatkan Addendum Proposal
Gambar 4-22 User Interface Addendum Proposal
Secara umum isi dari Addendum Proposal sama dengan Proposal yaitu:
1. Proposal header, semua field harus diisi kecuali nomor proposal yang akan tampil secara otomatis.
2. Project team, adalah harus diisi dan digunakan untuk melakukan permintaan bantuan dari mulai working party, source person, steering committee.
3. Isi proposal, dimana informasi mengenai project atau change request sangat penting, oleh karena itu sebisa mungkin diisi secara detil.
101 4. Plan Start, diisi sesuai dengan saat dimulainya pekerjaan dan finished date
adalah perkiraan pekerjaan itu selesai dikerjakan. Beberpa tombol untuk menjalankan fungsi antara lain save untuk menyimpan proposal, submit untuk mengirimkan proposal kepada atasan untuk dimintakan approve, dan insert
lampiran dimana tombol ini berfungsi untuk menyisipkan lampiran apabila diperlukan.
4.2.3.7 User Acceptence Test (UAT)
Form User Acceptance Test ini digunakan untuk mencatat hasil test yang dilakukan oleh user.
Gambar 4-24 User Interface UAT
103 4.2.3.8 Completion
Form ini dibuat untuk menyatakan bahwa pelaksanaan pekerjaan sudah selesai dilakukan dan hasil yang dihasilkan sudah sesuai dengan scope dalam proposal.
Gambar 4-26 User Interface Layar Utama Menu Completion
Gambar 4-27 User Interface Input Nomor Proposal untuk UAT
105 4.2.3.9 Rejection
Digunakan untuk melakukan penolakan terhadap URF jika memang URF tidak bisa dipenuhi.
Gambar 4-29 User Interface Completion Form
4.2.3.10 Score
Report score digunakan untuk memonitoring nilai score yang timbul dalam setiap project yang dikerjakan.
Gambar 4-30 User Interface Scoring
Nomor Completion yang akan dibuatkan Score Nomor rejection
4.2.3.11 Report Budget
Report budget menampilkan uraian budget yang muncul dari setiap project yang di-develop.
107 4.2.3.12 Report URF
4.2.3.13 Report Project
Report project digunakan untuk memonitoring project yang berjalan ataupun yang sudah selesai.
109 4.2.3.14 Report Score
Report score untuk memonitoring nilai yang timbul dalam setiap project yang dikerjakan.
Gambar 4-34 User Interface Report Score
4.3 Technical Platform
4.3.1 Equipment
Sistem yang digunakan akan dijalankan dengan menggunakan PC dengan spesifikasi minimum untuk PC client yang digunakan adalah Pentium III 700 MHz – 1,2 GHz, RAM Memory 256 MB, dan Hardisk 20 GB, printer Laser. Untuk server, spesifikasi minimum PC yang digunakan adalah Pentium IV 1,8 GHz, RAM Memory 512 MB dan Hardisk 80 GB.
4.3.2 System Software
Software yang digunakan adalah Microsoft. NET. Kebutuhhan software yang digunakan client workstation untuk menjalanan program ini adalah Microsoft window
2000. Sedangkan untuk kebutuhan software di server akan menggunakan operating system Windows 2000 server dan database yang digunakan Microsoft SQL Server 2000.
4.3.3 System Interface
Sistem menggunakan printer Laser yang dapat mencetak laporan-laporan dalam format A4 dan letter. Jaringan yang digunakan adalan LAN (Local Area Network) dan WAN (Wide Area Network) yang terpusat baik interface maupun databasenya di satu
server di kantor pusat.
4.3.4 Design Language
Bahasa perancangan yang digunakan sistem ini adalah berdasarkan notasi UML.
4.4 Architecture
4.4.1 Component Architecture
Component Architecture yang digunakan adalah client server architecture yang berdasarkan attribute functionality yaitu client mempunyai user, interface dan function, sedangkan server mempunyai model.
Pada componet client terdapat component user interface bagian penjualan, staff invoice, bagian administrasi penagihan, bagian gudang dan keuangan, yang
masing-111 masing memiliki component function yang berguna sebagai read untuk disampaikan ke
server. Untuk lebih jelasnya dapat dilihat pada gambar 4-35. 4.4.2 Process Architecture
Deployment diagram menggunakan centralized pattern, dimana client hanya ditangani user interface. Semua permintaan dan pembaharuan adalah implementasi antara client dengan server, yang sebelumnya data-data tersebut telah dibaca oleh
function. Hasil data pada client dicetak dengan menggunakan printer. Process Architecture ini dapat digambarkan pada gambar 4-36.
Gambar 4-35 Component Architecture
<<component>> IT Supervisor <<component>> UI <<component>> Function <<component>> Server <<component>> Model <<component>> IT Manager <<component>> UI <<component>> Function <<component>> IT Operation <<component>> UI <<component>> Function <<component>> User Requester <<component>> UI <<component>> Function <<component>> Process owner <<component>> UI <<component>> Function <<component>> IT PIC/PM <<component>> UI <<component>> Function
113 User Requester Printer Process Owner Printer IT PIC/PM Printer Server Model User Interface Function Print Control User Interface Function Print Control User Interface Function Print Control IT Manager Printer IT Operation Printer IT Supervisor Printer User Interface Function Print Control User Interface Function Print Control User Interface Function Print Control
4.5 Recommendations
4.5.1 The System Usefulness and Feasibility
Sistem yang dirancang ini diharapkan mampu menangani semua proses pengajuan change request atau project yang terjadi dalam perusahaan dan meminimalisasi kemungkinan timbulnya masalah baru. Sistem ini dibuat dengan memperhatikan kebutuhan perusahaan untuk mencapai tujuan perusahaan. Serta sistem ini juga dibuat dengan memperhatikan kesalahan-kesalahan yang mungkin terjadi dalam pengajuan change request atau project perusahaan.
4.5.2 Strategy
Rancangan sistem yang baru akan dipresentasikan kepada perusahaan sebelum diimplementasikan. Diharapkan perusahaan dapat lebih memahami kegunaan sistem dan dapat menerapkannya dalam kegiatan perusahaan.
Sistem diterapkan dengan menggunakan strategi phase in conversion yaitu penerapan sistem secara bertahap sehingga sistem yang baru akan diterapkan sedikit demi sedikit sampai akhirnya sistem yang lama akan terganti dengan sistem yang baru. Hal ini dimaksudkan agar perusahaan dapat mempelajari sistem sedikit demi sedikit sehingga dapat menyesuaikan diri dengan sistem.
4.6 Kriteria Kegunaan Sistem
Perancangan sistem yang dibuat memenuhi kriteria-kriteria yang sangat penting, dengan catatan sebagai berikut :
115
Usable : kemampuan sistem yang digunakan harus dapat memberikan
kemudahan bagi user dalam melakukan pekerjaannya.
Secure : sistem yang dikembangkan harus memperhatikan sisi keamanan
baik data maupun prosesnya.
Efficient : sistem yang ada dapat bekerja secara tepat sesuai dengan porsinya.
Correct : kemampuan dari sistem yang ada memberikan suatu kepuasan bagi user.
Reliable : kemampuan sistem untuk menjaga tingkat kinerjanya pada situasi dan waktu tertentu.
Maintainable : kemampuan sistem untuk dimaintain
Testable : sistem yang dikembangkan harus mudah ditest dengan banyak kondisi
Comprehensible : usaha yang diperlukan untuk memperoleh suatu pemahaman pada sistem.
Tabel 4-1 menunjukan prioritas dari design criteria, dengan menentukan kriteria-kriteria tersebut maka ini akan membantu dalam perencanaan atas aktifitas yang ada.
Tabel 4-9 Prioritas dari Design Criteria
Criteria Very Important Important Less Important Irrelevant Easily Fulfiled Usable X Secure X Efficient X Correct X Reliable X Maintainable X Testable X Comprehensible X
