1. BAB I PENDAHULUAN
2.8. Tools Perencanaan Arsitektur Enterprise
2.8.4. Rich Picture
Menurut Valente dan Marchetti (2010 : 1), rich picture merupakan pengetahuan tentang domain dan harus membimbing para pengembang sistem selama fase awal definisi dan konstruksi prototipe sistem.
Penciptaan rich picture adalah kegiatan awal desain, tahap dimana pengembang sistem harus membingkai masalah untuk menemukan solusi yang memadai, berfokus pada teknologi berorientasi objek.
Menurut Mathiassen (dalam Khairunisa, 2013 : 33), rich picture adalah sistem atau situasi dengan menggunakan gambar-gambar. Gambaran keseluruhan dari orang, objek, proses, struktur dan masalah pada keseluruhan proses bisnis yang ada di perusahaan. Rich picture juga merupakan gambaran informal yang mempresentasikan pemahaman ilustrator terhadap situasi yang ada. Rich picture memberikan deskripsi yang luas mengenai suatu situasi yang memungkinkan adanya interpretasi yang berbeda-beda. Tahap ini dilakukan untuk memperoleh pandangan menyeluruh terhadap situasi dan berbagai cara orang menginterpretasikannya.
Rich picture adalah gambaran dari aspek-aspek penting yang dapat membantu pengguna sistem untuk memahami sistem yang sedang dikembangkan (Pratiwi, 2013 : 60). Rich picture difokuskan pada aspek penting dari sistem yang ditentukan sendiri oleh pengembang sistem dengan mengunjungi perusahaan untuk melihat bagaimana perusahaan beroperasi, berbicara dengan banyak orang untuk mengetahui apa yang harus terjadi, dan mungkin melakukan wawancara formal.
Pengadu
E-Pengaduan
1. Login
Subbag Penerimaan & Registrasi Pengaduan 3. Me ne rima N o. Pe ng ad ua n & Ta nd a T erima Be rka s Pe ng ad uan
4. Mengecek berkas pengaduan (verifikasi formil)
5. Memberikan hasil verifikasi formil 6. Me lih at ha si l ve rifika si formi l 2. Mengisi form pengaduan
7. Menginput No. Pengaduan (jika lolos verifikasi formil)
8. Mengupload berkas pelengkap (jika belum lolos verifikasi formil)
Subbag Analisis & Verifikasi Pengaduan
9. Mengecek berkas pengaduan sesuai No. Pengaduan (verifikasi materiil)
10. Memberikan hasil verifikasi materiil
11. Submit berkas pengaduan yang lolos verifikasi materiil 12. Melihat hasil verifikasi materiil
13. Mengupload berkas pelengkap (jika BMS verifikasi materiil)
Gambar 2.6 Contoh Rich Picture
Gambar 2.6 merupakan contoh rich picture aktivitas pengaduan di DKPP. Rich picture mempunyai fungsi yang sama dengan flowchart, yaitu untuk menjelaskan alur suatu aktivitas. Tetapi, rich picture menggunakan gambar (simbol) yang lebih mudah dimengerti bagi user. Gambar 2.5 melibatkan tiga stakeholder, yaitu Pengadu, Subbagian Penerimaan dan Registrasi Pengaduan, Subbagian Analisis dan Verifikasi Pengaduan. Rancangan ini akan mengubah sistem pengaduan yang masih manual menjadi sistem terkomputerisasi melalui e-Pengaduan.
pengaduan dan mengupload berkas pengaduan dalam e-Pengaduan. Selanjutnya, Pengadu akan menerima nomor pengaduan dan tanda terima berkas pengaduan dari sistem.
Staf Subbagian Penerimaan dan Registrasi Pengaduan akan mengecek berkas pengaduan yang telah masuk ke sistem e-Pengaduan. Setelah dilakukan verifikasi formil, staf Subbagian Penerimaan dan Registrasi Pengaduan akan memberi tahu hasil verifikasi formil melalui e-Pengaduan.
Pengadu akan melihat hasil verifikasi formil di e-Pengaduan. Jika berkas pengaduan lolos verifikasi formil, maka Pengadu harus memasukkan nomor pengaduan ke dalam sistem e-Pengaduan. Jika berkas pengaduan masih BMS (Belum Memenuhi Syarat), maka Pengadu harus mengupload kekurangan berkasnya.
Setelah nomor pengaduan dimasukkan ke dalam sistem e-Pengaduan, maka akan dilakukan verifikasi materiil untuk berkas pengaduan tersebut oleh Subbagian Analisis dan Verifikasi. Setelah sudah terpilih berkas pengaduan yang lolos verifikasi materiil, maka staf Subbagian Analisis akan memasukkan daftar berkas pengaduan yang lolos ke dalam sistem e -Pengaduan.
Pengadu melihat hasil verifikasi materiil dalam sistem e-Pengaduan. Jika berkas pengaduannya lolos verifikasi materiil, maka Pengadu tinggal menunggu pemberitahuan selanjutnya untuk sidang. Jika berkas pengaduannya BMS (Belum Memenuhi Syarat), maka Pengadu harus segera
mengupload kekurangan berkasnya agar pengaduan tersebut dapat segera dilanjutkan ke dalam sidang.
2.8.5. UML (Unified Modelling Language)
UML (Unified Modelling Language) merupakan bahasa visual untuk pemodelan dan komunikasi mengenai sebuah sistem dengan menggunakan diagram dan teks-teks pendukung (A.S & Shalahuddin, 2011 : 118).
UML hanya berfungsi untuk melakukan pemodelan. Jadi, penggunaan UML tidak terbatas pada metodologi tertentu. UML muncul karena adanya kebutuhan pemodelan visual untuk menspesifikasikan, menggambarkan, membangun dan dokumentasi dari sistem perangkat lunak.
UML mempunyai sejumlah elemen grafis yang bisa dikombinasikan menjadi diagram. Karena UML merupakan sebuah bahasa maka UML mempunyai sejumlah aturan untuk menggabungkan elemen-elemen tersebut. Berikut ini adalah beberapa diagram yang ada pada UML.
1. Use Case Diagram
Use case diagram adalah pemodelan untuk behaviour sistem informasi yang akan dibuat. Use case mendeskripsikan sebuah interaksi antara satu atau lebih aktor dengan sistem informasi yang akan dibuat (A.S & Shalahuddin, 2011 : 130).
Dalam pembicaraan tentang use case, pengguna biasanya disebut dengan aktor. Aktoradalah sebuah peran yang bisa dimainkan oleh pengguna dalam interaksinya dengan sistem. Use case adalah alat bantu terbaik untuk
menstimulasi pengguna potensial untuk mengatakan tentang suatu sistem dari sudut pandangnya. Ide dasarnya adalah bagaimana melibatkan pengguna sistem di fase-fase awal analisis dan perancangan sistem.
Secara kasar, use case digunakan untuk mengetahui fungsi apa saja yang ada di dalam sebuah sistem informasi dan siapa saja yang berhak menggunakan fungsi-fungsi tersebut.
Menurut A.S. & Shalahuddin (2011 : 131), use case memiliki dua hal utama, yaitu :
a. Aktor merupakan orang, proses atau sistem lain yang berinteraksi dengan sistem informasi yang akan dibuat di luar sistem informasi yang akan dibuat itu sendiri. Jadi, walaupun simbol dari aktor adalah gambar orang, tapi aktor belum tentu merupakan orang.
b. Use case adalah fungsionalitas yang disediakan sistem sebagai unit-unit yang saling bertukar pesan antar unit atau aktor.
Berikut ini adalah daftar simbol yang digunakan di dalam use case diagram (A.S. & Shalahuddin, 2011 : 131 – 133) :
Tabel 2.4 Daftar Simbol Use Case Diagram
Simbol Deskripsi
Use Case Fungsionalitas yang disediakan
sistem sebagai unit-unit yang saling bertukar pesan antar unit atau aktor; biasanya dinyatakan dengan menggunakan kata kerja di awal frase nama use case.
Aktor (actor) Orang, proses, atau sistem lain yang berinteraksi dengan sistem informasi yang akan dibuat di luar sistem informasi yang akan dibuat itu sendiri; biasanya dinyatakan menggunakan kata benda di awal frase nama aktor.
Asosiasi (association) Komunikasi antara aktor dan use case yang berpartisipasi pada use case.
Ekstensi (extend) Relasi use case tambahan ke sebuah use case dimana use case yang ditambahkan dapat berdiri sendiri walau tanpa use case tambahan; biasanya use case tambahan memiliki nama depan yang sama dengan use case yang ditambahkan. Contoh :
Arah panah mengarah pada use case yang ditambahkan.
Generalisasi (generalization) Hubungan generalisasi dan spesialisasi (umum – khusus) antara dua buah use case dimana fungsi yang satu adalah fungsi yang lebih umum dari lainnya. Contoh :
Arah panah mengarah pada use case yang menjadi generalisasinya (umum).
Menggunakan (include)
Relasi use case tambahan ke sebuah use case dimana use case yang ditambahkan memerlukan use case ini untuk menjalankan fungsinya atau sebagai syarat dijalankan use case ini.
Dua sudut pandang mengenai include di use case, yaitu :
1. Include berarti use case yang ditambahkan akan selalu dipanggil saat use case tambahan dijalankan. Contoh :
2. Include berarti use case yang tambahan akan selalu melakukan pengecekan apakah use case yang ditambahkan telah dijalankan sebelum use case tambahan dijalankan. Contoh :
Kedua sudut pandang tersebut dapat digunakan salah satu atau keduanya, tergantung pada pertimbangan dan sudut pandang yang dibutuhkan.
Gambar 2.7 Use Case Diagram
Gambar 2.7 menjelaskan use case diagram untuk arsitektur aplikasi E-Pengaduan. Arsitektur aplikasi e-Pengaduan memiliki 10 aktor dan 8 use
Manajemen User Verifikasi Administrasi Registrasi Pengaduan Pemberitahuan Verifikasi Verifikasi Materiil Admin
Staf Subbag Penerimaan & Registrasi Pengaduan
Pengadu Staf Subbag TU
Kasubbag Analisis & Verifikasi
Staf Subbag Analisis & Verifikasi Tim Verifikasi Materiil Ketua DKPP Kepala Biro DKPP Lihat Laporan Kabag Administrasi Pengaduan Logout Login <<include>>
terlibat, yaitu Admin, Kepala Bagian Administrasi Pengaduan, Kepala Subbagian Analisis dan Verifikasi, Kepala Biro DKPP, Ketua DKPP, Pengadu, Staf Subbagian Analisis dan Verifikasi, Staf Subbagian Penerimaan dan Registrasi Pengaduan, Staf TU, Tim Verifikasi Materiil.
Use case yang terlibat dalam sistem e-Pengaduan, yaitu login, logout, manajemen user, laporan, pemberitahuan verifikasi, registrasi pengaduan, verifikasi administrasi, verifikasi materiil.
Use case login dan logout melibatkan semua aktor. Use case manajemen user hanya melibatkan aktor Admin. Use case registrasi pengaduan melibatkan aktor Pengadu dan Staf Subbagian Penerimaan dan Registrasi Pengaduan. Use case verifikasi administrasi hanya melibatkan aktor Staf Subbagian Penerimaan dan Registrasi Pengaduan. Use case verifikasi materiil melibatkan aktor Kepala Subbagian Analisis dan Verifikasi, Staf Subbagian Analisis dan Verifikasi, Tim Verifikasi Materiil. Use case pemberitahuan verifikasi melibatkan aktor Pengadu dan Staf TU. Use case Laporan melibatkan aktor Ketua DKPP, Kepala Biro DKPP, Kepala Bagian Administrasi Pengaduan.
3. Class Diagram
Class diagram menggambarkan struktur sistem dari segi pendefinisian kelas-kelas yang akan dibuat untuk membangun sistem (A.S & Shalahuddin, 2011 : 122). Class diagram memiliki atribut dan operasi (metode). Atribut
merupakan variabel-variabel yang dimiliki oleh suatu kelas. Operasi (metode) adalah fungsi-fungsi yang dimiliki oleh suatu kelas.
Class diagram memiliki beberapa jenis kelas, yaitu :
Kelas utama : memiliki fungsi awal dieksekusi ketika sistem dijalankan.
Kelas tampilan sistem : mendefinisikan dan mengatur tampilan ke user.
Kelas dari pendefinisian use case : menangani fungsi-fungsi yang harus
ada, diambil dari pendefinisian use case.
Kelas dari pendefinisian data : digunakan untuk memegang atau
membungkus data menjadi sebuah kesatuan yang diambil maupun akan disimpan ke basis data.
Berikut ini adalah simbol-simbol yang digunakan dalam class diagram ( A.S. & Shalahuddin, 2011 : 123) :
Tabel 2.5 Daftar Simbol Class Diagram
Simbol Deskripsi
Kelas Kelas pada struktur sistem.
Antarmuka (interface) Sama seperti konsep interface dalam pemrograman berorientasi objek.
Asosiasi (association) Relasi antar kelas dengan makna umum; biasanya disertai dengan multiplicity.
Asosiasi berarah (directed association) Relasi antar kelas dengan makna kelas yang satu digunakan oleh kelas yang lain; biasanya disertai dengan multiplicity.
Generalisasi (generalization) Relasi antar kelas dengan makna generalisasi – spesialisasi (umum –
khusus).
Kebergantungan (depedency) Relasi antar kelas dengan makna kebergantungan antar kelas.
Gambar 2.8 merupakan class diagram dari arsitektur data E-Pengaduan. Arsitektur data e-Pengaduan memiliki 13 kelas, yaitu, Bagian, Subbagian, Level, Jabatan, Pegawai, User, Panel_Majelis, Saksi, Pengaduan, Pencatatan_Perkara, Pengadu, Teradu, Form_Pengaduan.
Kelas Bagian memiliki multiplicity 1 * (satu ke banyak) terhadap kelas Subbagian. Kelas Subbagian memiliki multiplicity 1 * (satu ke banyak) terhadap kelas Pegawai. Kelas Level memiliki multiplicity 1 * (satu ke banyak) terhadap kelas Pegawai. Kelas Jabatan memiliki multiplicity 1 1 (satu ke satu) terhadap kelas Pegawai. Kelas Pegawai memiliki multiplicity 1 1 (satu ke satu) terhadap kelas User. Kelas User memiliki multiplicity 1 * (satu ke banyak) terhadap kelas Panel_Majelis, kelas Saksi, kelas Pengaduan, kelas Pencatatan_Perkara, kelas Pengadu, dan kelas Teradu. Kelas User memiliki multiplicity 1 1..* (satu ke antara satu sampai banyak) terhadap kelas Form_Pengaduan. Kelas Teradu memiliki multiplicity 1 1..* (satu ke antara satu ke banyak) terhadap kelas Pencatatan_Perkara. Kelas Pengadu memiliki multiplicity 1 1..* (satu ke antara satu sampai banyak)terhadap kelas Pencatatan_Perkara. Kelas Pengaduan memiliki multiplicity 1 1 (satu ke satu) terhadap kelas Pencatatan_Perkara.
Principles catalog bertujuan untuk menangkap prinsip-prinsip bisnis dan arsitektur yang menggambarkan solusi atau arsitektur seperti apa yang baik. Prinsip-prinsip digunakan untuk mengevaluasi dan menyetujui hasil keputusan arsitektur. Prinsip juga digunakan sebagai alat bantu untuk membantu dalam tata arsitektur perubahan (The Open Group, 2009 : 421).
Tabel 2.6 Principles Catalog
No. Prinsip Tujuan
1. Arsitektur yang dibuat harus sesuai dengan tujuan, aktivitas, serta tugas pokok dan fungsi (tupoksi) di DKPP
Mendukung aktivitas dan tupoksi di DKPP.
Memperkuat hubungan antara aktivitas dan infrastruktur untuk memudahkan penyelarasan aktivitas terhadap perubahan. 2. Pengelolaan arsitektur harus user
friendly
Meningkatkan kemampuan sharing data dan sumber daya lain dalam pelayanan kepada user.
Membantu kerja sama antar bagian.
3. Arsitektur yang dikembangkan harus aman
Agar tidak membahayakan keamanan dan kerahasiaan data, serta teknologi yang ada di DKPP.
Meminimalkan dampak dari bencana.
Mampu bertahan dari serangan virus, spyware, hack, worm.
Tabel 2.6 menjelaskan prinsip-prinsip beserta tujuan masing-masing dari tiap prinsip untuk membantu stakeholder dalam mengevaluasi dan
menyetujui perubahan arsitektur yang akan diusulkan. Salah satu prinsip, yaitu arsitektur yang dikembangkan harus aman. Tujuan dari prinsip itu agar arsitektur yang diusulkan tidak membahayakan keamanan dan kerahasiaan data dan teknologi yang ada di DKPP, arsitektuur yang diusulkan pun harus mampu bertahan dari serangan virus, spyware, hack, worm, atau bencana.
2.8.7. Actor/Role Matrix
Tujuan actor/role matrix adalah untuk menunjukkan aktor dan juga peranannya. Memahami hubungan aktor dengan peranannya adalah pendukung utama dari pendefinisian kebutuhan pelatihan, pengaturan keamanan user dan manajemen perubahan organisasi (The Open Group, 2009 : 426).
Tabel 2.7 merupakan actor/role matrix untuk aktivitas pengaduan di DKPP. Kolom pada matriks adalah bagian dan subbagian yang ada di DKPP (aktor), sedangkan baris pada matriks adalah unit aktivitas terkecil (business function) dalam aktivitas pengaduan. Dalam matriks ini ada keterangan RACI (Responsible, Accountable, Consulted, Informed) yang menghubungkan kolom aktor dengan baris unit aktivitas terkecil pada aktivitas pengaduan. Keterangan Responsible menyatakan bahwa suatu aktor melakukan suatu kegiatan atau pekerjaan. Keterangan Accountable menyatakan bahwa suatu aktor bertanggung jawab dan memiliki otoritas untuk memutuskan perkara. Keterangan Consulted menyatakan bahwa seorang aktor diperlukan saran dan kontribusinya terhadap suatu kegiatan. Keterangan Informed menyatakan bahwa seorang aktor perlu mengetahui hasil dari keputusan dalam suatu tindakan.
Untuk kegiatan penerimaan dan registrasi pengaduan, Kepala DKPP RI, Kepala Biro Administrasi DKPP, Kabag Administrasi Pengaduan, dan Kasubbag Penerimaan dan Registrasi Pengaduan memiliki keterangan Informed, yang berarti mereka perlu mengetahui laporan dari kegiatan penerimaan dan registrasi pengaduan. Sedangkan, Staf Subbag Penerimaan dan Registrasi Pengaduan memiliki keterangan Responsible, yang berarti staf tersebut yang secara langsung melakukan kegiatan penerimaan dan registrasi pengaduan.
Untuk kegiatan pemberkasan perkara, Kabag Administrasi Pengaduan memiliki keterangan Informed, yang berarti Kabag Administrasi Pengaduan
perlu mengetahui laporan mengenai pemberkasan perkara. Kasubbag Penerimaan dan Registrasi Perkara memiliki keterangan Accountable dan Consulted, yang berarti Kasubbag Penerimaan dan Registrasi Perkara bertanggung jawab dan sarannya dibutuhkan dalam kegiatan pemberkasan perkara. Sedangkan, Staf Subbag Penerimaan dan Registrasi Pengaduan memiliki keterangan Responsible, yang berarti staf tersebut yang secara langsung melakukan kegiatan pemberkasan perkara.
Untuk kegiatan analisis dan verifikasi pengaduan, Kepala DKPP RI, Kepala Biro Administrasi DKPP, Kabag Administrasi Pengaduan, dan Kasubbag Penerimaan dan Registrasi Pengaduan memiliki keterangan Informed, yang berarti mereka perlu mengetahui laporan dari kegiatan analisis dan verifikasi pengaduan. Kasubbag Analisis dan Verifikasi Pengaduan Wilayah 1 dan 2 memiliki keterangan Accountable dan Consulted, yang berarti Kasubbag Analisis dan Verifikasi Pengaduan Wilayah 1 dan 2 bertanggung jawab dan sarannya dibutuhkan dalam kegiatan analisis dan verifikasi pengaduan. Sedangkan, Staf Subbag Analisis dan Verifikasi Pengaduan Wilayah 1 dan 2 memiliki keterangan Responsible, yang berarti staf tersebut yang secara langsung melakukan kegiatan analisis dan verifikasi pengaduan.