9
II TINJAUAN PUSTAKA 2.1 Penelitian Sebelumnya Penelitian mengenai arsitektur sistem informasi telah menarik perhatian baik untuk lingkungan perguruan tinggi (PT) maupun pemerintahan daerah (Pemda). Mutyarini dan Sembiring (2006) telah melakukan penelitian tentang arsitektur sistem informasi untuk institusi perguruan tinggi di Indonesia. Tujuan penelitian ini adalah untuk menghasilkan model kerangka dasar arsitektur sistem informasi untuk institusi perguruan tinggi di Indonesia. Penelitian ini dilakukan dengan menggunakan perpaduan prinsip-prinsip dalam metode TOGAF ADM dan Control Objectives for Information and Related Technology (COBIT). Hasil dari penelitian ini berupa rancangan kerangka dasar sistem informasi untuk institusi perguruan tinggi di Indonesia. Penelitian tersebut merupakan konsep awal sehingga perlu dilakukan pengukuran hasilnya. Selain itu Priantoto (2008) menjelaskan tentang cetak biru data, aplikasi dan teknologi yang dilakukan di pemerintahan Kabupaten Barito Utara untuk pelayanan perizinan. Hasil dari penelitian tersebut yaitu adanya perencanaan arsitektur enterprise yang berupa panduan lengkap dalam membuat cetak biru pengembangan e-government untuk data, aplikasi dan teknologi bagi pelayanan perizinan terpadu. Namun dari penelitian yang dilakukan belum terdapat metode untuk seberapa baik dalam mengukur kualitas cetak biru yang dihasilkan. Dari penelitian tersebut, peneliti ingin mengembangkan perencanaan arsitektur enterprise pada pelaksanaan SDM yang sekaligus mampu mengukur kualitas dari cetak biru dan prototipe yang dihasilkan. Dengan demikian yang membedakan dalam penelitian ini adalah obyek penelitian (SDM di Badan Litbang Pertanian), adanya implementasi dengan metode pengembangan prototipe, serta pengukuran terhadap hasil cetak biru dan prototipe. 2.2 Arsitektur Enterprise Kata arsitektur enterprise terdiri dari dua kata yaitu arsitektur dan enterprise.
Arsitektur
merupakan
perancangan
dari
suatu
benda
atau
merepresentasikan suatu gambaran yang sesuai dengan suatu obyek sehingga dapat diperoleh hasil yang sesuai dengan kebutuhan dan berkualitas (Zachman
10 1997). Sedangkan menurut CIO Council (2001) arsitektur enterprise adalah struktur dari komponen-komponen yang saling berhubungan satu dengan yang lainnya, serta terdapat prinsip dan aturan-aturan dalam merancang yang berkembang dari waktu ke waktu. Definisi lain menyatakan arsitektur adalah pengorganisasian mendasar dari sistem yang terdiri dari beberapa komponen yang saling berhubungan dan prinsip-prinsip yang digunakan sebagai pedoman dalam merancang dan mengembangkan suatu sistem. Arsitektur juga merupakan suatu komponen yang penting dalam keberhasilan pengembangan dan evolusi dari suatu sistem perangkat lunak (Hilliard 2000). Dari definisi tersebut maka dapat digambarkan bahwa arsitektur merupakan suatu rancangan dari obyek yang terdiri dari komponen-komponen yang saling berhubungan dalam bentuk cetak biru untuk dijadikan dasar dalam mewujudkan suatu hasil yang nyata. Arsitektur juga menyiratkan suatu perencanaan yang diwujudkan dengan model dan gambar dari komponen dari sesuatu dengan berbagai sudut pandang (Surendro 2009). Sedangkan definisi dari enterprise adalah suatu informasi strategis berdasarkan aset yang mendefinisikan misi, kebutuhan informasi untuk melakukan misi, dan proses peralihan untuk mengimplementasikan teknologi baru dalam merespon kebutuhan perubahan misi. Arsitektur enterprise meliputi gambaran dasar arsitektur, arsitektur target, dan rencana berkelanjutan (Rumapea & Surendro 2007). Dari definisi di atas, arsitektur enterprise merupakan basis aset informasi strategis, yang menentukan misi, informasi dan teknologi yang dibutuhkan untuk melaksanakan misi, dan proses transisi untuk mengimplementasikan teknologi baru sebagai tanggapan terhadap perubahan kebutuhan misi (CIO council 2001). Sedangkan menurut Mutyarini dan Sembiring (2006) arsitektur enterprise merupakan suatu pengorganisasian data yang diperoleh dan digunakan oleh suatu organisasi untuk mencapai tujuan proses bisnis. Dengan memahami definisi arsitektur, enterprise, dan arsitektur enterprise, maka dapat dinyatakan arsitektur enterprise merupakan suatu pengorganisasian dari suatu model, prinsip dan metode yang mempunyai logika sehingga dapat digunakan dalam merancang dan menyatakan struktur organisasi enterprise, proses bisnis, sistem informasi dan infrastrukturnya (Surendro 2009).
11 Sama seperti arsitektur yang lain, hasil dari arsitektur enterprise ini terdiri dari dokumen-dokumen seperti gambar, diagram, model, dokumen dalam bentuk teks. Keseluruhan dokumen tersebut akan menjelaskan seperti apa sistem informasi yang akan dibutuhkan oleh suatu organisasi. Kemudian dalam mengembangkan sistem informasi tersebut, arsitektur enterprise akan dijadikan suatu acuan atau pedoman bagi pengembang sistem informasi. 2.3 Kerangka Kerja Arsitektur Enterprise Kerangka kerja merupakan suatu ide, pemikiran, dan konsep yang digunakan untuk membuat pemikiran lain yang lebih spesifik dalam suatu obyek. Kerangka kerja juga dapat digunakan untuk mengelompokkan suatu organisasi yang penting bagi manajemen organisasi tersebut dan digunakan juga dalam pengembangan sistem perusahaan yang akan datang (Zachman 1996). Kerangka kerja arsitektur enterprise memiliki beberapa kegunaan diantaranya adalah dapat mengidentifikasikan suatu jenis informasi yang dibutuhkan organisasi untuk menggambarkan arsitektur enterprise. Kerangka kerja arsitektur enterprise juga dapat mengelompokkan jenis informasi dalam struktur yang logis, dan menggambarkan hubungan antara jenis informasi tersebut (Setiawan 2009a). Dalam mengembangkan suatu arsitektur enterprise, perlu dilakukan penerapan atau pengembangan kerangka kerja arsitektur enterprise, karena kerangka kerja tersebut dapat membantu arsitek untuk memotret arsitektur organisasi dari berbagai sudut pandang dan aspek, sehingga diperoleh gambaran struktur organisasi secara utuh. Dalam pengembangan sebuah arsitektur enterprise akan lebih baik dan lebih mudah jika mengikuti sebuah kerangka berpikir tertentu. Kerangka berpikir tersebut dikenal dengan istilah enterprise architecture (EA) framework. Menurut CIO Council (2001) sebuah architecture framework adalah suatu alat yang bisa digunakan untuk mengembangkan cakupan luas dari arsitektur-arsitektur yang berbeda. Architecture framework harus mendeskripsikan sebuah metode untuk merancang sistem informasi dalam term kumpulan building block dan memperlihatkan bagaimana building block tersebut sesuai antara satu dengan yang lainnya. Penggunaan EA framework akan mempercepat dan menyederhanakan
12 pengembangan arsitektur, memastikan cakupan yang lengkap dari solusi desain dan memastikan arsitektur yang terpilih akan memungkinkan pengembangan di masa depan sebagai respon terhadap kebutuhan binis (Setiawan 2009a). Pada saat ini terdapat beberapa kerangka kerja arsitektur enterprise diantaranya adalah kerangka kerja Zachman, federal enterprise architecture framework (FEAF), dan the open group architectural framework (TOGAF). Ketiga kerangka kerja tersebut menurut hasil survei yang dilakukan oleh Institute for Enterprise Architecture Development (IFEAD 2005) merupakan kerangka kerja yang paling banyak digunakan di perusahaan atau pemerintahan selain kerangka kerja yang dibuat sendiri. Selanjutnya menurut hasil survei yang dilakukan oleh Institute for Enterprise Architecture Development (IFEAD 2005) menyatakan bahwa dari beberapa framework tersebut, yang paling banyak digunakan di perusahaan atau pemerintahan selain framework sendiri adalah Zachman (25%), TOGAF (11%), dan FEAF (9%). 2.3.1 Kerangka Kerja Zachman Kerangka kerja Zachman merupakan salah satu kerangka kerja yang digunakan untuk mengembangkan arsitektur enterprise yang telah diperkenalkan oleh Zachman sejak tahun 1987. Kerangka kerja Zachman merupakan suatu alat bantu yang dikembangkan untuk memotret arsitektur organisasi dari berbagai sudut pandang dan aspek, sehingga didapatkan gambaran organisasi secara utuh (Setiawan 2009a). Menurut Zachman (2009), kerangka kerja Zachman adalah suatu skema yang merupakan pertemuan antara dua klasifikasi yang telah digunakan selama ribuan tahun. Pertama adalah dasar-dasar komunikasi yang ditemukan di dalam pertanyaan-pertanyaan klasik seperti What, How, When, Who, Where dan Why. Pertanyaan-pertanyaan ini mengintegrasikan jawaban dari pertanyaan yang komprehensif dan gambaran dari ide yang kompleks. Kedua adalah berasal dari reification, yaitu transformasi dari ide abstrak menjadi sesuatu yang instantiation dimana telah didalilkan oleh filosof Yunani kuno dan dilabelkan pada framework Zachman sebagai identifikasi, definisi, representasi, spesifikasi, konfigurasi dan instansiasi. Sedangkan Kozina (2006) menyatakan bahwa konsep Zachman merupakan suatu framework yang digunakan untuk
13 pemodelan, evaluasi, optimisasi, manajemen, dan pendokumentasian pada sistem bisnis. Dari definisi di atas, maka dapat disimpulkan bahwa framework Zachman merupakan suatu alat bantu berfikir bagi arsitek atau manajer dalam memetakan permasalahan atau memotret arsitektur yang terdapat di suatu organisasi sehingga didapatkan gambaran organisasi yang lebih sederhana dan utuh. Framework Zachman untuk arsitektur enterprise yang terdiri dari 6 baris dan 6 kolom dapat dilihat pada Gambar 1.
Gambar 1 Arsitektur kerangka kerja Zachman (Kozina 2006). Framework
Zachman
bukan
suatu
metodologi
untuk
membuat
implementasi dari suatu obyek, namun framework ini merupakan ontologi untuk menggambarkan arsitektur enterprise. Ontologi merupakan suatu struktur sedangkan metodologi adalah suatu proses. Jadi framework Zachman adalah suatu struktur bukan merupakan suatu proses. Suatu struktur akan membentuk suatu definisi sedangkan proses akan menyajikan transformasi. Setiap framework yang digunakan untuk arsitektur enterprise mempunyai karakteristik yang berbeda. Pada kerangka kerja Zachman terdapat beberapa karakteristik diantaranya yaitu dapat mengkategorikan deliverables dari enterprise architecture (EA), kegunaan EA sangat terbatas, banyak diadopsi di seluruh
14 dunia, perspektif view kurang menyeluruh dan merupakan suatu alat untuk perencanaan (Setiawan 2009a). Selain karakteristik, terdapat juga kelebihan dan kelemahan dari framework Zachman. Menurut Mutyarini dan Sembiring (2006), kelebihan dari kerangka kerja ini adalah : •
Merupakan standar secara de-facto untuk mengklasifikasi artefak (objek atau deskripsi penyajian arsitektural) arsitektur enterprise.
•
Struktur logical untuk analisis dan presentasi artefak dari suatu perspektif manajemen.
•
Menggambarkan secara paralel baik dari sisi rekayasa yang sudah sangat dimengerti maupun paradigma konstruksi.
•
Dikenal secara luas sebagai alat manajemen untuk memeriksa kelengkapan arsitektur dan maturity level.
Sedangkan kelemahannya adalah : •
Tidak terdapat proses untuk tahap implementasi.
•
Sulit untuk diimplementasikan secara keseluruhan.
•
Tidak terdapat contoh maupun checklist yang siap secara utuh.
•
Perluasan cakupan sel-sel tidak jelas.
2.3.2 Kerangka Kerja The Open Group Architecture Framework (TOGAF) TOGAF
merupakan
kerangka
kerja
arsitektur
enteprise
yang
dikembangkan oleh The Open Group’s Architecture Framework pada tahun 1995 yang digunakan untuk mengembangkan arsitektur perusahaan. Pada mulanya TOGAF digunakan oleh Departemen Pertahanan Amerika Serikat, namun pada perkembangannya banyak digunakan pada berbagai bidang seperti industri manufaktur, perbankan, pendidikan, dan lain sebagainya. TOGAF digunakan untuk mengembangkan arsitektur enterprise, dimana terdapat metode dan alat yang detail untuk mengimplementasikannya. Hal inilah yang membedakan dengan kerangka kerja arsitektur enterprise yang lain. Salah satu kelebihan dari kerangka kerja ini adalah sifatnya yang fleksibel dan open source (Setiawan 2009a). TOGAF mendeskripsikan 4 subset arsitektur enterprise, yaitu : •
Business architecture, yaitu mendeskripsikan tentang bagaimana proses bisnis untuk mencapai tujuan organisasi.
15 •
Data
architecture,
adalah
penggambaran
bagaimana
penyimpanan,
pengelolaan, dan pengaksesan data pada perusahaan. •
Application architecture, merupakan pendeskripsian bagaimana suatu aplikasi dirancang dan bagaimana interaksi dengan aplikasi lain.
•
Technology architecture, yaitu gambaran infrastruktur perangkat lunak dan perangkat keras yang mendukung aplikasi dan bagaimana interaksinya dengan aplikasi yang lain. TOGAF adalah salah satu metode yang paling banyak diterima untuk
mengembangkan arsitektur perusahaan. TOGAF merupakan suatu kerangka kerja yang praktis, pasti dan dibuktikan dengan adanya tahapan-tahapan metode untuk mengembangkan dan mempertahankan arsitektur enterprise (Ugavina 2009). Secara umum TOGAF memiliki struktur dan komponen-komponen, yaitu : 1.
Architecture Development Method (ADM). ADM merupakan bagian utama dari TOGAF yang menjelaskan bagaimana menentukan sebuah arsitektur enterprise secara khusus sesuai dengan kebutuhan.
2.
Foundation Architecture (Enterprise Continuum). Foundation architecture merupakan sebuah “framework-within-a-framework” yang menyajikan gambaran hubungan bagi pengumpulan arsitektur yang relevan dan menyediakan bantuan petunjuk pada waktu terjadi perpindahan abstraksi level yang berbeda. Di dalam foundation architecture terdapat tiga bagian yaitu technical reference model, standard information, dan building block information base.
3.
Resource Base. Pada bagian ini memberikan informasi berupa guidelines, templates, checklist, latar belakang informasi dan detail material pendukung yang membantu arsitek dalam penggunaan ADM. TOGAF mewujudkan konsep enterprise continuum untuk mencerminkan
tingkat abstraksi yang berbeda dalam sebuah proses pembangunan arsitektur. Dengan cara ini TOGAF memfasilitasi pemahaman dan kerjasama antara aktor pada tingkat yang berbeda. TOGAF menyediakan konteks bagi penggunaan dari beberapa kerangka kerja, model, dan aset arsitektur dalam hubungannya dengan TOGAF ADM. Dengan cara enterprise continuum, arsitek didorong untuk memanfaatkan semua sumber daya arsitektur lain yang relevan dan aset-aset.
16 Selain itu TOGAF sebagai dasar arsitektur dalam mengembangkan teknologi informasi di suatu organisasi. TOGAF terdiri atas 8 (delapan) fase yang berbentuk siklus (cycle). Pada fase ke-4 difokuskan pengembangan arsitektur teknologi. Fase-fase dalam metode TOGAF dapat dilihat pada Gambar 2. Prelim: Framework and Principles
H
A Architecture Vision
Architecture Change Management
G Implementation Governance
F Migration Planning
B Business Architecture
C Information Systems Architecture
Requirements Management
E Opportunities and Solutions
D Technology Architecture
Gambar 2 Proses pengembangan TOGAF ADM (Lankhorst & Drunen Hans van 2007). Dalam kerangka kerja ini terdapat kelebihan dan kelemahan. Menurut Mutyarini dan Sembiring (2006) menyebutkan bahwa kelebihan TOGAF adalah sebagai berikut: •
Fokus pada siklus implementasi (ADM) dan proses
•
Terdapat banyak area teknis arsitektur
•
Resource base menyediakan banyak material referensi
17 Sedangkan kelemahan dari TOGAF adalah sebagai berikut: •
Tidak terdapat templates standar untuk seluruh domain seperti dalam membuat blok diagram tidak terdapat template yang baku.
•
Tidak terdapat artefak yang dapat digunakan ulang (ready made)
2.3.3 Kerangka Kerja Federal Enterprise Architecture Framework (FEAF) FEAF
merupakan
suatu
kerangka
kerja
yang
ditujukan
untuk
mengembangkan arsitektur enterprise dalam sistem yang mempunyai multiple inter-agency (Setiawan 2009a). FEAF juga merupakan suatu kerangka kerja yang telah diperkenalkan sejak tahun 1999 oleh Federal CIO Council. FEAF menyediakan petunjuk untuk mengembangkan, merawat, dan memfasilitasi arsitektur enterprise di dalam pemerintahan pusat atau melewati batas multiple inter-agency (CIO Council 2001). FEAF menyediakan suatu standar untuk mengembangkan dan mendokumentasikan gambaran arsitektur pada area yang menjadi prioritas. FEAF membagi arsitektur ke dalam empat hal yaitu area bisnis, data, aplikasi, dan arsitektur teknologi (Gambar 3). Pada saat ini FEAF memasukkan tiga kolom pertama dari kerangka kerja Zachman dan metodologi perencanaan EA oleh Spewak. Arsitektur ini bertindak sebagai nilai acuan (reference point) untuk memfasilitasi koordinasi yang efisien dan efektif pada proses bisnis secara umum, penempatan teknologi, alur informasi, sistem, dan investasi antar agen pusat (federal agencies). FEAF menyajikan suatu struktur untuk mengembangkan, memelihara, dan mengimplementasikan lingkungan operasional pada tingkat atas dan mendukung implementasi pada sistem teknologi informasi (TI). Seperti yang ditunjukkan pada Gambar 4, FEAF merupakan representasi yang nyata sebagai matriks 3 x 5 dengan tipe-tipe arsitektur pada sumbu mendatar adalah data, aplikasi dan teknologi dan perspektif pada sumbu yang lainnya yaitu planner, owner, designer, builder, dan subcontractor. Hubungan antara produk EA terdapat pada kolom dari matriks.
18
Gambar 3 Struktur komponen FEAF (CIO Council 2001).
Data Architecture
Application Architecture
Technology Architecture
Planner Perspective
List of Business Objects
List of Business Processes
List of Business Locations
Owner Perspective
Semantic Model
Business Process Model
Business Logistics System
Designer Perspective
Logical Data Model
Application Architecture
Physical Data Model
System Design
Data Dictionary
Programs
Builder Perspective Subcontractor Perspective
System Geographic Deployment Architecture Technology Architecture Network Architecture
Gambar 4 Matriks arsitektur FEAF (CIO Council 2001). Pada kerangka kerja ini terdapat karakteristik-karakteristik yang menjadi ciri dari FEAF, yaitu : •
Merupakan arsitektur enterprise yang mereferensikan model
•
Merupakan standar yang digunakan oleh pemerintahan Amerika Serikat
•
Menampilkan perspektif view yang menyeluruh
•
Merupakan alat untuk perencanaan dan komunikasi
19 2.3.4 Pemilihan Kerangka Kerja Arsitektur Enterprise Menurut Setiawan (2009a) dalam pemilihan sebuah kerangka kerja arsitektur enterprise terdapat beberapa kriteria berbeda yang dapat dijadikan sebagai acuan, seperti : a.
Tujuan dari arsitektur enterprise dengan cara melihat bagaimana definisi dari setiap arsitektur dan pemahamannya, proses arsitektur yang telah ditentukan sehingga mudah untuk diikuti, serta dukungan terhadap evolusi arsitektur.
b.
Input untuk aktivitas arsitektur enterprise seperti pendorong bisnis dan input teknologi.
c.
Output dari aktivitas arsitektur enterprise seperti model bisnis dan desain transisional untuk evolusi dan perubahan. Berdasarkan kriteria-kriteria tersebut, maka kerangka kerja yang telah
diuraikan di atas dapat dipetakan dan hasil pemetaan ditunjukkan pada Tabel 1 (Setiawan 2009a). Tabel 1 Perbandingan kerangka kerja arsitektur enterprise Zachman Definisi arsitektur dan pemahamannya Proses arsitektur yang detail Dukungan terhadap evolusi arsitektur
Standardisasi
Architecture Knowledge Base Pendorong bisnis Input teknologi Model bisnis Desain transisional
FEAF
TOGAF
Ya
Ya, pada tahap persiapan
Tidak
Ya, ADM dengan 9 tahap yang detail
Ya
Ya, ada tahap perencanaan migrasi
Tidak
Tidak
Ya, menyediakan Technical Reference Model (TRM), informasi yang standar
Tidak
Ya
Ya
Parsial Tidak Ya
Ya Ya Ya
Tidak
Ya
Ya Ya Ya Ya, hasil dari tahap perencanaan migrasi
Parsial
Ya
Tidak
20 Zachman Kenetralan (neutrality) Menyediakan prinsip arsitektur
FEAF
TOGAF
Ya
Tidak
Ya
Tidak
Tidak, hanya untuk karakteristik FEAF
Ya
Dari hasil pemetaan kriteria tersebut disimpulkan bahwa untuk studi kasus enterprise yang belum memiliki arsitektur enterprise dan memerlukan pengembangan arsitektur enterprise yang mudah dan jelas, maka kerangka kerja yang cocok digunakan adalah TOGAF. 2.4 Perencanaan Arsitektur Enterprise Perencanaan
arsitektur
enterprise
(PAE)
merupakan
proses
mendefinisikan arsitektur untuk penggunaan informasi yang mendukung bisnis dan juga mencakup rencana untuk mengimplementasikan arsitektur tersebut (Surendro 2009). Dari definisi tersebut, terdapat tiga hal yang menjadi kata kunci yaitu : 1.
Mendefinisikan Perencanaan arsitektur enterprise mendefinisikan bisnis dan arsitekturnya, bukan merancang, sehingga dalam pelaksanaannya tidak dilakukan kegiatan merancang sistem, basis data, atau jaringan. Pekerjaan merancang dan implementasi sistem dilakukan setelah proses pendefinisian perencanaan arsitektur enterprise selesai.
2.
Arsitektur Terdapat tiga jenis arsitektur dalam perencanaannya yaitu arsitektur data, aplikasi, dan teknologi. Arsitektur di sini sama dengan blueprint, gambar, dokumen, atau model. Dalam perencanaannya, arsitektur mendefinisikan dan menggambarkan data, aplikasi, dan teknologi yang diperlukan untuk mendukung proses bisnis suatu perusahaan.
3.
Rencana Beberapa arsitektur mendefinisikan apa yang diperlukan, dan rencana pendukung mendefinisikan kapan arsitektur akan diimplementasikan.
21 2.5 Sistem Informasi Manajemen Sumberdaya Manusia Manajemen sumber daya manusia merupakan suatu pengelolaan sumber daya manusia pada suatu organisasi berdasarkan visi dan misi yang ditetapkan dalam mencapai suatu tujuan organisasi tersebut. Sumber daya manusia merupakan tulang punggung dari suatu perusahaan dan sangat berfungsi dalam membantu perusahaan untuk mencapai suatu tujuan yang ingin dicapai. Menurut McLeod dan Schell (2007), dalam menjalankan kegiatannya, sumber daya manusia mempunyai empat fungsi yaitu : 1.
Perekrutan dan penerimaan (recruiting and hiring) yaitu sumber daya manusia dapat membantu mencari pegawai baru dan memosisikan pegawai tersebut. Disamping itu sumber daya manusia juga dapat mempengaruhi, menasehati, serta menetapkan pegawai dalam suatu kondisi tertentu sesuai dengan kebijakan yang tepat.
2.
Pendidikan dan pelatihan (educating and training). Sumber daya manusia dapat mengurus program kegiatan pendidikan dan pelatihan yang dibutuhkan untuk meningkatkan kemampuan pengetahuan pegawai.
3.
Manajemen data pegawai (managing employee related data) merupakan suatu kegiatan yang dilakukan oleh sumber daya manusia dalam memelihara dan mengelola database pegawai dan memproses data tersebut untuk pengguna yang membutuhkan informasi.
4.
Administrasi
penghentian
dan
tunjangan
(termination
and
benefit
administration), yaitu suatu proses pemberian tunjangan kepada pegawai yang sesuai dengan pekerjaan yang dilakukan. Namun hal ini sangat menyulitkan bagi pengelola administrasi karena ketika seorang pegawai berhenti dari pekerjaannya, pengelola administrasi harus memproses administrasinya dan melakukan wawancara terhadap pegawai yang bersangkutan.
Wawancara
tersebut
bertujuan
untuk
mendapatkan
pembelajaran bagaimana perusahaan dapat melayani pegawai lebih baik lagi di masa yang akan datang. Setiap perusahaan mempunyai suatu sistem untuk mengumpulkan dan memelihara data pegawai, mentransfer data tersebut menjadi informasi, dan melaporkan informasi tersebut kepada pengguna. Sistem ini yang sering disebut
22 sebagai sistem informasi manajemen sumberdaya manusia (SIMSDM/HRIS) (McLeod & Schell 2007). SIMSDM juga merupakan sebuah bentuk interseksi/pertemuan antara bidang ilmu manajemen sumber daya manusia (MSDM) dan teknologi informasi. Sistem ini menggabungkan MSDM sebagai suatu disiplin yang utamanya mengaplikasikan bidang teknologi informasi ke dalam aktivitas-aktivitas MSDM seperti dalam hal perencanaan, serta menyusun sistem pemrosesan data dalam serangkaian langkah-langkah yang terstandardisasi dan terangkum dalam aplikasi perencanaan sumber daya perusahaan/enterprise resource planning (ERP). Secara keseluruhan sistem ERP bertujuan mengintegrasikan informasi yang diperoleh dari aplikasi-aplikasi yang berbeda ke dalam satu sistem basisdata yang bersifat universal. Keterkaitan dari modul kalkulasi finansial dan modul MSDM melalui satu basisdata yang sama merupakan hal yang sangat penting yang membedakannya dengan bentuk aplikasi lain yang pernah dibuat sebelumnya, menjadikan aplikasi ini lebih fleksibel namun juga lebih kaku dengan aturanaturannya. 2.5.1 Jenjang karier pegawai Setiap pegawai mengharapkan adanya karir yang meningkat dalam pekerjaan atau jabatan yang ditanganinya. Karier merupakan semua pekerjaan atau jabatan yang ditangani atau diemban selama masih bekerja dalam kehidupan seseorang (Handoko 2000). Dengan demikian karir merupakan pengembangan kinerja pegawai dalam bekerja sehingga diharapkan adanya kemajuan dan peningkatan dalam jabatan atau pangkat pada suatu organisasi. Menurut Irianto (2001) terdapat dua cara pendekatan untuk memahami makna karir. Pendekatan pertama memandang karir sebagai pemilikan (a property) dan jabatan dalam organisasi, dimana karir dilihat sebagai jalan keberhasilan seseorang dalam organisasi. Pendekatan kedua memandang karir sebagai suatu kualitas seorang pegawai dalam organisasi. Setelah setiap pegawai mengakumulasi serangkaian jabatan, posisi, dan pengalaman tertentu pendekatan ini mengakui kemajuan karir yang telah dicapai seseorang. Pola dasar pengembangan karir berdasarkan PP 100 Tahun 2000 mencakup unsur-unsur (LNRI, 2000) antara lain:
23 1.
Pendidikan yang meliputi pendidikan dasar (SD, SLTP), pendidikan umum (SMU) dan perguruan tinggi.
2.
Pendidikan dan pelatihan dalam jabatan yang meliputi pendidikan dan pelatihan kepemimpinan.
3.
Usia
4.
Masa kerja yaitu lamanya pegawai dalam bekerja.
5.
Pangkat atau golongan.
6.
Jabatan yaitu kedudukan yang menunjukkan tugas, tanggungjawab, wewenang, dan hak seorang pegawai.
7.
Daftar Penilaian Pelaksanaan Pekerjaan (DP3) yang meliputi kesetiaan, prestasi kerja, ketaatan, tanggungjawab, kejujuran, kerjasama, dan praktek kepemimpinan.
8.
Daftar Urut Kepangkatan (DUK) pegawai yang lebih tinggi urutan dan kepangkatannya diberi kesempatan terlebih dahulu untuk menduduki jabatan yang lowong.
2.5.2 Proses monitoring pengurusan administrasi pegawai Monitoring merupakan suatu tindakan yang dilakukan untuk mengawasi atau memantau proses dan perkembangan pelaksanaan program dengan fokus untuk mendapatkan informasi mengenai proses pelaksanaan program tersebut (BPS 2004). Begitu juga dalam proses pengurusan administrasi pegawai yang rantai birokrasinya panjang sehingga disamping pengelola administrasi, pegawai yang
bersangkutan
juga
perlu
memonitor
proses
pengurusan
proses
administrasinya. Dengan adanya proses monitoring pengurusan administrasi ini diharapkan pegawai yang bersangkutan mengetahui sudah sejauh mana posisi berkas proses pengurusan administrasinya dan dapat memperkirakan lamanya proses pengurusan administrasi yang bersangkutan dari mulai pengusulan sampai menerima hasilnya. Tujuan dilakukannya proses monitoring adalah untuk pemantauan proses pelaksanaan program dan sedapat mungkin petugas memberikan saran untuk mengatasi masalah yang terjadi. Hasil monitoring digunakan sebagai umpan balik untuk penyempurnaan pelaksanaan program (BPS 2004).
24 2.6 E-Government Dalam rangka penerapan e-government untuk menuju good governance maka konsep e-government harus diterapkan di setiap lembaga pemerintah tingkat pusat dan daerah. Model penerapan e-government di setiap lembaga akan sangat tergantung kepada tugas, fungsi, dan wewenang yang diemban oleh setiap lembaga pemerintah. Hal ini akan menentukan struktur data dan model bisnis yang mendasari model layanan dan arsitektur sistem informasi yang akan dikembangkan. Penerapan e-government di setiap lembaga pemerintah harus mengacu kepada kebijakan dan strategi nasional pengembangan e-government sesuai dengan instruksi presiden (INPRES) No. 3 Tahun 2003 (Menkominfo 2003). Definisi e-government di setiap negara berbeda-beda, tergantung pada pandangan dan tujuan dari negara tersebut terhadap teknologi informasi. Menurut Setiyadi (2001) dalam konteks makro, e-government mencakup penggunaan telematika (ICT) secara efektif dan efisien guna menunjang pelaksanaan tugas dan tata laksana pemerintah dalam misinya sebagai pengemban amanat menuju masyarakat demokratis, adil, makmur dan sejahtera. Sedangkan dalam konteks mikro, e-government adalah pelayanan publik yang dilaksanakan oleh semua instansi pemerintah yang terkoordinasi atau dengan lainnya secara optimal dengan menggunakan teknologi telematika. e-government diartikan sebagai rujukan yang ditujukan pada penggunaan teknologi informasi (TI) oleh lembaga di pemerintahan seperti Wide Area Networks, internet, dan komputer yang mempunyai kemampuan untuk berhubungan dengan orang lain, bisnis, dan lembaga pemerintahan yang lain. Teknologi ini dapat melayani berbagai macam tujuan akhir yang berbeda seperti pelayanan pemerintah terhadap masyarakat yang akan lebih baik, meningkatkan hubungan bisnis dan industri, atau menjadikan manajemen pemerintahan yang lebih efisien. Keuntungan yang dihasilkan adalah dapat mengecilkan kecurangan, meningkatkan transparansi, lebih nyaman, meningkatkan pendapatan, dan mengurangi biaya (Bank Dunia 2009). Tujuan e-government harus dilihat dalam konteks good governance, yang merupakan suatu prasyarat untuk dapat bersaing dalam pasar global. Birokrasi pemerintah harus dapat mempertanggungjawabkan kinerjanya tidak saja kepada
25 atasan langsung, tetapi juga kepada masyarakat. Adapun tujuan implementasi egovernment menurut (Depkominfo 2004) adalah sebagai berikut : •
Meningkatkan mutu layanan publik melalui pemanfaatan teknologi IT dalam proses penyelenggaraan pemerintahan.
•
Terbentuknya kepemerintahan yang bersih, transparan, dan mampu menjawab tuntutan perubahan secara efektif.
•
Perbaikan organisasi, sistem manajemen, dan proses kerja kepemerintahan. Sasaran pembangunan yang ingin dicapai oleh pemerintah dalam
implementasi e-government (Depkominfo 2004) adalah : •
Pembentukan jaringan informasi dan transaksi pelayanan publik yang berkualitas dan terjangkau.
•
Pembentukan hubungan interaktif dengan dunia usaha untuk meningkatkan dan memperkuat kemampuan perekonomian menghadapi perubahan dan persaingan perdagangan internasional.
•
Pembentukan mekanisme komunikasi antar lembaga pemerintah serta penyediaan
fasilitas
bagi
partisipasi
masyarakat
dalam
proses
kepemerintahan. •
Pembentukan sistem manajemen dan proses kerja yang transparan dan efisien serta memperlancar transaksi dan layanan antar lembaga pemerintah. Meskipun tidak berorientasi laba, lembaga-lembaga pemerintahan perlu
terus meningkatkan layanannya kepada masyarakat sebagai konsumennya. Dengan berkembangnya teknologi informasi dan telekomunikasi, lembagalembaga pemerintahan dapat menerapkan e-government untuk meningkatkan efisiensi dan efektivitas operasionalnya serta untuk meningkatkan pelayanan kepada masyarakat (Hendriana 2004). Konsep pengembangan e-government mempunyai fokus terhadap tiga hal yaitu pemerintah ke masyarakat (G2C), pemerintah ke bisnis (G2B), dan pemerintah ke pemerintah (G2G), selain internal lembaga pemerintahan itu sendiri seperti pemerintah ke pegawai (G2E) (Bank Dunia 2009). 2.7 Internetworking Internetworking merupakan suatu abstraksi yang kuat dalam pembahasan kompleksitas
dari
teknologi
komunikasi
yang
beragam
dengan
cara
26 menyembunyikan detail setiap perangkat keras jaringan dan menyediakan suatu lingkungan komunikasi tingkat tinggi (Wiryana 2009). Tujuan utama dari internetworking adalah interoperabilitas yang maksimun, yaitu memaksimalkan kemampuan program pada sistem komputer yang berbeda dan sistem jaringan yang berbeda untuk berkomunikasi secara handal dan efisien. Ini akan menunjang ketersediaaan informasi pada sistem komputer dan jaringan yang beragam, baik perangkat lunak, perangkat keras maupun model data dari informasi tersebut. Pada era teknologi saat ini informasi yang cepat dan mudah didapat sangat diperlukan sekali. Penggunaan Internet juga didukung oleh saluran komunikasi yang sudah memadai dimana hampir setiap rumah mempunyai saluran komunikasi telepon sampai dengan perusahaan yang sudah menggunakan saluran komunikasi yang khusus. Hal lain yang timbul di Indonesia saat ini adalah mulai banyaknya Internet Services Provider (penyedia layanan Internet) yang menyediakan fasilitas Internet kepada para pelanggannya. 2.8 Implementasi Metode Prototipe Pengembangan sistem informasi dapat dilakukan dengan pendekatan prototipe. Prototipe merupakan pembuatan model sistem informasi yang pengembangannya dilakukan dengan cepat (Marimin et al. 2006). Prototipe memberikan ide bagi pembuat maupun pemakai potensial tentang cara sistem akan berfungsi dalam bentuk lengkapnya (McLeod & Schell 2007). Model ini dimulai dengan pengumpulan kebutuhan dan perbaikan, desain cepat, pembentukan prototipe, evaluasi pelanggan terhadap prototipe, perbaikan prototipe dan produk akhir. Pengembang dan pengguna bertemu dan mendefinisikan obyek keseluruhan dari software, mengidentifikasi segala kebutuhan yang diketahui, dan area garis besar yang merupakan keharusan dan kemudian dilakukan perancangan lagi secara cepat. Perancangan cepat ini akan membuat suatu prototipe yang selanjutnya dievaluasi oleh pengguna dan digunakan untuk kebutuhan pengembangan software. Pada pendekatan ini terjadi iterasi yaitu pada saat prototipe di kerjakan untuk memenuhi kebutuhan pengguna, dan pada saat yang sama pengembang melakukan pemahaman terhadap apa yang harus dilakukan sehingga prototipe akan lebih baik (Suyanto 2005).
27 McLeod dan Schell (2007) mengemukakan bahwa pengembangan prototipe terdiri dari 2 jenis. Prototipe jenis I atau yang disebut sebagai prototipe evolutionary yang akan menjadi suatu sistem operasional. Prototipe jenis II (requirement prototype) merupakan suatu model yang berfungsi sebagai cetak biru bagi sistem operasional, dimana pada langkah pertama sampai dengan ketiga sama seperti untuk prototipe jenis I. Tahapan yang terdapat pada prototipe jenis I dapat dilihat pada Gambar 5. Adapun langkah-langkahnya adalah sebagai berikut: 1.
Mengidentifikasikan kebutuhan pemakai. Pada tahap ini analis sistem mewawancarai pemakai untuk mendapatkan gagasan dari apa yang diinginkan pemakai terhadap sistem.
2.
Mengembangkan prototipe. Analis sistem dapat bekerja sama dengan spesialis informasi lain, menggunakan satu atau lebih peralatan prototyping untuk mengembangkan sebuah prototipe.
3.
Menentukan apakah prototipe dapat diterima. Analis mendidik pemakai dalam penggunaan prototipe dan memberikan kesempatan kepada pemakai untuk membiasakan diri dengan sistem. Pemakai memberikan masukan bagi analis apakah prototipe memuaskan atau tidak. Jika ya, langkah berikutnya akan diambil dan jika tidak, prototipe direvisi dengan mengulangi langkah 1 sampai 3 dengan pengertian yang lebih baik mengenai kebutuhan pemakai.
4.
Menggunakan prototipe. Prototipe yang akan menjadi sistem operasional. Penggunaan prototipe dalam pengembangan sistem informasi mempunyai
beberapa keuntungan, diantaranya : •
Menghasilkan syarat yang lebih baik dari produksi yang dihasilkan.
•
Pengguna dapat mempertimbangkan sedikit perubahan selama masih dalam bentuk prototipe.
•
Memberikan hasil yang lebih akurat dari pada perkiraan sebelumnya, karena fungsi yang diinginkan dan kerumitannya sudah diketahui dengan baik.
28
1.
Mengidentifikasi kebutuhan pemakai
2.
Mengembangkan prototipe
3.
Prototipe dapat diterima?
Tidak
Ya 4.
Gunakan Prototipe
Gambar 5 Pengembangan prototipe jenis I (McLeod & Schell 2007). Reaksi awal dari pengguna, diawali dengan menampilkan sebuah prototipe sistem informasi, kemudian melihat reaksi dari pengguna saat bekerja dengan prototipe apakah fitur-fitur sistem pada prototipe tersebut sudah sesuai dengan kebutuhannya. Reaksi tersebut dikumpulkan dalam lembar observasi, wawancara dan kuesioner. Pengembangan prototipe jenis II dapat dilihat pada Gambar 6. Tiga langkah pertama sama seperti untuk prototipe jenis I. langkah-langkah selanjutnya adalah sebagai berikut : 4.
Mengkodekan sistem operasional. Programer menggunakan prototipe sebagai dasar untuk pengkodean (coding) sistem operasional.
5.
Menguji sistem operasional. Programer menguji sistem.
6.
Menentukan jika sistem operasional dapat diterima. Pengguna memberikan masukan pada analis apakah sistem dapat diterima. Jika ya, langkah 7 dilakukan dan jika tidak, langkah 4 dan 5 diulangi.
7.
Menggunakan sistem operasional.
Pendekatan ini diikuti jika prototipe tersebut hanya dimaksudkan untuk memiliki penampilan seperti sistem operasional dan tidak dimaksudkan untuk memuat semua elemen penting.
29
4.
Mengkodekan sistem operasional
5.
Menguji sistem operasional
6.
Sistem dapat diterima?
Tidak
Ya 7.
Menggunakan sistem operasional
Gambar 6 Pengembangan prototipe jenis II (McLeod & Schell 2007). 2.9 Alat Pemodelan Proses Bisnis Proses merupakan sekumpulan aktivitas yang memanfaatkan masukan untuk diberi nilai tambah sehingga dapat menghasilkan keluaran yang diinginkan. Sedangkan bisnis merupakan upaya untuk menghasilkan nilai tertentu dalam memenuhi kebutuhan. Dari pengertian tersebut proses bisnis merupakan aktivitas yang merespon kejadian pada organisasi (business event) dan pekerjaan yang dilakukan oleh suatu sistem untuk mentransformasi sebuah input menjadi output yang sesuai dengan keinginan pengguna (Wijaya et al. 2009). Pada pembuatan model proses bisnis, terdapat beberapa alat yang umum digunakan yaitu Business Process Modelling Notation (BPMN), Integration Definition for Function Modeling (IDEF), dan Unified Modelling Language (UML). BPMN merupakan suatu alat yang digunakan untuk pemodelan proses bisnis yang dikembangkan berbasis flowchart sehingga mudah dipahami (Wijaya et al. 2009). IDEF merupakan sebuah standar yang dibangun berdasarkan Structured Analysis and Design Technique (SADT) dan kemudian diadopsi sebagai Federal Information Processing Standard (FIPS) (Syaiful & Permadi 2005). Sedangkan UML adalah suatu ‘bahasa’ yang menjadi standar dalam industri untuk visualisasi, merancang dan mendokumentasikan sistem perangkat lunak (Dharwiyanti & Wahono 2003).
30 2.9.1 Business Process Modeling Notation (BPMN) Business Process Modeling Notation (BPMN) yaitu suatu metodologi baru yang dikembangkan oleh Business Process Modeling Initiative sebagai suatu standard baru pada pemodelan proses bisnis. BPMN juga sebagai alat desain pada sistem yang kompleks berbasis pesan (message-based). Tujuan utama dari BPMN adalah menyediakan notasi yang mudah digunakan dan bisa dimengerti oleh semua orang yang terlibat dalam bisnis, yang meliputi bisnis analis yang memodelkan proses bisnis, pengembang teknik yang membangun sistem yang melaksanakan bisnis, dan berbagai tingkatan manajemen yang harus dapat membaca dan memahami proses diagram dengan cepat sehingga dapat membantu dalam pengambilan keputusan (Rosmala & Falahah 2007). Notasi BPMN yang baru juga dirancang untuk sifat sistem berbasis layanan web. BPMN dapat memodelkan pesan kompleks yang dilewatkan diantara pelaku bisnis atau bagian dari pelaku bisnis, kejadian yang menyebabkan pesan dilewatkan, dan aturan bisnis yang membatasi kejadian tersebut. BPMN memungkinkan proses bisnis dipetakan ke bahasa eksekusi bisnis berbasis XML seperti Business Process Execution Language for Web Service (BPEL4WS) dan Business Process Modeling Language (BPML). Informasi pada bahasa eksekusi bisnis ini dapat divisualisasikan dengan notasi umum. Contoh penerapan notasi BPMN pada sistem berbasis layanan web adalah seperti pada Gambar 7.
Contact Seller
Bidder
Item of Interest Found
No Bid
No Read Item Description
Review Seller’s Credentials
Smart Sell
Contact Seller For Further Information
Deal with Seller? Yes
Buy Item Now
Message Flow
Read Sellers Feedback
Verify Bidder Credentials Pools
Item Sold Subject to Payment Close Auction
Sequence Flow End of Auction
Gambar 7 Diagram proses bisnis BPMN (Owen & Jog Raj 2003).
31
Salah satu kelebihan diagram BPMN adalah kemampuan memodelkan aliran pesan. Diagram bisnis proses tradisional mampu memodelkan aliran proses secara sekuensial, dari kejadian awal sampai hasil akhir. Dalam lingkungan ecommerce, tentunya, orang mengirim pesan kepada yang lain sebagai bagian dari aliran proses. Pesan ini menuntun pada penggambaran dan pemahaman proses business to business dan business to customer (Rosmala & Falahah 2007). 2.9.2 IDEF Model IDEF dibuat berdasarkan pada analisis struktur dan teknik perencanaan SADT yang telah disempurnakan oleh Integrated Computer Aided Manufacturing (ICAM) tahun 1993. IDEF digunakan untuk mengembangkan representasi grafis terstruktur dari sebuah sistem atau perusahaan (Syaiful & Permadi 2005). Model IDEF digambarkan dengan persegi panjang dan empat jenis arah panah di sekitar persegi panjang. Persegi panjang merupakan fungsi atau kegiatan yang dijelaskan dalam ungkapan verbal. Anak panah yang masuk dari sebelah kiri mewakili input, dari kiri ke kanan menggambarkan output, dari atas ke bawah menunjukan pengawasan (control), dan anak panah bawah adalah mekanisme (Mechanism) yang mengimplimentasikan suatu dukungan terhadap aktivitas (Jeong et al. 2009). IDEF tersusun dari sebuah building blocks, yang terdiri dari 2 macam, yaitu aktifitas dan ICOM. Aktivitas adalah komponen suatu sistem yang menjalankan atau melakukan suatu tindakan. Sedangkan ICOM yaitu komponen suatu sistem yang digunakan oleh suatu aktivitas. ICOM terdiri dari : 1.
Input yaitu sesuatu yang ditransformasikan oleh suatu aktivitas.
2.
Control yaitu sesuatu yang menentukan bagaimana suatu aktivitas terjadi tetapi tidak ditransformasikan.
3.
Output yaitu sesuatu yang dihasilkan oleh aktivitas.
4.
Mechanism yaitu antara lain orang, fasilitas, dan mesin yang menjalankan aktivitas (Syaiful & Permadi 2005). Elemen dari IDEF yaitu suatu persegi panjang (untuk aktifitas kotak
syntax) dan arah anak panah yang didefinisikan. Elemen tersebut digunakan untuk
32 membuat gambar dan gambar tersebut disusun untuk pembentukan model IDEF. Elemen-elemen tersebut dapat dilihat pada Gambar 8.
Control (noun)
Input (noun)
Function (Phrase starting with Verb)
Output (noun)
Mechanism (noun)
Gambar 8 Notasi pada model IDEF (Jeong, et al. 2009). Dalam model IDEF ada tiga elemen utama yaitu konsep, bahasa, dan pragmatik. Konsep dasar terdiri dari tujuh langkah yang harus diikuti yaitu (1) harus secara tepat menggambarkan kawasan masalah, yaitu suatu model grafik dari sistem harus dikembangkan sehingga elemen-elemen sistem tersebut serta interaksi-interaksinya dapat didefenisikan, didokumentasikan, dibahas, dan dianalisis secara efektif; (2) model harus memiliki suatu struktur atas bawah, modular dan hirarki. Model harus menggambarkan atas bawah sistem melalui pendefinisian elemen-elemen sistem modular yang berintegrasi untuk membentuk suatu hirarki; (3) model harus memisahkan fungsi dari rancangan sistem. Fungsi dasar dapat diubah dan rencana baru dapat dibuat untuk keperluan fungsi yang baru tersebut; (4) model harus mencerminkan objek atau tindakan-tindakan dan kasus yang terjadi, yaitu kaedah pemodelan harus mampu menggambarkan seluruh bentuk proses dan kasus-kasus yang terjadi; (5) bentuk model harus grafik. Bentuk model harus tercatat dalam grafik bukan matematik ataupun teks yang dapat berkomunikasi secara ringkas dan tepat yang mencerminkan fungsifungsi nyata serta proses; (6) model harus produk bagi kelompok kerja yang disiplin dan terkoordinasi serta sesuai untuk membangunkan sebuah model dan untuk mendapatkan persetujuan bersama; (7) model harus menampilkan seluruh informasi dalam teks (Rita et al. 2010).
33 Bahasa ditulis dalam bentuk simbol dan kotak, serta panah grafik dalam bentuk skema yang terstruktur guna menghasilkan model IDEF. Bahasa digunakan untuk menuangkan maksud para penganalisa, pembaca, dan pekerja. Pragmatik IDEF menyiapkan cadangan bagi pengguna IDEF. Dalam banyak hal, pragmatik begitu dekat dengan konsep dan bahasa dimana hal tersebut tidak dapat dipisahkan, sehingga dengan pragmatik pengguna dapat menggunakan model IDEF. 2.9.3 Unified Modeling Language (UML) Unified Modeling Language (UML) adalah alat bantu (tool) untuk pemodelan sistem, “UML adalah bahasa yang dapat digunakan untuk spesifikasi, visualisasi, dan dokumentasi sistem object-oriented software pada fase pengembangan. UML merupakan unifikasi dari metode Booch, Object Modelling Technique (OMT), dan notasi objectory, serta ide-ide terbaik metodologi lainnya seperti terlihat pada Gambar 9. Dengan menyatukan notasi metode-metode objek oriented tersebut, UML merupakan standar dasar dalam bidang analisis dan desain berorientasi-objek. (Nurokhim & Rohmah 2002). Rumbaugh Jacobson Booch Meyer Pre-and Postconditions
Odell Classification
UML
Shlaer-Mellor Object life cycles
Gamma et al. Frameworks, patterns, notes Embly Singleton classes
Harel State charts
Wirfs-Brock Responsibilities Fusion Operation descriptions, message numbering
Gambar 9 Unifikasi berbagai metode pengembangan objek ke dalam UML (Quatrani 1999). Menurut Dharwiyanti dan Wahono (2003) konsep dasar dari UML adalah mendefinisikan beberapa diagram. Diagram tersebut antara lain use case diagram,
34 class diagram, statechart diagram, acvtivity diagram, sequence diagram, collaboration diagram, component diagram, dan deployment diagram. Use case diagram, yaitu menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Suatu use case merepresentasikan sebuah interaksi antara aktor dengan sistem. Use case merupakan sebuah pekerjaan tertentu, diantaranya adalah login ke sistem, dan membuat sebuah daftar belanja. Seorang/sebuah aktor adalah sebuah entitas manusia atau mesin yang berinteraksi dengan sistem untuk melakukan pekerjaan-pekerjaan tertentu. Use case diagram dapat membantu untuk menyusun kebutuhan (requirement) sebuah sistem, mengkomunikasikan rancangan dengan klien, dan merancang test case untuk semua feature yang ada pada sistem. Class diagram, yaitu suatu diagram yang menggambarkan struktur dan deskripsi class, package dan objek beserta hubungan satu dan yang lainnya seperti containment, pewarisan, asosiasi, dan lain-lain. Class mempunyai tiga area pokok yaitu nama class, atribut, dan metoda. Atribut dan metoda dapat memiliki salah satu sifat berikut : -
Private, tidak dapat dipanggil dari luar class yang bersangkutan.
-
Protected, hanya dapat dipanggil oleh class yang bersangkutan dan anakanak yang mewarisinya.
-
Public, dapat dipanggil oleh siapa saja. Statechart diagram, menggambarkan transisi dan perubahan keadaan (dari
satu state ke state yang lain) suatu objek pada sistem sebagai akibat dari stimuli yang diterima. Pada umumnya statechart diagram menggambarkan class tertentu (satu class dapat memiliki lebih dari satu statechart diagram). Activity diagram, menggambarkan berbagai alir aktivitas dalam sistem yang sedang dirancang, bagaimana masing-masing alir berawal, decision yang mungkin terjadi, dan bagaimana aktivitas berakhir. Activity diagram juga dapat menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi. Activity diagram merupakan state diagram khusus, di mana sebagian besar state adalah action dan sebagian besar transisi di-trigger oleh selesainya state sebelumnya (internal processing). Oleh karena itu activity diagram tidak menggambarkan perilaku internal sebuah sistem (dan interaksi antar subsistem)
35 secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur aktivitas dari level atas secara umum. Sebuah aktivitas dapat direalisasikan oleh satu use case atau lebih. Aktivitas menggambarkan proses yang berjalan, sementara use case menggambarkan bagaimana aktor menggunakan sistem untuk melakukan aktivitas. Sequence diagram, menggambarkan interaksi antar objek di dalam dan di sekitar sistem (termasuk pengguna, display, dan sebagainya) berupa message yang digambarkan terhadap waktu. Sequence diagram terdiri atas dimensi vertikal (waktu) dan dimensi horizontal (objek-objek yang terkait). Sequence diagram biasa digunakan untuk menggambarkan skenario atau rangkaian langkah-langkah yang dilakukan sebagai respons dari sebuah event untuk menghasilkan output tertentu. Diawali dari apa yang menjadi trigger aktivitas tersebut, proses dan perubahan apa saja yang terjadi secara internal dan output apa yang dihasilkan. Masing-masing objek, termasuk aktor, memiliki lifeline vertikal. Message digambarkan sebagai garis berpanah dari satu objek ke objek lainnya. Pada fase desain berikutnya, message akan dipetakan menjadi operasi/metoda dari class. Activation bar menunjukkan lamanya eksekusi sebuah proses, biasanya diawali dengan diterimanya sebuah message. Collaboration diagram, merupakan salah satu cara untuk menggambarkan skenario dari sistem yang akan dirancang. Diagram ini juga menggambarkan interaksi antar objek seperti sequence diagram, tetapi lebih menekankan pada peran masing-masing objek dan bukan pada waktu penyampaian message. Setiap message memiliki sequence number. Messages dari level yang sama memiliki prefiks yang sama. Component diagram, menggambarkan struktur dan hubungan antar komponen piranti lunak, termasuk ketergantungan (dependency) di antaranya. Komponen piranti lunak adalah modul berisi code, baik berisi source code maupun binary code, baik library maupun executable, baik yang muncul pada compile time, link time, maupun run time. Umumnya komponen terbentuk dari beberapa class dan/atau package, tapi dapat juga dari komponen-komponen yang lebih kecil. Komponen dapat juga berupa interface, yaitu kumpulan layanan yang disediakan sebuah komponen untuk komponen lain.
36 Deployment diagram, menggambarkan detail bagaimana komponen didistribusikan dalam infrastruktur sistem (di mana komponen akan terletak pada mesin, server atau piranti keras apa). Kemudian menunjukkan bagaimana kemampuan jaringan pada lokasi tersebut, spesifikasi server, dan hal-hal lain yang bersifat fisikal. Sebuah node adalah server, workstation, atau piranti keras lain yang digunakan untuk mendistribusikan komponen dalam lingkungan sebenarnya. Hubungan antar node (misalnya TCP/IP) dan requirement dapat juga didefinisikan dalam diagram ini. 2.10 Pengukuran Hasil Framework merupakan sebuah bagian penting dalam pendesainan EA, oleh sebab itu diperlukan suatu kriteria untuk pengukuran framework tersebut. Demikian juga dalam mendesain suatu sistem harus memiliki rancangan sistem yang teruji. Menurut Setiawan (2009a) kriteria yang seharusnya dimiliki oleh suatu framework adalah sebagai berikut: a.
Reasoned.
Merupakan framework yang masuk akal yang dapat memungkinkan pembuatan arsitektur yang bersifat deterministik ketika terjadi perubahan batasan dalam mendesain suatu sistem. Framework juga harus tetap menjaga integritasnya walalupun menghadapi perubahan bisnis dan teknologi serta demand yang tak terduga. b.
Cohesive.
Framework yang kohesif memiliki sekumpulan perilaku yang akan seimbang dalam cara pandang dan cakupannya. c.
Adaptable.
Framework haruslah bisa beradaptasi terhadap perubahan yang mungkin sangat sering terjadi dalam organisasi. d.
Vendor-independent.
Framework haruslah tidak tergantung pada vendor tertentu untuk benar-benar memaksimalkan manfaat bagi organisasi. e.
Technology-independent.
Framework tidak harus tergantung pada suatu teknologi tertentu, namun harus dapat disesuaikan dengan perkembangan teknologi.
37 f.
Domain-neutral.
Adalah atribut penting bagi framework agar memiliki peranan dalam pemeliharaan tujuan organisasi. Framework harus mudah dimengerti oleh semua user agar tujuan organisasi dapat tercapai dan terpelihara. g.
Scalable.
Framework haruslah beroperasi secara efektif pada level departemen, unit bisnis, pemerintahan dan level korporat tanpa kehilangan fokus dan kemampuan untuk dapat diaplikasikan.
