BAB 4 RANCANGAN SISTEM YANG DIUSULKAN

Transkripsi

1 BAB 4 RANCANGAN SISTEM YANG DIUSULKAN 4.1 Problem Domain Cluster Structure Gambar 4-1 Cluster 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: 66

2 67 URF 1 1 Proposal * 1..* 1..* Working Party 0..* Steering Commitee 0..* Source Person 0..* 1 0..* Addendum Proposal 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 score.

3 68 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: Gambar 4-3 Struktur untuk CR/Project Completion

4 Class Diagram URF 1 1 Proposal * 1..* 1..* Working Party 0..* Steering Commitee 0..* Source Person 0..* 1 0..* Addendum Proposal 1 UAT 1 1 Completion 1 1 Form Score 1 1..* Test Scenario Gambar 4-4 Class Diagram

5 Definition Class URF Attibutes : key field, status project, nomor urf, tgl create urf, judul urf, nama dept requester, nama requester, 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, owner, nama it operation, account (idem), (idem), kode section, nama it spv, account (idem), (idem), nama it pic, account (idem), (idem), nama it maint, it maint, account it maint, nama it mgr, account it maint, 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, pm, co pm, co pm, nama spv, account spv, spv, status accept spv, tgl accept spv, nama sys maint pic, account sys maint pic, sys maint pic, accept sys maint pic, tgl accept sys maint pic, nama

6 71 operation spv, account operation spv, status accept operation spv, tgl accept opr spv, opr spv, nama opr maint pic, 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

7 hardware, Rp consultan, text consultan, Rp others, text others, tgl start, tgl finish. 72 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), (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), (idem), status accept, tgl accept, status steering committee.

8 Opeartions : Menyetujui proposal, menyetujui addendum proposal, mendevelop CR atau project. 73 Class Source Person Attributes : key field, account dari source person, nama (idem), (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. Opeartions : Membuat test scenario, melakukan testing, mengubah test scenario,

9 74 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, spv, nama system maintenance, account (idem), (idem), nama operation SPV, account (idem), (idem), nama operation PIC, account (idem), (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. Operations : Membuat completion form.

10 Application Domain Usage Gambar 4-5 Use Case Diagram Sistem IT Collaboration Suite 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.

11 76 Tabel 4-1 Use Case Specification untuk Mengajukan Request Pre-Condition Flow of Event Ada perubahan atau permintaan baru pada sistem yang berjalan 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 ke semua orang-orang yang terlibat dalam URF. Post Condition URF disetujui atau di-reject.

12 77 Gambar 4-6 Sequence Diagram Mengajukan Request 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.

13 78 Tabel 4-2 Use Case Specification untuk Mengerjakan Request Pre-Condition Flow of Event URF sudah disetujui. 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 notifikasi kepada setiap actor yang terlibat. Post Condition Proposal disetujui.

14 79 Gambar 4-7 Sequence Diagram Mengerjakan Request 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.

15 80 Tabel 4-3 Use Case Specification untuk Melakukan Testing Pre-Condition Flow of Event Requirement sudah selesai dikerjakan oleh IT PIC. 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 notifikasi kepada setiap actor yang terlibat. Post Condition Testing selesai dilakukan dan UAT disetujui

16 81 Gambar 4-8 Sequence Diagram Melakukan Testing 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:

17 82 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. Post Condition Status request muncul.

18 83 Gambar 4-9 Sequence Diagram View Status 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 Flow of Event Request selesai dikerjakan dengan adanya completion form Basic Path: 1. Setelah completion form selesai dikerjakan, IT Supervisor membuka aplikasi melalui intranet.

19 84 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 Functions Tabel berikut ini menunjukan fungsi-fungsi yang ada didalam sistem IT Collaboration Suite.

20 85 Tabel 4-6 Daftar fungsi 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 Check Program Complex Read and Compute

21 User Interface Gambar 4-11 Navigation Diagram

22 Menu Utama Menu utama terdiri dari dua bagian yaitu Menu Transaction dan Menu User Guide. Rancangan layar untuk menu Transaction adalah: a c b d 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.

23 6. Completion, akan menampilkan halaman yang berisi seluruh daftar completion yang telah dibuat 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. 1 2 Gambar 4-13 User Interface Menu User Guide Pada menu User Guide terdapat sub menu: 1. User Guide, menampilkan petunjuk penggunaan aplikasi bagi pengguna.

24 89 2. Workflow, menampilkan aliran proses pada setiap proses, antara lain proses URF, proses proposal, proses addendum, proses UAT, proses completion, dan proses scoring 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 Project Name, menampilkan judul dari URF yang telah diajukan user requester, baik berupa kategori project ataupun change request.

25 90 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

26 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 Waiting for approval In progress Done Keterangan 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. Proposal belum dibuat ataupun sedang dibuat oleh IT PIC dan belum diajukan ke proses approval. Project atau change request sudah selesai dikerjakan dan completion sudah dibuat dan approval sudah sampai pada level IT Manager URF List Sub menu URF digunakan untuk melihat daftar URF yang telah masuk ke IT. Pada sub menu ini akan menampilkan:

27 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 User Request Form (URF) User Requirement Form digunakan untuk mendefinisikan secara detil kebutuhan user. Didalam URF terdiri dari:

28 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. 3. Business Benefit. Berisi business benefit dari request yang diajukan.

29 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 process owner b. Reset, untuk mengosongkan kembali form form URF c. Insert Lampiran, untuk memasukkan file sebagai lampiran.

30 Proposal Proposal digunakan untuk mendefinisikan secara detil rencana kerja untuk menyelesaikan permintaan dari user. Daftar proposal lengkap dengan statusnya Gambar 4-17 User Interface Layar Utama Menu Proposal

31 96 Diisikan Nomor URF yang akan dibuatkan proposal 1 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.

32 Gambar 4-19 User Interface Proposal

33 98 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.

34 Addendum Proposal Daftar proposal lengkap dengan statusnya Gambar 4-20 User Interfacce Layar Utama Menu Addendum Proposal Nomor Proposal yang akan dibuatkan Addendum Proposal Gambar 4-21 User Interface Input Nomor Proposal

35 100 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.

36 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 User Acceptence Test (UAT) Form User Acceptance Test ini digunakan untuk mencatat hasil test yang dilakukan oleh user. Gambar 4-23 User Interface Layar Utama Menu UAT

37 102 Gambar 4-24 User Interface UAT Gambar 4-25 User Interface Test Scenario

38 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 Nomor Proposal yang akan dibuatkan UAT Gambar 4-27 User Interface Input Nomor Proposal untuk UAT

39 104 Gambar 4-28 User Interface Completion Form

40 Rejection Digunakan untuk melakukan penolakan terhadap URF jika memang URF tidak bisa dipenuhi. Nomor rejection Berisi alasan penolakan Gambar 4-29 User Interface Completion Form Score Report score digunakan untuk memonitoring nilai score yang timbul dalam setiap project yang dikerjakan. Nomor Completion yang akan dibuatkan Score Gambar 4-30 User Interface Scoring

41 Report Budget di-develop. Report budget menampilkan uraian budget yang muncul dari setiap project yang Gambar 4-31 User Interface Report Budget

42 Report URF Gambar 4-32 User Interface Report URF

43 Report Project Report project digunakan untuk memonitoring project yang berjalan ataupun yang sudah selesai. Gambar 4-33 User Interface Report Project

44 Report Score dikerjakan. Report score untuk memonitoring nilai yang timbul dalam setiap project yang Gambar 4-34 User Interface Report Score 4.3 Technical Platform 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.

45 System Software Software yang digunakan adalah Microsoft. NET. Kebutuhhan software yang digunakan client workstation untuk menjalanan program ini adalah Microsoft window Sedangkan untuk kebutuhan software di server akan menggunakan operating system Windows 2000 server dan database yang digunakan Microsoft SQL Server 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 Design Language Bahasa perancangan yang digunakan sistem ini adalah berdasarkan notasi UML. 4.4 Architecture 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-

46 masing memiliki component function yang berguna sebagai read untuk disampaikan ke server. Untuk lebih jelasnya dapat dilihat pada gambar 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.

47 112 <<component>> User Requester <<component>> Process owner <<component>> IT PIC/PM <<component>> UI <<component>> UI <<component>> UI <<component>> Function <<component>> Function <<component>> Function <<component>> Server <<component>> Model <<component>> IT Manager <<component>> IT Operation <<component>> IT Supervisor <<component>> UI <<component>> UI <<component>> UI <<component>> Function <<component>> Function <<component>> Function Gambar 4-35 Component Architecture

48 113 User Requester Process Owner IT PIC/PM User Interface User Interface User Interface Function Function Function Print Control Print Control Print Control Printer Printer Printer Server Model IT Manager IT Operation IT Supervisor User Interface User Interface User Interface Function Function Function Print Control Print Control Print Control Printer Printer Printer Gambar 4-36 Deployment Diagram

49 Recommendations 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 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 :

50 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.

51 116 Tabel 4-1 menunjukan prioritas dari design criteria, dengan menentukan kriteriakriteria 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