II-1
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-2
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-3
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-4
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-5 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-6
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-7 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-8
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-9
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
II-10
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-11
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-12
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. RequirementGathering
RequirementGathering merupakan tahap pengumpulan dan identifikasi kebutuhan pengguna. Pada dasarnya identifikasi penggguna dimaksudkan untuk menjadikan dasar dalam membangun sistem yang tepat.
II-13
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-14
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 classdiagram.
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-15
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-16 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
II-17
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-18
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
II-19
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-20
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 Mencerminkan permulaan suatu
aktivitas
Final Node Mencerminkan berakhirnya suatu
aktivitas
Activity Merupakan bentuk penyederhanaan
operasi atau proses bisnis
Decision Node Menggambarkan penjabaran dalam
suatu aliran aktivitas
Control Flow Menunjukkan hubungan antar
aktivitas
Note Menunjukkan catatan dalam suatu
elemen
2. 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-21
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 Keterangan
Package Merupakan bentuk pengelompokan
suatu elemen dalam diagram UML
Containment Menunjukkan hubungan sumber
dan target elemen
3. Use Case Diagram
Use casediagram 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
Actor
Mendefinisikan pihak eksternal yang memainkan peran dalam interaksi terhadap sistem.
Association Mengasosiasikan atau
menghubungkan suatu elemen.
Include
Merepresentasikan suatu fungsionaltas use case yang tergolong dalam suatu use case
tertentu berdasarkan “digolongkan dari“ (that is ) dan “digunakan oleh” (used by).
II-22
Tabel 2.3 Simbol Use Case Diagram (lanjutan)
Simbol Nama Keterangan
Extend
Merepresentasikan jabaran suatu
use case dengan penambahan beberapa langkah.
System Merepresentasikan kondisi
sistem tertentu
Use case 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-23
Tabel 2.4 Simbol Class Diagram
Simbol Nama Keterangan
Class Merepresentasikan suatu entitas
sistem yang dibangun
Attribute Merupakan atribut dari suatu class
Association
Mengasosiasikan atau
menghubungkan satu elemen diagram dengan elemen diagram lain.
Multiplicity
Multiplicity merupakan interval dengan permulaan batas bawah dan diakhiri dengan batas atas (Milicev, 2009).
Aggregation
Merupakan hubungan antar class
yang menunjukkan hubungan keterkaitan yang dapat dipisahkan (Shoval, 2007).
Composition
Merupakan hubungan antar class
yang menunjukkan hubungan keterkaitan yang tidak bisa dipisahkan (Shoval, 2007).
Generalization
Menunjukkan hubungan antara
superclass dan subclass (Shoval, 2007).
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-24
Tabel 2.5 Simbol Deployment Diagram
Simbol Nama Keterangan
Node Mencerminkan sumber daya
komputasi
Artifact
Spesifikasi fisik terkait informasi yang digunakan dalam pengembangan software
Specification
Seperangkat spesifikasi yang menentukan jenis eksekusi dari
node
Component Merepresentasikan bagian modular
dari suatu sistem
Association
Mengasosiasikan atau
menghubungkan 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-25
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-26
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.
