BAB II TINJAUAN PUSTAKA Pada bab ini akan dijelaskan mengenai konsep dan landasan teori sebagai kerangka berpikir yang dapat digunakan untuk menyelesaikan masalah dalam penelitian ini. 2.1
Tinjauan Umum Instansi Badan Pengkajian dan Penerapan Teknologi (BPPT) secara resmi dibentuk
sebagai lembaga pemerintah non departemen yang bertanggung jawab kepada Presiden. Proses pembentukan BPPT bermula dari gagasan mantan Presiden Soeharto kepada Prof. Dr. Ing. B. J. Habibie pada tanggal 28 Januari 1974. Jabatan Kepala BPPT selama 25 tahun selalu dirangkap oleh Menteri Negara Riset dan Teknologi. Tepat pada bulan April 2006 secara resmi organisasi BPPT terpisah dengan organisasi Kementrian Riset dan Teknologi dengan diterbitkannya Keppres Nomor 42 tahun 2006 tentang pengangkatan Kepala BPPT (Badan Pengkajian dan Penerapan Teknologi [BPPT], 2015). 2.1.1
Pusat Audit Teknologi (PAT) Pada struktur organisasi BPPT, Kedeputian Pengkajian Kebijakan
Teknologi membawahi Pusat Pengkajian Kebijakan Inovasi Teknologi, Pusat Pengkajian Kebijakan Difusi Teknologi, Pusat Pengkajian Kebijakan Peningkatan Daya Saing, Pusat Audit Teknologi dan Balai Inkubator Teknologi (Badan Pengkajian dan Penerapan Teknologi [BPPT], 2015) PAT diberi wewenang oleh pemerintah dalam melaksanakan kegiatan audit teknologi baik pada sektor pemerintah maupun swasta. Direktur PAT periode saat ini dijabat oleh Dr. Ir. Arwanto, M.Si. Audit teknologi yang dilakukan oleh PAT dilaksanakan terhadap industri guna mengetahui posisi daya saing perusahaan serta mengurangi potensi dampak negatif akibat penerapan teknologi (Pusat Audit Teknologi [PAT], 2011). PAT menaungi sejumlah 35 auditor aktif yang memiliki dominasi kompetensi dalam bidang audit industri dan audit sistem informasi (A. Pamungkas,
II-1
komunikasi personal, November 23, 2015). Selama periode tahun 2011 hingga 2013, sebanyak 23 objek audit telah dilaksanakan oleh auditor teknologi di PAT BPPT (Badan Pengkajian dan Penerapan Teknologi [BPPT], 2013). 2.2
Audit Teknologi Menurut PAT (2011), audit teknologi merupakan evaluasi secara sistematis
dan objektif terhadap suatu aset teknologi demi mencapai tujuan audit teknologi yakni memberikan nilai tambah dan meningkatkan kinerja pihak yang diaudit. Audit teknologi sangat penting dibutuhkan sebagai suatu bentuk kegiatan dalam usaha perbaikan yang berkelanjutan bagi suatu perusahaan maupun organisasi (Badan Pengkajian dan Penerapan Teknologi [BPPT], 2012). 2.3
Sistem Nasional Audit Teknologi Berdasarkan Keputusan Presiden No 103 Pasal 60 Tentang Kedudukan,
Fungsi, Kewenangan, Susunan Organisasi dan Tata Kerja Lembaga Pemerintah Non Departemen, BPPT memiliki hak penuh atas pelaksanaan audit teknologi secara nasional karena didalam peraturan perundangan lain tidak ditemukan instansi selain BPPT yang diberi kewenangan dalam pelaksanaan audit teknologi (BPPT, 2012). Sehingga dapat disimpulkan bahwa pelaksanaan audit teknologi di Indonesia saat ini secara menyeluruh dilaksanakan oleh BPPT. BPPT memiliki keterbatasan dalam jumlah sumber daya manusia auditor teknologi. Hingga saat ini terdapat 35 auditor teknologi yang dinaungi oleh PAT BPPT, sehingga pelaksanaan audit teknologi dapat diberikan kepada instansi lain yag berkompeten. Pihak yang mendapat pendelegasian pelaksanaan audit teknologi diwajibkan memiliki kualifikasi serta menggunakan pedoman pelaksanaan audit teknologi yang ditetapkan BPPT. Sehingga hasil audit teknologi dapat dipertanggung-jawabkan baik dari segi substansi maupun keabsahannya. Karena begitu penting konsep tatanan jaringan sarana dan kegiatan terkait audit teknologi secara nasional, BPPT mengeluarkan hasil kajian berupa Sistem Nasional Audit Teknologi (SNAT) dalam bentuk naskah akademis. SNAT merupakan tatanan jaringan yang mengatur kegiatan terkait audit teknologi secara nasional. SNAT mengakomodir pengaturan audit teknologi mencakup skema kelembagaan,
II-2
aktivitas standarisasi kompetensi auditor teknologi dan mekanisme sertifikasi auditor teknologi secara nasional (BPPT, 2012). 2.3.1
Peta Kelembagaan SNAT Menurut BPPT (2012), sistem kelembagaan pada audit teknologi adalah
salah satu aspek penting dalam mendukung berjalannya SNAT. Sistem kelembagaan tersebut mencakup jaringan sarana dan kelembagaan pendukung kegiatan audit teknologi. Membangun kelembagaan dalam SNAT merupakan langkah awal yang dilakukan guna mengimplementasikan pelaksanaan audit teknologi secara nasional. Membangun kelembagaan pendukung SNAT di daerah, berfungsi untuk mengakomodir permintaan pelaksanaan audit teknologi dan meningkatkan jumlah auditor teknologi di daerah. Kelembagaan yang berperan secara langsung terhadap peningkatan jumlah auditor teknologi di daerah diantaranya Lembaga Pendidikan dan Pelatihan (LPP), Tim Ujian Kompetensi (TUK) dan Dewan Sertifikasi Auditor Teknologi (DSAT). Sedangkan pihak ketiga yang diberi kewenangan dalam pelaksanaan kegiatan audit teknologi oleh BPPT adalah Lembaga Pemberi Jasa (LPJ). Sehingga proses bisnis dalam manajemen auditor teknologi dapat dipetakan dalam skema verifikasi lembaga untuk membangun jejaring kelembagaan, skema sertifikasi auditor teknologi untuk meningkatkan jumlah auditor teknologi di daerah dan skema pelaksanaan audit teknologi oleh pihak ketiga untuk mengakomodir permintaan audit teknologi di daerah (BPPT, 2012). Skema pada Gambar 2.1 dibawah ini menggambarkan hubungan kelembagaan pendukung audit teknologi.
Gambar 2.1 Skema interaksi lembaga pendukung SNAT Sumber: (BPPT, 2012)
II-3
Kepala BPPT merupakan pembina auditor teknologi di lingkungan BPPT. Sedangkan yang dimaksud Unit Pembina Teknis Audit Teknologi (UPTAT) didalam SNAT yakni PAT BPPT. Pelaksanaan UPTAT didukung dengan membangun LPP. Instansi negeri maupun swasta dapat mengajukan sebagai LPP auditor teknologi dengan persetujuan verifikasi oleh Komite Akreditasi Audit Teknologi (KAAT). Kemudian aktivitas ujian kompetensi dilaksanakan oleh Tim Ujian Kompetensi. Tim Ujian Kompetensi dibentuk dengan surat keputusan (SK) Kepala BPPT. Tim Ujian Kompetensi mempunyai tugas dalam menyusun materi ujian kompetensi auditor teknologi, memeriksa hasil ujian kompetensi auditor teknologi dan menerbitkan sertifikat kelulusan ujian kompetensi auditor teknologi sebagai persyaratan dalam kenaikan jenjang. Pelaksanaan ujian kompetensi dilakukan di TUK yang berada di daerah. Tempat kerja dengan sarana dan prasara setara dengan tempat kerja profesi dapat mengajukan lisensi kepada Lembaga Sertifikasi Profesi (LSP) untuk menjadi TUK (BPPT, 2012). Selanjutnya DSAT memiliki mewenang dalam melaksanakan sertifikasi auditor teknologi, DSAT dibentuk dengan SK Kepala BPPT. Personel yang masuk dewan ini merupakan staf senior di BPPT dengan jenjang jabatan auditor teknologi utama. Begitu juga dengan pembentukan DSAT diverifikasi oleh BPPT melalui KAAT. KAAT merupakan lembaga non struktural yang bertugas dalam menetapkan akreditasi kelembagaan dan memberikan pertimbangan saran kepada Komite Akreditasi Nasional (KAN). Sedangkan LSP (Lembaga Sertifikasi Profesi) merupakan DSAT dalam bentuk lembaga pelaksana sertifikasi. LSP mempunyai tugas dalam memeriksa persyaratan portofolio dalam kenaikan jenjang, menetapkan jenjang auditor teknologi dan menerbitkan sertifikat kelulusan jenjang auditor teknologi (BPPT, 2012). 2.3.2 Pelaksanaan Audit Teknologi dalam SNAT Pusat Audit Teknologi mendelegasikan pelaksanaan audit teknologi kepada LPJ. Kegiatan audit teknologi yang dilaksanakan tetap mengikuti tata laksana audit teknologi yang terbagi menjadi tiga tahapan diantaranya (BPPT, 2012):
II-4
1.
Tahap perencanaan (pre-audit) Merupakan tahap dimana dilakukan penyiapan rencana dan protokol
audit terkait permintaan audit teknologi oleh klien. Pada tahap perencanaan apabila terdapat permintaan audit teknologi oleh klien kepada LPJ, LPJ menunjuk seorang auditor teknologi yang memiliki jenjang auditor teknologi utama untuk membentuk tim audit teknologi. Skema organogram pembentukan tim audit teknologi dapat dilihat seperti Gambar 2.2. Tim Audit Teknologi berfungsi untuk mengaudit suatu objek audit yang telah ditetapkan oleh klien. 2.
Tahap pelaksanaan lapangan (onsite audit) Merupakan tahapan dimana tim audit mengumpulkan data sesuai
metode dan rencana yang telah disiapkan. Perubahan rencana ketika dilakukan pelaksanaan lapangan harus atas persetujuan lead auditor dalam tim tersebut. Pelaksanaan lapangan ditutup dengan pertemuan penutupan dalam rangka memaparkan hasil pengumpulan data selama pelaksanaan lapangan. Apabila terdapat kekurangan dalam penyampaian hasil yang telah disampaikan oleh auditor, pihak auditee dapat mengusulkan untuk menambah data. 3.
Tahap analisa data dan pelaporan (post audit) Merupakan tahapan dimana tim audit menganalisa data menjadi bukti
audit. Kemudian tim audit menyiapkan laporan sesuai standar pelaporan PAT BPPT. Draft laporan diperiksa oleh technical manager, selanjutnya laporan dapat diserahkan oleh LPJ kepada pihak auditee apabila telah disetujui.
II-5
Gambar 2.2 Skema organogram tim audit teknologi Sumber: (BPPT, 2012)
Tim Audit Teknologi terdiri dari posisi dengan uraian tugas dan tanggung jawab seperti berikut ini (BPPT, 2012): 1.
Dewan Audit Teknologi Dewan Audit Teknologi bertanggung jawab untuk mengesahkan hasil
audit teknologi yang bersifat wajib (audit teknologi berdasarkan permintaan pemerintah) atau menyangkut kepentingan publik. Dewan Audit Teknologi adalah Deputi Kepala Badan Pengkajian dan Penerapan Teknologi. 2.
General Manager General Manager bertanggung jawab berkoordinasi dengan klien dan
organisasi yang diaudit, bertanggung jawab secara keseluruhan atas pelaksanaan dan mengesahkan hasil audit teknologi. General Manager adalah LPJ audit teknologi. 3.
Technical Manager Technical Manager bertanggung jawab ataas pelaksanaan hasil audit
teknologi secara teknis, menentukan ruang lingkup audit dan berperan dalam membentuk Tim Audit Teknologi. Technical Manager harus mempunyai kualifikasi sertifikat auditor teknologi utama.
II-6
4.
Lead Auditor Lead Auditor bertanggung jawab menyusun rencana audit, membuat
rincian ruang lingkup audit, ikut serta melaksanakan audit lapangan dan mmebuat laporan hasil audit teknologi. Lead Auditor harus mempunyai kualifikasi sertifikat auditor teknologi madya atau utama. 5.
Auditor Auditor bertanggung jawab dalam membantu Lead Auditor ketika
melaksanakan kegiatan audit. Auditor dapat dijabat oleh auditor teknologi dengan kualifikasi jenjang sertifkat auditor teknologi pertama, muda atau madya. Namun dalam pelaksanaan audit teknologi berada dibawah bimbingan Lead Auditor. 6.
Asisten Auditor Asisten Auditor bertugas dalam membantu auditor dalam melakukan
kajian awal, mengenai objek audit dan mengumpulkan data audit. 7.
Teknisi Teknisi bertugas membantu auditor dalam mengumpulkan data
lapangan. 8.
Narasumber Narasumber berperan dalam memberikan masukan terkait isu, status
industri dan teknologi. Narasumber direkrut dari pihak luar apabila auditor teknologi tidak memiliki keilmuan dan kompetensi yang relevan dengan organisasi yang diaudit.
2.4
Sistem Sertifikasi Profesi Auditor Teknologi Sertifikasi auditor teknologi mencakup kualifikasi tertentu sehingga yang
bersangkutan dapat melaksanakan aktivitas audit teknologi. Kualifikasi auditor teknologi ditentukan oleh pendidikan akademis, pengetahuan dalam bidang audit teknologi, pengalaman dalam bidang audit teknologi, pengalaman dalam aktivitas audit teknologi sebagai asisten auditor selama periode tertentu dan mengikuti sertifikasi profesi auditor teknologi. Kualifikasi yang dimaksud, mencakup aspek pendidikan akademis, pengetahuan dalam bidang teknologi, pengalaman dalam
II-7
bidang teknologi, pengalaman dalam audit teknologi, sertifikasi profesi, pendidikan berkelanjutan dan pengembangan bidang profesi (Badan Pengkajian dan Penerapan Teknologi [BPPT], 2012). Setiap mengajukan kenaikan jenjang kualifikasi auditor teknologi, seorang pemohon harus melalui pendidikan di LPP, ujian kompetensi di TUK dan penilaian portofolio sertifikasi auditor teknologi oleh DSAT (BPPT, 2012). Skema sertifikasi kenaikan jenjang kualifikasi auditor teknologi dapat dilihat pada Gambar 2.3.
Gambar 2.3 Penjenjangan Auditor Teknologi Sumber: (BPPT, 2012)
2.5
Sistem Informasi Manajemen Definisi konsep sistem dalam sistem informasi memiliki karakteristik atau
bagian yang saling berkaitan untuk beroperasi bersama mencapai suatu tujuan. Definisi informasi adalah bagian data yang terstruktur, dapat tersimpan, dapat diproses dan disajikan pada tujuan tertentu. Sedangkan definisi sistem informasi itu sendiri merupakan sistem berbasis komputer yang dapat menyimpan data besar. Sehingga implementasi teknologi komputer tidak dapat terpisahkan dalam pengembangan sistem informasi (Milicev, 2009). Sedangkan definisi dari sistem informasi manajemen adalah sistem informasi yang memiliki hubungan ketergantungan dengan faktor manusia. Selain itu sistem informasi manajemen tidak dapat dipisahkan sebagai sistem pendukung keputusan (Koumpis, 2012).
II-8
2.6
Paradigma Pengembangan Software Paradigma pengembangan software dibagi menjadi object oriented dan
procedural atau structural. Pada paradigma object oriented, atribut dan kebiasaan dari sistem berada dalam satu objek. Sedangkan pada procedural atau structural, atribut dan kebiasaan secara normal terpisah. Sehingga dengan pemisahan antara atribut dan kebiasaan tersebut, akses terhadap data tidak terkontrol dan tidak dapat diprediksi (Weisfeld, 2009). Keunggulan object oriented dibandingkan structural yakni dengan object oriented dapat mengakomodir terkait aspek dinamis dari suatu sistem (Weisfeld, 2009). Hal ini dikarenakan pada paradigma pengembangan objek dibagi menjadi tiga model yang terdiri dari : object model, dynamic model dan functional model. Object model menawarkan data terstruktur dari sistem yang mengekspresikan dalam bentuk diagram objek. Dynamic model menawarkan bermacam bentuk kejadian yang mana setiap objek tersebut mendefinisikan transisi setiap kondisi. Functional model mendefinisikan bermacam fungsi yang membawa objek dan diekspresikan kedalam Data Flow Diagram (DFD). Meskipun paradigma pengembangan berbasiskan objek dibagi kedalam beberapa bentuk perpektif, namun mengintegrasikan antar perspektif tersebut tidak dijelaskan secara rinci (Shoval, 2007).
2.7
Metode Pengembangan Sistem Informasi Permintaan customer akan sebuah software dengan sistem yang rumit,
kualitas yang tinggi, biaya yang murah dan waktu yang pendek memberikan tekanan bagi pengembang software dalam memilih metode yang efektif dan efisien. Menurut Watkins (2009), metode pengembangan sistem informasi yang ada saat ini dapat dikategorikan kedalam metode classic dan metode agile. Metode agile berhasil menggantikan eksistensi metode classic karena lebih cepat merespon perubahan spesifikasi software selama tahap pengembangan (Koch, 2005). Berikut ini metode pengembangan software yang populer berdasarkan kategori metode classic dan metode agile (Watkins, 2009).
II-9
2.7.1 Metode Classic 1.
Waterfall Waterfall memiliki struktur yang rigid karena metode ini tidak
responsif dengan perubahan sistem yang dikembangkan. Bentuk pengujian dilakukan diakhir software yang dibangun, sehingga memiliki resiko dalam mengakomodir ekpektasi dari pengguna. 2.
Spiral Metode yang cocok digunakan dalam proyek besar, kompleks dan biaya
yang besar. Membuat perancangan secara langsung bersumber dari identifikasi kebutuhan, dimana identifikasi kebutuhan didefinisikan secara detil. Pembuatan perancangan digunakan sebagai bentuk pengujian untuk dapat melakukan tahapan berikutnya. Keunggulan metode ini yakni sistem yang dibangun dapat menyampaikan kebutuhan dari cara pandang pengguna. 3.
Iterative Metode pengembangan iterative mengubah perspektif sebuah proyek
pengembangan software menjadi lebih mudah dengan cakupan yang kecil. Metode ini memiliki keunggulan dalam mengembangkan aplikasi berorientasi objek. Metode ini menghasilkan use case dan visual modeling yang powerfull dalam mengkomunikasikan antara pengembang dan pengguna. 2.7.2
Metode Agile Development 1.
Rapid Application Development (RAD) Metode RAD memiliki tujuan pengembangan dengan sistem dengan
kualitas tinggi, pengembangan yang cepat dan biaya rendah. RAD membreakdown langkah iterasi waterfall menjadi lebih singkat. Metode RAD dibagi menjadi dua tipe pengembangan diantaranya: a.
Intensive RAD project Pengembangan ini dilakukan dengan membentuk tim yang terdiri
dari pengguna dan pengembang yang bekerja secara bersama-sama.
II-10
Sehingga proyek pengembangan software dapat dilakukan dengan waktu relatif singkat. b.
Phase RAD project Perancangan dapat dilakukan dengan menghabiskan waktu
berbulan-bulan, dimana tidak ada kewajiban untuk berkumpul antara pengguna dan pengembang. Identifikasi kebutuhan dapat dilakukan dengan workshop seperti Joint Application Design (JAD) dimana pengguna
dan
pengembang
duduk
secara
bersama
untuk
mengidentifikasi kebutuhan dan rancangan secara detil. Kunci dari RAD yakni mengembangkan prototype sebagai bentuk pengujian secara informal, dimana sistem yang diterjemahkan dari identifikasi pengguna dapat merepresentasikan implementasi fitur dan elemen fungsional. 2.
Extreme Programming Merupakan proses pengembangan software yang dibuat secara mudah
dan lebih efisien. Metode ini memberdayakan programmer dalam berkomunikasi, menyederhanakan, menerima feedback serta memberikan respon terkait pengembangan software secara langsung kepada pengguna. Adanya komunikasi dan feedback secara rutin antara pengguna dan programmer secara langsung dapat memastikan bahwa sistem yang dibangin lebih dekat dengan apa yang diinginkan oleh user. 3.
The Dynamic Systems Development Method (DSDM) DSDM merupakan metode yang secara prinsip didasarkan pada metode
RAD. Metode ini merupakan pengembangan iteratif yang sangat responsive dengan perubahan kebutuhan pengguna. Pemetaan kebutuhan pengguna pada metode ini dilakukan secara umum (high level) sehingga lebih dinamis. Metode ini memiliki beberapa tingkatan pengujian yang dilakukan secara berulang-ulang. Tim pengembang juga diberdayakan untuk mengambil keputusan.
II-11
4.
Scrum Merupakan metode dalam manajemen proyek yang mengorganisir tim
dalam komunikasi secara efektif terkait software yang akan dikembangkan. Prinsip dari scrum yakni dapat mengakomodir perubahan kebutuhan pengguna dapat berganti-ganti pemikiran terkait kebutuhan dan keinginan software yang dirancang selama proyek berlangsung. Metode ini memfokuskan tim dalam memproses secara cepat dengan memaksimalkan kemampuan tim dalam merespon kebutuhan. 5.
Rational Unified Process (RUP) Merupakan metode yang dikembangkan berdasarkan use case, RUP
mengadopsi pengembangan iteratif yang menggunakan Unified Modeling Language (UML) sebagai bahasa pemodelan. RUP memberikan petunjuk dalam pengembangan software melalui user interface dan bentuk pengujian yang sederhana. RUP memiliki kerangka business modeling, requrement, analysis and design, implementation, test, deployment, operation and support, configuration and change management, project management, environment, and infrastructure management.
2.8
Guidelines for Rapid APPLication Engineering (GRAPPLE) Menurut Schmuller (2004), GRAPPLE merupakan metode pengembangan
yang
dirancangan
berdasarkan
metode
pengembangan
lain.
GRAPPLE
menggunakan destilasi kerangka proses metodologi RUP yang memiliki petunjuk dalam menjadikan pengembangan secara cepat. Selain itu GRAPPLE tergolong kedalam metode pengembangan berorientasi objek yang diintegrasikan dengan bahasa pemodelan UML. Kerangka pengembangan didalam GRAPPLE dibagi menjadi 5 segmen dan setiap segmen terdiri dari beberapa langkah pengembangan diantaranya: 1.
Requirement Gathering Requirement Gathering merupakan tahap pengumpulan dan identifikasi
kebutuhan pengguna. Pada dasarnya identifikasi penggguna dimaksudkan untuk menjadikan dasar dalam membangun sistem yang tepat.
II-12
a.
Discover Business Processes Langkah awal dimulai dengan mengetahui proses bisnis klien,
proses bisnis dipetakan melalui activity diagram langkah demi langkah. Output dari langkah ini adalah activity diagram yang memetakan setiap langkah dari proses bisnis. b.
Perform Domain Analysis Selanjutnya dengan wawancara lebih lanjut, analyst mendapatkan
pemahaman terkait pemetaan konsep bukan pada sistem yang akan dibangun. Pada langkah ini analyst merancang object modeler dimana kata benda dijadikan class, beberapa kata benda dijadikan atribut dan kata kerja dijadikan operasi dari class. c.
Identity Cooperating System Setiap sistem memiliki integrasi dengan sistem lain, untuk
mengetahui terkait pemetaan tersebut, pada tahap ini dilakukan pembuatan deployment diagram. d.
Discover System Requirement Object modeler telah didapat sebelumnya digunakan sebagai dasar
dalam merancang class diagram. Output dari langkah ini adalah package
diagram
yang
merepresentasikan
high
level
area
fungsionalitas sistem. Setiap package diagram memiliki beberapa set use case. e.
Present Result to Client Ketika telah selesai dilakukan identifikasi kebutuhan, project
manager menyajikan hasil serta mengestimasi biaya yang dibutuhkan. 2.
Analysis Analysis merupakan tahapan yang dapat dilakukan sejalan dengan
identifikasi kebutuhan pengguna. Pada tahap analysis, seorang analyst sistem diminta untuk mengurai dan menganalisis permasalahan pengguna melalui informasi yang didapatkan selama identifikasi kebutuhan sistem.
II-13
a.
Understand System Usage Langkah awal yang dilakukan yakni dengan mengetahui cara kerja
sistem yang akan dirancang, analyst memetakan setiap pihak eksternal actor yang terlibat dalam sistem pada use case analysis secara umum. b.
Flesh Out Use Case Selanjutnya memetakan langkah secara sequential dengan
penjabaran use case analysis secara umum. c.
Refine Class Diagram Kemudian menggambarkan dalam bentuk class diagram untuk
mengetahui berbagai hubungan class baik pada association, abstract classes, multiplicities, generalization maupun aggregation. Output dari langkah ini adalah class diagram. d.
Analyze Changes of State in Object Memetakan perubahan state (kondisi) dalam pengembangan sistem
beserta interaksi antar objek yang terjadi. Output dari langkah ini adalah state diagram. e.
Define Interaction Among Object Dengan melihat set use case dan class diagram, saatnya
memetakan object diagram dan relasinya. Sequential diagram dan collaboration diagram dapat dipetakan interaksi yang terjadi. f.
Analyze Integration with Cooperating System Kemudian yang terakhir menganalisis integrasi yang dilakukan
dengan sistem terkait seperti arsitektur dan database. Output dari tahap ini adalah deployment diagram. 3.
Design Design merupakan hasil dari analisis yang diungkapkan dalam bentuk
solusi rancangan. Pada segmen ini perancangan dan analisis tetap dapat dilakukan kembali sampai rancangan selesai.
II-14
a.
Develop and Refine Object Diagram Tahap awal segmen design, programmer memiliki peran utama
dalam membawa class diagram untuk memunculkan object diagram. Melakukan flesh out object diagram memiliki tujuan untuk mengetahui setiap operasi dan melakukan pengembangan terkait activity diagram. Activity diagram menyajikan basis dalam segmen pengembangan. Output dari tahap ini adalah object diagram dan activity diagram. b.
Develop Component Diagram Programmer memiliki peran utama pada tahap ini dimana dengan
melakukan
visualisasi
terhadap
komponen
akan
menyajikan
ketergantungan antar komponen. Output dari tahap ini adalah component diagram. c.
Plan for Deployment Ketika component diagram selesai, system engineer mencoba
untuk merencanakan deployment diagram dan integrasi terkait sistem terkait. Produknya adalah diagram dari deployment diagram yang telah dibangun. d.
Design and Prototype User Interface Perancangan prototype user interface berdasarkan use case yang
telah dibangun sebelumnya. Perancangan user interface didasarkan pada persetujuan user, output dari tahap ini adalah screenshot prototype user interface. e.
Design Test Selanjutnya untuk menilai apakah pengembangan sistem sesuai
dengan tujuan spesifikasi use case, pengembang merancangan pengujian komparasi berdasarkan use case diagram. Output dari tahap ini adalah skrip pengujian komparasi. f.
Begin Documentation User dan sistem adminitrator mengembangkan dokumen yang
dibangun secara umum. Output dari tahap ini adalah dokumen yang terstruktur.
II-15
4.
Development Pada segmen development, programmer mengambil alih kendali
pengembangan sistem melalui pengkodean berdasarkan diagram yang dirancang pada segmen design. a.
Construct Code Berdasarkan class diagram, object diagram, activity diagram dan
componen
diagram,
programmer
membangun
sistem
melalui
pengkodean. b.
Test Code Selanjutnya dilakukan pengetesan terhadap script yang dibangun
apakah sesuai dengan fungsionalitas rancangan. c.
Construct User Interface, connect to code and test Hasil pengkodean sistem diintegrasikan dengan prototype user
interface yang telah dibangun, output dari tahap ini yakni fungsionalitas sistem yang lengkap dengan user interface. d.
Complete Documentation Kemudian
yang
terakhir
melakukan
dokumentasi
terkait
pengembangan sistem dalam bentuk dokumen. 5.
Deployment. Pada segmen deployment dilakukan ketika pengembangan telah selesai
dilakukan dan siap untuk implementasi dengan sistem terkait. a.
Plan for Backup and Recovery Pada segmen ini system engineer mengambil alih kendali dalam
deployment sistem. Pada tahap ini dilakukan perancangan backup dan recovery sistem, output rancangan berupa langkah antisipasi apabila terjadi kerusakan terhadap sistem. b.
Install Finished System on Appropriate Hardware Selanjutnya instalasi sistem pada perangkat yang sesuai, system
engineer
melakukan
deploy terhadap sistem
yang
hendak
diimplementasikan. Output dari tahap ini adalah deployment system secara rinci.
II-16
c.
Test Installed System Kemudian yang terakhir dilakukan pengujian terhadap instalasi
sistem yang dibangun, dalam pengujian ini yang diujikan yakni apakah sistem berjalan sesuai dengan fungsinya. Output pada tahap ini merupakan hasil dari pengujian yang dilakukan.
2.9
Teknik Identifikasi Kebutuhan Menurut Milicev (2009), mengidentifikasi kebutuhan merupakan aktivitas
yang menantang karena mengubah hal yang tidak formal, tidak terstruktur, tidak jelas, ambigu dan tidak lengkap menjadi sebuah spesifikasi dan model analisis yang terstruktur, jelas, tidak ambigu dan lengkap. Dibutuhkan kemampuan, pengetahuan dan talenta seorang analis untuk menyelesaikan tantangan tersebut. Dalam rangka mengatasi ketergantungan pada talenta manusia untuk mengidentifikasi kebutuhan sistem, dibutuhkan metode teknik identifikasi kebutuhan untuk membantu dalam aktivitas tersebut. Adapun teknik identifikasi kebutuhan terdiri dari beberapa aktivitas seperti berikut : 1.
Requirement Capturing Mengumpulkan identifikasi kebutuhan melalui dokumen tertulis
maupun wawancara 2.
Requirement Analysis Fokus pada mengkonsepkan, menstrukturkan dan memformalkan
identifikasi kebutuhan yang telah dikumpulkan 3.
Requirement Specification Membangun artifak yang terstruktur kedalam analisis model UML.
2.10
Unified Modelling Language Bahasa pemodelan digunakan dalam merepresentasikan sistem informasi
untuk membuat keputusan tentang rancangan dan berkomunikasi kepada pihak terait tentang cara kerja sistem tersebut (Hungerford & Eierman, 2005). UML merupakan bahasa pemodelan yang memungkinkan pengembang sistem untuk menuliskan pandangan terkait cara kerja sistem pada standar yang mudah dipahami
II-17
serta mempermudah perancang dalam mengkomunikasikan pandangan terkait sistem dengan pemangku kepentingan (Schmuller, 2004). Sebagai bahasa pemodelan, UML dapat digunakan secara luas dalam pengembangan software (Quan et al., 2015). Selain itu UML tidak hanya digunakan untuk mendefinisikan cara kerja suatu sistem berbasis software tetapi juga dapat digunakan untuk menggambarkan suatu proses bisnis (Gelbard, 2009). Karakteristik dari UML diantaranya dapat dijadikan sebagai fungsi kontrol dalam memisahkan kebutuhan inti sistem, aktivitas dalam memvalidasi sistem serta memisahkan antara elemen yang perlu diimplementasikan dalam merancang sistem (Murray and Clark, 2015). Salah satu keunggulan dari UML adalah dapat dengan mudahnya diintegrasikan dengan bahasa permodelan lain (Rittgen, 2009). Selain itu juga UML memiliki kepresisian dalam menerjemahkan rancangan hingga tahap arsitektur dan desain (Murray and Clark, 2015). UML memiliki teknik dan notasi yang memungkinkan pengembang dalam mendefinisikan komponen suatu sistem dari berbagai cara pandang dan langkah pengembangan. Notasi didalam UML diklasifikasikan kedalam tiga kategori diantaranya (Shoval, 2007): 1. Structure Diagram Mendeskripsikan struktur tetap dari sistem beserta komponen didalamnya untuk diketahui terkait hubungan antar komponen tersebut. Tipe structure diagram diantaranya class diagram, objects diagram, components diagram, and deployment diagram. 2.
Behavior Diagram Menggambarkan cara pandang sistem secara dinamis, yakni aspek
fungsional didalam sistem. Tipe behavior diagrams diantaranya use case diagram, sequence diagram, collaboration diagram, state chart, dan activity diagram. 3.
Model Management Diagram Model management diagram merupakan diagram yang mengatur antar
komponen dalam sistem. Tipe model management diagram diantaranya package diagram, subsystem diagram, and model diagram.
II-18
UML merupakan bahasa pemodelan berorientasikan objek yang terstandar dan secara luas digunakan dalam memodelkan sistem berbasis software. Berikut ini beberapa manfaat dalam menggunakan UML sebagai bahasa pemodelan (Milicev, 2009) : 1.
UML Terstandar Bahasa pemodelan ini untuk mengembangkan dan melakukan beberapa
bentuk perubahan model suatu software. UML banyak didukung oleh berbagai software pengembangan komersial. 2.
UML Secara Konseptual Cukup Lengkap UML dapat menggambarkan konsep dari kebutuhan secara praktis.
UML dapat diimplementasikan dari berbagai domain pengembangan sistem, selain itu juga dapat memodelkan proses bisnis dan konfigurasi hardware sistem. 3.
UML Berorientasi Objek UML mendukung semua paradigma pengembangan objek, selain itu
dapat menghidarkan dari perancangan kembali setelah memasuki langkah pemrograman. 4.
UML dapat Dikontrol dan Dijabarkan dalam Standar UML memungkinkan untuk melakukan fungsi kontrol domain aplikasi
atau masalah secara konkrit. Ketika ingin menggambarkan cara kerja sistem, analyst dapat menggunakan UML beserta diagram didalamnya. Berikut ini beberapa diagram UML yang dapat disajikan : 1.
Activity Diagram Activity diagram merupakan diagram alir yang merepresentasikan
aliran
dari
satu
aktivitas
ke
aktivitas
lain.
Aktivitas
tersebut
mendeskripsikan cara kerja dari suatu sistem, sehingga activity diagram juga berfungsi untuk memetakan aliran suatu sistem yang terdiri dari beberapa sub-sistem yang saling berhubungan (Schmuller, 2004). Activity diagram sebagai notasi front-end lebih mengedepankan dalam menangkap aspek yang relevan pada fase perancangan (Sarshar & Loos,
II-19
2003). Sebagai salah satu bagian dari standar UML, activity diagram dapat diterapkan dalam memodelkan proses terkomputerisasi dan digunakan untuk memodelkan proses di dalam organisasi. Sebagai proses organisasi, notasi didalam UML menunjukkan kontrol aliran antara aktivitas di dalam proses (Riesco, Acosta, & Montejano, 2013). Activity diagram sangat berguna untuk menunjukkan proses bisnis atau apa yang terjadi didalam operasi sebuah sistem, namun dengan bentuk yang lebih sederhana karena merupakan bagian integral dalam analis sistem (Schmuller, 2004). Selain sebagai analisis proses bisnis, activity diagram dapat digunakan untuk mengidentifikasi use case diagram (Baekgard, 2007). Sehingga dengan menggunakan activity diagram, pengembang dapat mengklarifikasi proses dan langkah baik pada domain klien maupun sebagai analyst sistem. Tabel 2.1 Simbol Activity Diagram
Simbol
Nama
Keterangan
Initial Node Final Node Activity
Merupakan bentuk penyederhanaan operasi atau proses bisnis
Decision Node
Menggambarkan penjabaran dalam suatu aliran aktivitas
Control Flow Note
2.
Mencerminkan permulaan suatu aktivitas Mencerminkan berakhirnya suatu aktivitas
Menunjukkan hubungan antar aktivitas Menunjukkan catatan dalam suatu elemen
Package Diagram Merupakan sebuah diagram yang mengorganisir elemen fungsional
kedalam suatu paket. Tujuannya yakni agar fungsi-fungsi yang dikelompokkan dapat dengan mudah dianalisis terkait ada tidaknya kekurangan dalam lingkup fungsionalitas sistem. Fungsionalitas sistem yang dimaksud dapat berasal dari class diagram, use case maupun
II-20
komponen di dalam sub sistem. Manfaat dari penggunaan package diagram ini agar perancangan sistem terhindar dari pemetaan yang tidak lengkap dan tidak akurat (Schmuller, 2004). Tabel 2.2 Simbol Package Diagram
Simbol
Nama
Package
Containment
3.
Keterangan Merupakan bentuk pengelompokan suatu elemen dalam diagram UML Menunjukkan hubungan sumber dan target elemen
Use Case Diagram Use case diagram merupakan bentuk pemetaan perancangan kebutuhan
dari suatu sistem dengan memetakan aktivitas internal dan ekternal yang berpengaruh kedalam sistem. Use case juga memungkinkan pengembang sistem untuk menjelajahi apa yang dapat terjadi di dalam suatu sistem, sehingga use case diagram dapat membantu dalam mengekplorasi terkait apa yang seharusnya dimiliki oleh sistem (Schmuller, 2004). Tabel 2.3 Simbol Use Case Diagram
Simbol
Nama
Keterangan Mendefinisikan pihak eksternal
Actor
yang memainkan peran dalam interaksi terhadap sistem.
Association
Mengasosiasikan
atau
menghubungkan suatu elemen. Merepresentasikan
suatu
fungsionaltas use case yang Include
tergolong dalam suatu use case tertentu
berdasarkan
“digolongkan dari“ (that is ) dan “digunakan oleh” (used by).
II-21
Tabel 2.3 Simbol Use Case Diagram (lanjutan)
Simbol
Nama
Keterangan Merepresentasikan jabaran suatu
Extend
use case dengan penambahan beberapa langkah.
System
Use case
Merepresentasikan
kondisi
sistem tertentu Suatu bentuk keterjadian yang terdapat didalam sistem
Use case dibutuhkan untuk menampung scope dari fungsionalitas sistem. Didalam use case terdapat include relationship yang menunjukkan relasi secara langsung antara dua use case yang mengindikasi keadaan dari suatu use case mengandung spesifikasi dari use case lainnya. Sedangkan exclude relationship merupakan hubungan antara use case yang mengindikasi sebuah penambahan dari use case lain dalam keadaan tertentu. Fragmen dalam extending relationship use case didefinisikan dengan menjabarkan use case tersebut dalam sebuah spesifikasi pada extended use case (Milicev, 2009). 4.
Class Diagram Class diagram merupakan sebuah kategori kata benda, kata kerja dan
frase di dalam sistem yang memiliki kesamaan atribut dan operasi. Penggunaan class diagram memiliki manfaat untuk membantu sisi analyst dalam membongkar detil penting masalah yang akan dipecahkan. Dalam menyajikan class diagram dipaparkan dalam bentuk high level, kemudian secara rinci dapat disajikan melalui diagram terpisah (Schmuller, 2004).
II-22
Tabel 2.4 Simbol Class Diagram
Simbol
Nama
Keterangan Merepresentasikan suatu sistem yang dibangun
Class
Attribute
entitas
Merupakan atribut dari suatu class
Mengasosiasikan atau menghubungkan satu elemen diagram dengan elemen diagram lain. Multiplicity merupakan interval dengan permulaan batas bawah dan Multiplicity diakhiri dengan batas atas (Milicev, 2009). Merupakan hubungan antar class menunjukkan hubungan Aggregation yang keterkaitan yang dapat dipisahkan (Shoval, 2007). Merupakan hubungan antar class menunjukkan hubungan Composition yang keterkaitan yang tidak bisa dipisahkan (Shoval, 2007). Menunjukkan hubungan antara Generalization superclass dan subclass (Shoval, 2007). Association
Class diagram dan entity relation diagram memiliki konsep yang sama, namun memiliki prinsip yang berbeda. Class diagram dapat dikonversikan kedalam basis data relasional dengan mengkonversikan skema konseptual kedalam skema logika (Shah & Slaughter, 2003). 5.
Deployment Diagram Deployment diagram dapat menunjukkan gambaran secara fisik sistem
berbasiskan komputer. Deployment diagram tersebut juga dapat dapat menunjukkan secara detail hubungan serta software yang mengoperasikan sistem tersebut. Sehingga dengan adanya deployment diagram, dapat diketahui apa yang diperlukan ketika hendak mengimplementasikan sistem secara nyata (Schmuller, 2004).
II-23
Tabel 2.5 Simbol Deployment Diagram
Simbol
Nama Node
Keterangan Mencerminkan
sumber
daya
komputasi Spesifikasi fisik terkait informasi
Artifact
yang
digunakan
dalam
pengembangan software Seperangkat Specification
spesifikasi
yang
menentukan jenis eksekusi dari node
Component
Merepresentasikan bagian modular dari suatu sistem Mengasosiasikan
Association
menghubungkan
atau satu
elemen
diagram dengan elemen diagram lain.
2.11
Perancangan Graphical User Interface (GUI) Merancang suatu GUI dapat dibagi menjadi beberapa layer, layer tersebut
saling berinteraksi dalam mencapai tampilan secara spesifik seperti berikut (Milicev, 2009) : 1.
GUI component merupakan spesifikasi dari GUI yang dibuat selama proses perancangan GUI. GUI component memiliki beberapa library yang diatur oleh GUI framework/GUI widget
2.
GUI widget merupakan elemen dinamis dari sistem yang mengontrol GUI selama aplikasi berjalan. GUI tersebut bersifat statis seperti halnya widget menu pada tree view.
3.
GUI style configuration merupakan pengaturan style dalam GUI yang bersifat statis. Dalam pengembangan sistem berbasis web, GUI style configuration dapat berupa Cascading Style Sheets (CSS) di HTML
II-24
Memodelkan GUI berorientasikan objek dalam sistem informasi UML, sebagian besar pengembang aplikasi lebih memilih menggunakan tatanan GUI framework tree view seperti gambar 2.5 (Milicev, 2009). Jika menu diorganisir dalam bentuk hierarki atau tree view menu, user dapat dipermudah dalam menentukan pilihan. Interface tersebut cocok untuk berbagai user baik yang sudah familiar maupun tidak dengan sistem informasi (Shoval, 2007).
Gambar 2.4 Tingkatan layer arsitektur tampilan Sumber: (Milicev, 2009)
Pada tampilan GUI framework gambar 2.5, pada kolom 1 merupakan komponen panel sebagai komponen utama. Sedangkan pada kolom nomor 2 merupakan kolom komponen tree view untuk menampilkan menu. Kemudian untuk kolom nomor 3 disediakan sebagai kolom pencarian. Pada kolom 4 ditampilkan panel yang terdiri dari komponen objek tampilan.
Gambar 2.5 Tampilan GUI framework Sumber: (Milicev, 2009)
II-25
2.12
Perancangan Test Case Perancangan software menggunakan bahasa pemodelan memiliki manfaat
dalam memodelkan cara kerja sistem melalui proses untuk lebih memahami sistem yang sedang dimodelkan. Bahasa pemodelan yang digunakan juga dapat digunakan sebagai test case untuk melakukan pengecekan kembali atas apa yang telah disampaikan melalui model yang dirancang. Pengecekan kembali atas apa yang telah disampaikan dapat melalui pengujian MBT (Model Based Testing), namun MBT tergantung pada akurasi pemilihan model. Melakukan pengujian melalui MBT dapat dilakukan melalui langkah sebagai berikut (Jorgensen, 2014): 1. Transformasikan model yang digunakan kedalam test case. 2. Lakukan pengujian test case dan catat hasilnya 3. Berdasarkan hasil test case yang didapat, apabila terdapat perbaikan segera perbaiki dan lanjutkan pada langkah berikutnya Selain melalui MBT, hubungan use case dengan perancangan software sangat memungkinkan untuk dibuat elemen pengujian. Elemen pengujian tersebut yakni dengan mentransformasikan use case menjadi bentuk pengujian. Elemen pengujian melalui use case, digunakan untuk memverifikasi fungsional umum dari software yang dirancang. Setiap elemen pengujian merupakan bagian dari stereotyped use case. Sedangkan setiap pengujian memiliki banyak skenario pengujian Mengidentifikasi skenario pengujian setiap test case melalui elemen use case dapat mengacu pada beberapa langkah diantaranya (Rosenberg & Stephens, 2007): 1.
Baca kembali use case dalam setiap kontek dimana elemen kontrol digunakan
2.
Setiap test case dapat dibuat skenario pengujian setiap skenario use case.
3.
Setiap skenario tes diberi nama sesuai dengan skenario sumber use case.
II-26
