Pusat Pengembangan, Penelitian, dan Pengabdian Masyarakat (LP4M) Panitia tidak bertanggung jawab terhadap isi paper dari peserta

Dipublikasikan Tahun 2014 oleh: Pusat Pengembangan, Penelitian, dan Pengabdian Masyarakat (LP4M) STMIK DIPANEGARA MAKASSAR SULAWESI SELATAN - INDONESIA

ISSN: 2355-1941

Panitia tidak bertanggung jawab terhadap isi paper dari peserta

Komferensi Nasional Sistem Informasi 2014, STMIK Dipanegara Makassar 27 Pebruari – 1 Maret 2014

PROCEEDINGS KONFERENSI NASIONAL SISTEM INFORMASI 2014 Ketua Editor Drs. I Wayan Simpen, M.MSI.

Sekretaris Editor Yesaya Tommy Paulus, S.Kom., MT.

Anggota Editor M. Syukri Mustafa, S.Si., M.MSI. Indra Samsie, M.Kom. Jufri, S.Kom., MT. Asran, ST.,MT. Ahmad Sukarna S.,S.Kom.,MT.

KNSI 2014

ii


KOMITE KNSI 2014 PENANGGUNG JAWAB: Drs. Suarga, M.Sc., M.Math., Ph.D. Ketua Sekolah Tinggi Manajemen Informatika dan Komputer (STMIK) Dipanegara Makassar KETUA PELAKSANA KNSI 2014: Indra Samsie, M.Kom. STEERING COMMITTEE • Kridanto Surendro, Ph.D • Dr. Rila Mandala • Dr. Husni S Sastramihardja • Prof. Iping Supriatna PROGRAM COMMITTEE • Dr. Kridanto Surendro (ITB) • Dr. Rila Mandala (ITB) • Dr. Husni Sastramihardja (ITB) • Dr. Masayu Leyla Khodra (ITB) • Dr. Djoko Soetarno (BINUS) • Dr. Agus Hardjoko (UGM) • Dr. Sri Hartati (UGM) • Dr. Retyanto Wardoyo (UGM) • Prof. Zainal A. Hasibuan (UI) • Dr. Sri Nurdiati (IPB) • Dr. Agus Buono (IPB) • Prof. Benny Mutiara (Universitas Gunadarma) TECHNICAL COMMITTEE • • • • • • • • • • • •

•

Drs. I Wayan Simpen, M.MSI. Johny Soetikno, SE.,MM. Indra Samsie, S.Kom.,M.Kom. M. Syukri Mustafa, S.Si.,M.MSI. Ir. Mirfan, MM. Abdul Ibrahim, S.Kom.,M.MSI. Ahmad Sukarna, S.Kom.,M.Si. Asran, ST.,MT. Wilem Musu, S.Kom.,MT. Erfan Hasmin, S.Kom.,MT. Komang Aryasa, S.Kom.,MT. Yesaya Tommy Paulus, S.Kom.,MT. Jufri, S.Kom.,MT.

KNSI 2014

• • • • • • • • • • • •

Cucut Susanto, S.Kom.,M.Si. Ir. Mirfan, MM. Ir. H. Irsal, MT Michael Octavianus, S.Kom.,MM. Ir. Kamarullah Nusu Muh. Khadafi Tayyeb, SE. Ir. Mahmud Hasan Michael Polinggomang, SSI. Nurbaeda, S.Kom. Marsha, SE., ST. Herlina, SE. Ramlah Amir, S.Pd.

iii


DAFTAR ISI

Susunan Komite KNSI 2014 ......................................................................................................................

iii

Daftar isi .....................................................................................................................................................

iv

Kata Sambutan Ketua STMIK Dipanegara Makassar ................................................................................

v

Kata Sambutan Ketua Panitia KNSI 2014 ..................................................................................................

vi

Susunan Acara KNSI 2014 .........................................................................................................................

vii

Jadwal Presentas .........................................................................................................................................

x

Daftar Makalah ............................................................................................................................................

xxvii

Makalah ......................................................................................................................................................

1

KNSI 2014

iv


KNSI2014-82

Pengembangan Tools pada Fase Requirement Engineering dengan Metode LWBA Reza Chandra Sistem Informasi, Fakultas Ilmu Komputer, Universitas Gunadarma Universitas Gunadarma, Jalan Margonda Raya no. 100, Depok – Jawa Barat 16424 [email protected]

Abstrak Pendeskripsian pada fase requirement engineering dibutuhkan agar penyebab permasalahan menjadi lebih terjajaki (traceable). Yang menjadi permasalahan dari dokumentasi pada fase requirement engineering adalah seringkali timbul inkonsistensi dalam penyajian informasi. Jika pendeskripsian informasi dilakukan secara manual maka kemungkinan terjadinya inkonsistensi penyajian informasi menjadi masalah. Oleh karena itu, pendeskripsian informasi secara otomatis dan konsisten untuk menelusuri penyebab ketidakpuasan. Untuk memperoleh pendeskripsian secara otomatis dan konsisten maka diperlukan suatu perangkat bantu yang dapat menghasilkan pendeskripsian secara otomatis. Berdasarkan permasalahan tersebut maka dikembangkanlah suatu perangkat bantu yang dapat mempermudah pendeskripsian masalah untuk model Lightweight Why Because Analysis (LWBA) pada fase analisis requirement engineering. Kata kunci : tools, DSS, dokumentasi, LWBA, requirement engineering

1.

Pendahuluan

Requirement Engineering merupakan fase awal dari proses rekayasa perangkat lunak. Requirement engineering adalah cabang dari rekayasa perangkat lunak yang mengurusi masalah yang berhubungan dengan tujuan, fungsi, dan batasan-batasan pada sistem perangkat lunak. Termasuk hubungan faktorfaktor tersebut dalam menetapkan spesifikasi yang tepat dari suatu perangkat lunak, proses evolusinya baik berhubungan dengan masalah waktu maupun dengan perangkat lunak lain. (Zave, 1997). Pendeskripsian informasi dilakukan untuk mengetahui masalah yang akan dipecahkan atau diberikan solusinya dalam pengembangan suatu sistem. Kegagalan suatu pengembangan sistem sering disebabkan oleh ketidaktepatan tahapan requirement engineering. Salah satu penyebab dari masalah yang ada adalah terdapat ketidakpuasan dalam penggunaan sistem. Maka dari itu, penyebab dari ketidakpuasan harus dihilangkan atau diminimalkan. Yang menjadi permasalahan pada deskripsi requirement engineering adalah seringkali timbul inkonsistensi dalam penyajian informasi. Jika pendeskripsian informasi dilakukan secara manual maka, besar kemungkinan terjadinya KNSI 2014

inkonsistensi penyajian informasi terutama untuk menjadi masalah. Oleh karena itu, dibutuhkan pendeskripsian informasi secara otomatis dan konsisten untuk menelusuri penyebab ketidakpuasan. Untuk memperoleh pendeskripsian secara otomatis dan konsisten maka diperlukan suatu perangkat bantu yang dapat menghasilkan visualisasi dan pendeskripsian secara otomatis. Berdasarkan permasalahan tersebut maka dikembangkanlah suatu perangkat bantu yang dapat mempermudah visualisasi dan pendeskripsian masalah untuk Lightweight Why Because Analysis (LWBA) pada fase requirement engineering. 2.

Landasan Teori

2.1

Lightweight (LWBA)

Why

Because

Analysis

Lightweight Why Because Analysis merupakan pengembangan dari metode Why Because Analysis (WBA) dan diperkenalkan sebagai perangkat bantu untuk pengembangan sistem yang berkelanjutan (sustainable). WBA mempertimbangkan aspek nonteknis yaitu manusia, kultur, organisasi, regulasi

403


pada sistem nyata. WBA ini tidak terkait pada perangkat bantu khusus ataupun paradigma pemograman apa saja, berbeda dengan UML yang terkait dengan paradigma pemrograman objek (OOP). WBA menganalisis penyebab awal, dengan cara mengetahui faktor penyebab yang diperlukan (Necessary Caused Factor - NCF).

3.

LWBA disebut “lightweight” (ringan) karena analisis ini tidak mendetail dan tidak “formal” seperti WBA. LWBA adalah analisis “semi-formal” yang menyelidiki kendala-kendala tanpa cara yang menghakimi. LWBA juga digunakan untuk memahami kebutuhan dari suatu metoda pengembangan yang baru dengan bertumpu pada keberlanjutan (sustainability). (Zave, 1997) Ide utama dari analisis LWBA adalah mengenali faktor kausal yang dapat di ganti untuk membuat sebuah sistem menjadi lebih baik. Analisis pada LWBA juga mencakup pada aspek non teknis, misalkan sumber daya manusia, regulasi dan organisasi. Analisis LWBA ini mempunyai beberapa karakteristik, antara lain merupakan analisis yang bersifat semi-formal. Berbeda dengan analisis WBA yang bersifat formal. Pada dasarnya LWBA mengidentifikasi kendala-kendala pada sistem. Identifikasi terhadap kendala-kendala dilakukan tanpa cara yang menghakimi. Karena itu sangat penting untuk mengenali bagian mana yang dapat di ganti oleh pengembang sistem atau bagian mana yang membutuhkan upaya organisasi untuk menggantinya.

Gambar 2. Contoh Analisis LWBG 2.2

Gambar 1. Lightweight Why Because Graph (LWBG) (Wiryana, 2009) Analisis akan dilakukan dengan mengidentifikasi faktor kausal, seperti terlihat pada Gambar 2, node sebagai faktor kausal akan diklasifikasikan menjadi: 1. Node (1) adalah node yang umum. Sebagai contoh node (6) mempunyai faktor kausal node (7) yang tidak dapat di ganti. 2. Node (2), adalah node yang dapat di ganti dengan menerapkan software/hardware atau organisasi/orang. Misalnya pada node (4) mempunyai faktor kausal node (5), dengan menerapkan software atau perubahan pada node (5), node (4) dapat dihindari. Pada KNSI 2014

dasarnya, sistem di rancang untuk menjawab permasalahan. Node (3) adalah node yang membutuhkan pergantian, tapi pergantian ini membutuhkan waktu yang panjang dan tidak berada di bawah kontrol pengembang, misalnya pergantian organisasi, regulasi baru dikembangkan, kesadaran masyarakat dikembangkan. Misalnya untuk node (8) mempunyai faktor kausal node (9). Pihak pengembang memahami bahwa dengan mengganti node (9) maka node (8) dapat dihindari. Akan tetapi, node (9) membutuhkan waktu yang panjang untuk diterapkan. Untuk itu, pihak pengembang harus menemukan cara bagaimana untuk mengurangi dampak dari hubungan sebab dan akibat ini. Node ini akan menjadi bagian dari pergantian organisasi dan strategi pembelajaran.

Fase Requirement Engineering

Requirements engineering adalah fase terdepan dari proses rekayasa perangkat lunak, dimana software requirements (kebutuhan) dari user (pengguna) dan customer (pelanggan) dikumpulkan, dipahami dan ditetapkan. Para pakar software engineering sepakat bahwa requirements engineering adalah suatu pekerjaan yang sangat penting. Fakta membuktikan bahwa kebanyakan kegagalan pengembangan software disebabkan karena adaya ketidakkonsistenan (inconsistent), ketidaklengkapan (incomplete), maupun ketidakbenaran (incorrect) dari requirements specification (spesifikasi kebutuhan). (Wahono, 2006) Software biasanya direkayasa dalam proyek dan siklus pengembangan, dimana requirement engineering dilakukan setelah inisiasi proyek dan sebelum perancangan sistem. Hal ini secara tradisional diikuti oleh pengkodean, pengujian, pengoperasian, dan tahap pemeliharaan seperti dapat dilihat pada Gambar 3. Namun, requirement engineering juga dapat dilakukan secara iteratif dan bertahap melalui siklus pengembangan perangkat lunak, dan hasil dari tahap requirement engineering

404


juga dapat digunakan untuk tujuan perencanaan dan untuk menentukan apakah proyek harus terus dijalankan atau tidak (Darmayantie, 2012). Requirement engineering lebih dari sekedar kumpulan fakta, tetapi itu mencakup semua kegiatan siklus hidup proyek terkait dengan memahami kemampuan yang diperlukan dan atribut dari suatu sistem.

Gambar 3. Fase Rekayasa Perangkat Lunak 2.3. Pendokumentasian yang Baik Untuk menggunakan sistem yang kompleks dengan aman dan efisien membutuhkan pelatihan dan dokumentasi, berdasarkan pada pemahaman yang baik tentang sistem itu sendiri. Sistem adalah (atau seharusnya) berdasarkan spesifikasi dari apa yang dilakukan. Maka dari itu, diambil persyaratan atau spesifikasi desain untuk selanjutnya menjadi predikat (logis) dalam bahasa yang tepat bahwa sistem diperlukan untuk suatu kebutuhan. Spesifikasi ini menempatkan kondisi pada variabel keadaan tertentu dari sistem. Sebuah sistem memenuhi spesifikasi hanya dalam kasus, tidak menunjukkan perilaku yang dilarang oleh spesifikasi, dan kegagalan untuk memenuhi spesifikasi yang hanya dalam kasus itu mungkin menunjukkan perilaku yang dilarang oleh spesifikasi. Perubahan requirement dan pengembangan suatu sistem disebabkan oleh kebutuhan dalam perancangan dan umpan balik dari pengguna. Penting sekali melibatkan pengguna dalam proses perancangan karena pengguna merupakan bagian penting dari sistem. Apabila pengguna sangat memahami sistem, mereka dapat membantu untuk perancangan sistem yang lebih baik. Secara logis, dokumentasi pengguna merupakan sesuatu yang mencerminkan sistem, suatu metode yang singkat untuk perancangan-uji coba-perancangan kembali. (Timbleby & Ladkin, 1996) Karakteristik dari sistem dokumentasi yang baik dianggap seperti bentuk dokumentasi apa yang harus ambil. Persyaratan dokumentasi sistem KNSI 2014

dipertimbangkan dan dilakukan usaha untuk mendefinisikan dokumentasi sistem apa yang harus lakukan, misalnya apa tujuannya. Kemungkinan untuk mengotomatisasi dokumentasi sistem saat ini telah dikembangkan. 3.

Perancangan Sistem

Penggunaan model formal, yang merupakan cara abstrak untuk menentukan sistem komputer, merupakan realitas industri. Penggunaan notasi abstrak sebelum memulai implementasi sangat membantu untuk pemahaman masalah yang lebih baik. Sebagai permulaan dalam pengembangan perangkat lunak, dibutuhkan suatu requirement yang menghasilkan dokumen berkualitas tinggi sebagai masukan dari rekonstruksi model. Namun demikian, jika requirement telah di dapat masih merupakan tugas yang sulit untuk membangun model dan implementasi yang mencerminkan masalah. Transisi dari persyaratan untuk analisis atau model desain adalah proses manual, dan karena itu rawan kesalahan. (Cabral & Sampaio, 2008) 3.1. Deskripsi Sistem Untuk menghemat waktu pengerjaan pada fase analisis kebutuhan, perangkat bantu ini dikembangkan. Perangkat bantu ini cocok dipakai untuk suatu pengembangan sistem yang memiliki waktu pengembangan, dana dan SDM yang terbatas. Perangkat bantu ini akan memudahkan pengguna sistem dalam melakukan analisis kebutuhan. Adapun diagram use-case untuk perangkat bantu ini adalah seperti Gambar 4.

Gambar 4. Diagram Use Case Terdapat tiga pengguna yang memakai perangkat bantu ini, yaitu sistem analis, sistem desainer dan klien. Ketiga pengguna tersebut dapat memasukkan file, setelah file dimasukkan, kemudian file diproses dengan cara parsing untuk mendapatkan informasi dari file yang dimasukkan.

405


3.2. Pengguna Pengguna yang memakai perangkat bantu yang dibuat adalah pengguna yang pekerjaannya berhubungan dengan perancangan sistem yang memakai teknik analisis LWBA seperti: • Perancang sistem. Perancang sistem dapat memanfaatkan alat ini untuk memudahkan perancangan sistem. • Sistem analis. Sistem analis dapat memanfaatkan alat ini untuk memudahkan dalam mencari penyebab suatu masalah dan menemukan solusinya. • Klien. Klien dapat mengetahui alur dari masalah yang ada. 4.

Hasil dan Pembahasan

Contoh kasus yang dipakai adalah contoh kasus dari skripsi Riska Zahara yang berjudul “Pengembangan Layanan Location Base Service Dan Chat Pada Aplikasi Panduan Haji Dengan Pendekatan Lightweight Why Because Analysis” dengan contoh kasus pada permasalahan sistem penyelenggaraan haji dan umroh (Zahara, 2011). Arsitektur yang diterapkan untuk perancangan sistem ini adalah arsitektur pada client. Pengguna dapat langsung men-generate file spreadsheet dengan format atribut yang telah disediakan melalui web browser. Apabila pengguna sudah benar menganalisis permasalahan dan menghubungkan relasi-relasinya maka tampilan dalam format dokumen akan muncul. Tampilan dari arsitektur terlihat seperti Gambar 5.

Gambar 5. Asitektur Blok Diagram 4.1. Uploader

Gambar 6. Data dalam Bentuk Spreadsheet 4.2. Format Dokumen File yang sudah di ekstrak dari spreadsheet selanjutnya akan dicetak ke dalam bentuk dokumen yang hasilnya dapat tampil pada web browser. Adapun potongan programnya adalah sebagai berikut :

for ($i = 2; $i <= $xls->rowCount(); $i++) { echo "[".$tabel[$i][2]." ".$tabel[$i][4]. "] Deskripsi\t: ".$tabel[$i][5]; $item_relasi=explode("-",$relation[$i]); $panjang=count($item_relasi); if($item_relasi[0] !="") { echo "
"; for ($j=0;$j<$panjang;$j++){ $no_row=get_deskripsi($label,$item_relasi[$j],$jumlah); $deskripsi=$tabel[$no_row][4]; echo("
[".$item_relasi[$j]."$deskripsi ]
"); } echo "
"; } echo "
"; }

Kolom didefinisikan sebagai variabel i ($i) dan dilakukan perulangan sebanyak isi baris. Setelah itu isi dari kolom 2 (node), kolom 4 (label) dan kolom 5 (description) akan dibaca. Setelah itu, program akan membaca relasinya. Jika terdapat relasi, maka program akan mencetak relasinya. Hasilnya terlihat seperti Gambar 7.

Uploader yang menggunakan perangkat bantu ini dapat berupa seorang analis sistem atau desainer sistem yang menggunakan LWBA untuk penyelesaian masalahnya. Untuk dapat menjalankan perangkat bantu ini, uploader harus mempunyai file berformat spreadsheet (*.xls) dengan atribut-atribut yang sudah ditentukan. Adapun contoh filenya terlihat seperti Gambar 6 Gambar 7. Output Dokumen Pengembangan perangkat bantu ini menggunakan metode top-down. Metode ini dipakai untuk memudahkan analisis yang dimulai dari KNSI 2014

406


masalah-masalah kecil sehingga kesimpulan penyebab masalah. 5.

dapat

ditarik

Kesimpulan dan Saran

5.1. Kesimpulan Dengan dikembangkannya tools untuk requirement engineering pada model pengembangan sistem LWBA diharapkan penyajian informasi pada fase ini menjadi lebih baik dan pendokumentasian masalah pada fase lebih efisien. 5.2. Saran Perangkat bantu ini masih memiliki keterbatasan. Diharapkan pengembangan selanjutnya, perangkat bantu ini dapat menyajikan informasi secara visual untul lebih memudahkan pengguna dalam melihat permasalahan pada fase requirement engineering. Daftar Pustaka:

[13] Viégas, F. B. & Wattenberg, M., 2012, Artistic Data Visualization: Beyond Visual Analytics. [14] Wahono, R. S., 2006, Menyegarkan Kembali Pemahaman tentang Requirement Engineering.. [15] Wasson, C. S., 2006, System analysis, design, and development. Concepts, principles, and practices, John Willey & Sons, Inc. [16] Wiryana, I. M., 2009, A Sustainable System Development Method with Applications. [17] Wiryana, I. M. & Hasibuan, E., 2007. Pengelolaan Pustaka Menggunakan BibTex, Graha Ilmu. [18] Wybrow, M., 2008, Using semi-automatic layout to improve the usability of diagramming software. [19] Zahara, R., 2011, Pengembangan Layanan Location Base Service Dan Chat Pada Aplikasi Panduan Haji Dengan Pendekatan Lightweight Why Because Analysis. Zave, P., 1997, Classification of Research Efforts in Requirements Engineering, ACM Computing Surveys, Volume 29, pp. 315-321.

[1] Cabral, G. & Sampaio, A., 2008, Automated Formal Specification Generation and Refinement from Requirement Documents, s.l.: s.n. [2] Chris, E. R. & Levinez, J., 1995, Automatic Generation of Technical Documentation, Applied Articial Intelligence, Volume 9, pp. 259-287. [3] Darmayantie, A., 2012, Repository Model and Specification Matching Strategy for Requirement Engineering in Mobile Manufacturing. [4] Few, S., 2006, Information Dashboard Design, s.l.:O'Reilly. [5] Few, S., 2007, Perceptual Edge, s.l.:Cognos. [6] Fry, B., 2004, Computational Information Design. [7] Hendrawan, W., 2009, Software System Requirement Management Planning. [8] Nicolás, J. & Toval, A., 2009, On the generation of requirements specifications from software engineering models: A systematic literature review, Information and Software Technology, Volume 51, pp. 1291-1307. [9] Pratiwi, N. L., 2010, Behavior Engineering. [10] Rasmussen, J., 1986, Information Processing And Human-Machine Interaction. An Approach To Cognitive Engineering. s.l.:Elsevier Science Publishing Co., Inc.. [11] Stephen, E. K. & Woodhull, G., 2004, Graphviz and Dynagraph – Static and Dynamic Graph Drawing Tools. [12] Thimbleby, H. & Ladkin, P., 1996, From logic to manuals. Software Engineering Journal, Volume 11, pp. 347-354. KNSI 2014

407

Pusat Pengembangan, Penelitian, dan Pengabdian Masyarakat (LP4M) Panitia tidak bertanggung jawab terhadap isi paper dari peserta

Recommend Documents