• Tidak ada hasil yang ditemukan

RISET AWAL: PENGEMBANGAN POLA REQUIREMENTS UNTUK PENGEMBANGAN PERANGKAT LUNAK PENDUKUNG SISTEM INFORMASI

N/A
N/A
Protected

Academic year: 2022

Membagikan "RISET AWAL: PENGEMBANGAN POLA REQUIREMENTS UNTUK PENGEMBANGAN PERANGKAT LUNAK PENDUKUNG SISTEM INFORMASI"

Copied!
5
0
0

Teks penuh

(1)

KNSI 2016 – Paper #221

RISET AWAL:

PENGEMBANGAN POLA REQUIREMENTS UNTUK PENGEMBANGAN PERANGKAT LUNAK PENDUKUNG SISTEM INFORMASI

Elviawaty Muisa Zamzami1), Ade Candra2), Dian Rachmawati3) Fakultas Ilmu Komputer – Teknologi Informasi Universitas Sumatera Utara

Kampus USU Padang Bulan Medan

e-mail: 1[email protected] [email protected] 2 [email protected] 3[email protected] [email protected]

Abstrak

Keberhasilan perangkat lunak pendukung sistem informasi dapat diterima para penggunanya jika perangkat lunak tersebut mampu memenuhi hal-hal yang diharapkan ada sebagai solusi dari permasalahan para pengguna. Keinginan- keinginan dan kebutuhan-kebutuhan dari pengguna dimuat dalam requirements perangkat lunak. Menentukan requirements perangkat lunak bukanlah hal yang mudah bagi pengembang. Pada rekayasa requirements banyak faktor yang dipertimbangkan untuk menentukan suatu keinginan dan kebutuhan pengguna termasuk sebagai requirements perangkat lunak. Kesulitan mengelisitasi dan menentukan requirements perangkat lunak dapat diperkecil dengan tersedianya pola requirements. Pola requirements berperan sebagai panduan kepada pengembang perangkat lunak tentang requirements apa yang biasanya ditentukan sebagai requirements pada perangkat lunak sejenis dengan perangkat lunak yang dikembangkan. Penelitian ini akan mengembangkan pola requirements yang dapat digunakan pada pengembangan perangkat lunak pendukung sistem informasi dengan ranah permasalahan tertentu. Pengembangan pola requirements mengacu pada pendekatan rekayasa balik perangkat lunak.

Kata kunci: requirements, pola requirements, elisitasi requirements, rekayasa requirements.

1. Pendahuluan

Perangkat lunak pendukung sistem informasi dikembangkan untuk menjadi solusi penyelesaian permasalahan sistem informasi tertentu. Untuk mengetahui hal apa sebenarnya yang menjadi permasalahan dan menentukan hal apa yang akan diimplementasikan menjadi perangkat lunak bukanlah sesuatu yang mudah buat pengembang atau perekayasa perangkat lunak. Pada pengembangan perangkat lunak, sesuatu hal yang akan diimplementasikan menjadi perangkat lunak dikenal dengan istilah requirements.

Requirement merupakan sebuah kondisi atau kemampuan yang dibutuhkan oleh seorang user untuk menyelesaikan sebuah permasalahan atau mencapai sebuah tujuan. Dapat juga didefinisikan sebagai sebuah kondisi atau kemampuan yang harus dipenuhi atau dimiliki oleh sistem atau komponen sistem untuk memenuhi kontrak, standar, spesifikasi, atau dokumen lain yang diberlakukan resmi [467], [469]. Requirements harus didokumentasikan sebagai dokumen requirements atau dokumen spesifikasi requirements perangkat lunak (software requirements specification= SRS).

Proses menentukan requirements apa yang akan diimplementasikan menjadi perangkat lunak termasuk dalam rekayasa requirements (requirements engineering). Pada rekayasa requirements, perekayasa akan melakukan aktifitas elisitasi requirements (requirements elicitation) untuk mengumpulkan requirements. Elisitasi requirements dapat diperoleh dari beberapa sumber, antara lain stakeholders, standar organisasi, regulasi, informasi domain, dan dokumen.

Elisitasi requirements juga mempunyai beberapa teknik, antara lain adalah melakukan wawancara atau bertanya kepada stakeholder. Namun, stakeholders sering tidak sepenuhnya memahami kebutuhan mereka, tidak sepenuhnya memahami kemampuan dan keterbatasan komputer, terkadang mempunyai pandangan yang bertentangan, serta tidak

(2)

berpartisipasi didalam rekayasa engineering [468]. Dengan demikian, dapat digunakan teknik elisitasi lainnya yaitu dengan penggunaan ulang requirements yang dimuat pada pola-pola requirements perangkat lunak.

Pola requirements perangkat lunak dapat dijadikan sebagai panduan untuk mengetahui requirements yang seharusnya ada pada perangkat lunak tertentu serta dapat mengurangi waktu dan biaya untuk menemukan requirements. Namun, seperti halnya dokumen requirements yang sering diabaikan keterkiniannya oleh perekayasa perangkat lunak, demikian pula dokumen pola requirementperangkat lunak. Dengan demikian, pada penelitian yang dilakukan oleh penulis dan sedang berlangsung, melakukan pengembangan suatu pola requirement perangkat lunak [476]. Pola requirements yang dikembangkan merupakan pola requirements yang diperoleh dari interaksi pengguna pada antarmuka perangkat lunak pendukung sistem informasi.

Penelitian ini merupakan penelitian lanjutan dari penelitian sebelumnya yang telah menghasilkan sebuah metode R3 (Requirements Recovery and Reconstruction) untuk memperoleh kembali requirements dari perangkat lunak atau sistem informasi jadi (existing information system) [475].

2. Metode Penelitian

Penelitian yang sedang berlangsung ini akan mengembangkan pola-pola requirements interaksi pengguna pada antarmuka pengguna perangkat lunak tertentu. Pola-pola requirements dikembangkan dengan pendekatan rekayasa balik (reverse engineering). Dari perangkat lunak jadi (existing software) dan/atau dokumen requirements yang bersesuaian dengan perangkat lunak jadi akan diperoleh requirement interaksi pada antarmuka.

Aktifitas penelitian yang dilakukan pada penelitian ini dimuat pada Gambar 93 berikut ini:

Gambar 93. Aktifitas penelitian.

Penelitian ini dimulai dengan aktivitas “Pengumpulan Kandidat Pola Req”. Aktivitas ini akan melibatkan pelaku eksperimen penelitian yang memasukkan data requirements dari perangkat lunak jadi pendukung sistem informasi atau dokumen requirements. Dengan aktivitas ini, akan terbentuk ontologi yang merepresentasikan kandidat pola requirement interaksi pada antarmuka pengguna.

Berikutnya adalah aktivitas “Verifikasi Kandidat Pola Req”. Aktivitas ini akan memeriksa kesesuaian data requirements terhadap elemen-elemen yang dimuat pada template ontologi. Jika terjadi ketidaksesuaian, maka harus dilakukan perbaikan. Pada aktivitas ini juga dilakukan analisa terhadap kandidat pola requirement.

Terhadap kandidat pola requirement dilakukan aktivitas selanjutnya, aktivitas “Pembentukan Pola Req”. Aktivitas ini akan menggabungkan ontologi yang merepresentasikan kandidat pola sehingga terbentuk ontologi yang merepresentasikan pola requirement interaksi terhadap antarmuka pengguna. Dilakukan juga peninjauan terhadap konsistensi pola requirement. Pada aktivitas ini akan ditentukan requirements yang termasuk kedalam pola utama dan pola tambahan.

(3)

Aktivitas terakhir pada penelitian ini adalah “Validasi Pola Req”. Pada aktivitas ini akan dirancang kuesioner yang dijadikan sebagai perkakas validasi. Pada aktivitas ini validasi dilakukan terhadap masukan berupa data requirement interaksi dan requirement antarmuka dari perangkat lunak jadi dan/atau dokumen requirements. Validasi keluaran dilakukan dengan menyebarkan kuesioner terhadap responden untuk memeriksa kesesuaian pola requirements sehingga diperoleh validitas pola requirement interaksi terhadap antarmuka pengguna perangkat lunak.

3. Pembahasan

Penelitian ini terkait dengan penelitian yang telah dilakukan sebelumnya oleh beberapa peneliti. Penelitian terkait dengan penelitian ini dimuat pada Tabel 1 berikut:

Tabel 44: Penelitian terkait.

No. Peneliti Topik / Hasil Penelitian

Tahun Publikasi Penelitian

1. Andriyani, Yanti [462]

SRS pattern bisa direpresentasikan dengan memahami proses registrasi akademik yang sudah

diimplementasikan untuk memperoleh kebutuhan software spesifik.

2011

2. Budiardjo, Eko [464]

Sebuah varian template pola Software Requirements

Specification 2009

3. Hoffmann,Axel, et al. [466]

Software requirement patterns terdiri dari nama, goal, forces dan template req yang telah ditetapkan yang dapat digunakan untuk menentukan requirements berdasarkan kepercayaan tertentu.

2012

4. Palomares,Cristina [470]

Menunjukkan penggunaan pola requirements

perangkat lunak pada aktivitas rekayasa requirements 2014 5. Withall,Stephen

[472] Ide Software Requirement Pattern 2007

6. Yang,Jingwei, and Liu,Lin [473]

Penggunaan pendekatan semi formal seperti Problem Frames (PF) dan i* untuk merepresentasikan,

mengorganisasikan, dan menganalisis pola-pola pengetahuan requirements berulang.

2008

7.

Zamzami, Elviawaty M, Budiardjo,Eko K., and

Suhartanto,Heru [475]

Sebuah metode R3 (Requirements Recovery &

Reconstruction) untuk memperoleh dan

merekonstruksi requirements dari perangkat lunak (aplikasi) sistem informasi

2013

Penelitian ini merupakan kesinambungan penelitian sebelumnya yang telah dilakukan oleh peneliti/penulis.

Pada penelitian sebelumnya telah diperoleh sebuah metode R3 (Requirements Recovery and Reconstruction). Metode R3 ditujukan untuk memperoleh kembali requirements dari perangkat lunak jadi (existing software) berbasis pada End-to- End interaction. End-to-End interaction merupakan pasangan aksi pengguna dan respon perangkat lunak untuk mencapai sebuah goal. Interaksi diinisiasi oleh pengguna.

Penelitian ini juga akan menggunakan beberapa template ontologi yang telah dibangun pada penelitian sebelumnya. Template ontologi yang digunakan adalah:

a. Ontologi WIMP-UI (WindowIconMenuPointer – User Interface), ontologi ini ditujukan untuk merepresentasikan antarmuka pengguna (user interface) dengan style interaksi WIMP (Window, Icon, Menu, dan Pointer) [474].

b. Ontologi USI (User Software Interaction), ontologi yang merepresentasikan interaksi antara pengguna dan

(4)

perangkat keras.

c. Ontologi R2UC (Requirements Representation with Use Case), sebagai ‘dokumen’ SRS.

Pada penelitian ini, pola requirements yang dikembangkan bersumber dari functional requirements yang telah diimplementasikan pada perangkat lunak sistem informasi. Functional requirements adalah fungsi-fungsi dan fitur-fitur [471]. Fitur (feature) merupakan perilaku yang dapat diobservasi. Fitur memuat keinginan dan perilaku tertentu. Fitur perangkat lunak akan melibatkan pengguna, interaksi, dan antarmuka. Dengan demikian, penelitian ini akan melibatkan banyak pelaku eksperimen (observer) yang mengobservasi pengguna, interaksi, dan antarmuka untuk mengembangkan pola requirements.

Pola requirements adalah sebuah pendekatan untuk menentukan tipe tertentu dari requirements [472]. Penelitian Withall mengelompokkan pola-pola requirements menjadi 8 pola seperti pada Gambar 94.

Gambar 94. Pola-pola requirements perangkat lunak [472].

Setiap pola menentukan informasi apa yang harus dikumpulkan untuk menjadi requirements tertentu dan hal apa yang tidak. Terdapat studi bahwa requirements menjadi salah satu faktor resiko penting dalam kegagalan proyek [463]. Usaha perbaikan requirements memerlukan biaya dan waktu tambahan terhadap pengembangan perangkat lunak.

Untuk melakukan elisitasi requirements secara efisien, memvalidasi dan mendokumenkan requirements telah diusulkan peneliti lainnya dengan cara penggunaan ulang requirements. Penggunaan ulang requirements merupakan konsep mengambil requirements dari proyek sebelumnya dan digunakan pada proyek baru [465]. Mengacu pada kelompok pola requirements hasil penelitian Withall, maka pada penelitian ini akan melakukan pembangunan fundamental requirement pattern.

4. Simpulan

Dari penelitian awal yang telah dilakukan maka dapat diambil beberapa simpulan berikut:

a. Metode R3 (Requirements Recovery and Reconstruction Method) dapat digunakan untuk pengembangan pola requirements perangkat lunak pendukung sistem.

(5)

b. Pola requirements yang dikembangkan termasuk kelompok fundamental requirement pattern dengan melibatkan interaksi, antarmuka pengguna, dan dokumen requirements jika ada.

c. Pengembangan pola requirements ini membutuhkan beberapa perangkat lunak sistem informasi sejenis pada sebuah ranah permasalahan.

d. Pola requirements bersumber dari perangkat lunak sistem informasi yang banyak menyediakan interaksi antara pengguna dan perangkat lunak.

Daftar Pustaka

[462] Andriyani,Yanti, Software Requirement Specification Pattern Pada Aplikasi Sistem Informasi Registrasi Akademik, Jurnal Generic, Vol. 6, No. 2, Juli 2011, 2011.

[463] Arnuphaptrairong,Tharwon, Top Ten Lists of Software Project Risks : Evidence from the Literature Survey, Proceedings of the International Multi Conference of Engineers and Computer Scientists 2011, Vol I, 2011, pp 732- 737.

[464] Budiardjo,Eko K. (2009), The Structure of Software Requirement Specification Patterns: UML Based Template, The 2009 International Conference On Advanced Computer Science And Information System (ICACSIS 2009).

[465] Goldin,Leah, and Berry,Daniel M. (2013), Reuse of requirements reduced time to market at one industrial shop: a case study, Requirement Eng, Springer, Sept 2013.

[466] Hoffmann,Axel, et al. (2012), Towards Trust-Based Software Requirement Patterns, Second International Workshop on Requirements Patterns (RePa' 12), IEEE

[467] IEEE, IEEE Standard Glossary of Software Engineering Terminology, lEEE Std 610.121990, http://ieeexplore.ieee.org/, 1990.

[468] Kotonya,Gerald and Sommerville,Ian, Requirements Engineering: Processes and Techniques, John Wiley &

Sons Ltd, 1998.

[469] Leffingwell,Dean, and Widrig,Don, Managing Software Requirements, Addison Wesley, 1999.

[470] Palomares,Cristina (2014), Definition and Use of Software Requirement Patterns in Requirements Engineering Activities, Proceedings: REFSQ Workshops 2014.

[471] Pressman,Roger S. (2005), Software Engineering: A Practitioner’s Approach, Sixth Edition, McGraw-Hill.

[472] Withall,Stephen, Software Requirement Patterns, Microsoft Press, 2007.

[473] Yang,Jingwei, and Liu,Lin (2008), Modelling Requirements Patterns with a Goal and PF Integrated Analysis Approach, Conference: Computer Software and Applications, 2008. COMPSAC '08. 32nd Annual IEEE International.

[474] Zamzami,Elviawaty M, and Budiardjo,Eko K. (2012), Capturing Semantic Meaning on User Interface Presence By Creating Its Ontology, IJCSI International Journal of Computer Science Issue, Vol.9, Issue 4, No 1, July 2012, pp.

6-12.

[475] Zamzami,Elviawaty M.Zamzami, Budiardjo,Eko K., Suhartanto,Heru, Requirements Recovery and Reconstruction Method From Existing Information Systems, IJACT International Journal of Advancements in Computing Technology, Volume 5, Number 12, August 2013, pp 55-64.

[476] Zamzami,Elviawaty Muisa, dkk, Pengembangan Pola Requirements Interaksi Pengguna Pada Antarmuka Pengguna Dengan Pendekatan Rekayasa Balik Perangkat Lunak, Usulan Penelitian Unggulan Perguruan Tinggi (Disetujui 2016), Fakultas Ilmu Komputer – Teknologi Informasi Universitas Sumatera Utara, 2015.

Gambar

Gambar 93. Aktifitas penelitian.
Tabel 44: Penelitian terkait.
Gambar 94. Pola-pola requirements perangkat lunak [472].

Referensi

Dokumen terkait

Dieng Djaya, Wonosobo, membuat rancangan sistem informasi manajemen untuk mendukung pengendalian persediaan barang dalam bentuk perangkat lunak komputer.. dengan menampilkan

Berdasarkan hal diatas penulis tertarik untuk mengembangkan sistem yang sedang berjalan saat ini dengan judul “Perangkat Lunak Sistem Informasi Pengendalian

Sistem pendukung keputusan pemilihan proyek perangkat lunak ini menggunakan metode MADM yaitu weighted product dengan mempertimbangkan beberapa kriteria yaitu nilai

xiv INTISARI SISTEM PENDUKUNG KEPUTUSAN MENENTUKAN PEMEGANG PROYEK PERANGKAT LUNAK MENGGUNAKAN METODE ANALYTIC HIERARCHY PROCESS AHP Oleh : VIVI ANGGUN PROVITA INDRIYANI

Requirements Pada tahap ini pengembang sistem memerlukan komunikasi yang bertujuan untuk memahami perangkat lunak yang diharapkan oleh pengguna dan batasan perangkat lunak tersebut..

Metode pengembangan perangkat lunak Agile mengutamakan kepuasan pelanggan dan terbuka terhadap modifikasi selama