Fakultas Ilmu Komputer
1947
Pembangungan Sistem Perubahan Kebutuhan Menggunakan
Improved
Framework
Widya Bayu Wicaksono1, Fajar Pradana2, Bayu Priyambadha3
Program Studi Teknik Informatika, Fakultas Ilmu Komputer, Universitas Brawijaya Email: 1[email protected], 2[email protected], 3[email protected]
Abstrak
Perubahan kebutuhan merupakan suatu hal yang tidak terelakkan pada lingkungan pengembangan perangkat lunak dalam proses rekayasa kebutuhan. Hal ini dapat terjadi karena adanya perubahan permintaan yang diajukan oleh pemangku kepentingan. Seiring berjalannya waktu perubahan kebutuhan menjadi suatu hal yang kompleks pada tahap pengembangan perangkat lunak. Kurangnya komunikasi antara pemangku kepentingan dan pengembang menjadikan perubahan kebutuhan susah untuk dipenuhi secara baik. Dampak yang terjadi karena adanya perubahan kebutuhan juga akan menyebabkan proses, harga, dan jadwal dari pengembangan perangkat lunak terganggu. Pada skripsi ini akan dijelaskan framework dan metode untuk memecahkan masalah tersebut. framework yang dipakai meliputi proses– proses manajemen perubahan kebutuhan. framework tersebut dimulai dengan pengajuan perubahan kebutuhan oleh pemangku kepentingan, yang kemudian dianalisis dan dilakukan voting untuk menentukan apakah perubahan kebutuhan tersebut akan diimplementasikan atau tidak. Beberapa framework sebelumnya yang telah dipakai untuk memecahkan masalah perubahan kebutuhan juga akan dibahas pada skripsi ini. Terdapat juga sebuah metode untuk menghitung dampak yang terjadi apabila terjadi perubahan pada suatu kebutuhan. Metode tersebut menghitung waktu yang dibutuhkan untuk implementasi, harga dari perubahan kebutuhan, dan sisa waktu dari tenggat waktu proyek. Beberapa data juga diambil untuk menguatkan masalah yang terjadi pada tahap perubahan kebutuhan. Data-data tersebut diambil dari perusahaan pengembangan perangkat lunak Inagata Technosmith yang ada di kota Malang.
Kata kunci: pengembangan perangkat lunak, rekayasa kebutuhan, manajemen perubahan kebutuhan
Abstract
Requirement change is an inevitable in software development activity. It can happen when stakeholders change their requirements. By the time requirements change becomes more complicated in software development. Requirements change are hardly achieved well because the lack of communication among stakeholders and software developer. Requirements change impact can affect process, cost, and schedule of software development. In this research a mehod and framework will be explained to resolve this problem. The framework includes all the process that required in requirement change management. The framework start with stakeholder write down what their needs, then analyzed, and finally some vote will be done to determine wether requirement change is worth to be implemented or not. Past research used to solve this problem will be explained too.There is also a method to count impact occurred when requirement change will be implemented. This method count time to implement, cost, and time left before the deadline come. Some data taken to support this problem in requirement change. The data is taken from Inagata Technosmith Software house in Malang city.
Keywords: software development, requirement engineering, requirement change management
1. PENDAHULUAN
Requirement Change Management (RCM) merupakan proses untuk menafsirkan, mengelola, menganalisis, melacak, dan mendokumentasi perubahan pada kebutuhan
terpenuhi, maka pemangku kepentingan tidak akan mendapatkan perangkat lunak yang mereka butuhkan (Westfall, 2005). Perubahan kebutuhan merupakan salah satu faktor terbesar dalam kegagalan perangkat lunak karena mempengaruhi dana, kualitas, dan jadwal dari pengembangan perangkat lunak (Ali, 2015).
RCM menjadi lebih susah untuk dilakukan pada lingkungan projek terdistribusi karena susahnya komunikasi antara pengembang dengan pemangku kepentingan (Minhas, 2014). Kurangnya manajemen terhadap perubahan kebutuhan membuat peluang kegagalan dalam pengembangan perangkat lunak semakin besar (Minhas, 2014). Pertemuan antara pengembang dengan pemangku kepentingan juga terkadang susah untuk dilakukan, padahal RCM merupakan proses kolaborasi yang intensif pada lingkungan terdistribusi (Minhas, 2014). RCM sangatlah penting untuk dapat sukses membangun perangkat lunak yang diinginkan oleh pemangku kepentingan (Minhas, 2014). Kesalahan analisis kebutuhan pada proses RCM dapat menghabiskan 70 sampai 85 persen dari biaya pengerjaan ulang proyek perangkat lunak (Wiegers, 2003).
Beberapa penelitian telah dilakukan sebelumnya untuk memecahkan masalah pada RCM. Seperti pada penelitian Lai, dkk (2013)
yang mengajukan pemecahan masalah
kebutuhan dengan membuat repository untuk RCM pada lingkungan global. Penelitian lain dari Sultana, dkk (2012) mengajukan framework untuk RCM pada lingkup global. Framework tersebut menggunakan repository utama untuk berbagi informasi tentang kebutuhan, agar masalah RCM dapat terselesaikan. Khan, dkk (2012) mengajukan framework untuk mengatasi masalah komunikasi yang ada selama RCM pada lingkup global. Framework ini meliputi aktifitas perubahan inisiasi, evaluasi, dan implementasi.
Penelitian-penelitian tersebut masih belum mencakup semua yang dibutuhkan untuk memecahkan masalah pada RCM. Semua elemen-elemen seperti komunikasi, koordinasi, dan kontrol belum dicakup semua oleh
penelitian sebelumnya. Berdasarkan
permasalahan dan penelitian sebelumnya maka penulis melakukan penelitian dengan judul Pembangunan Sistem Perubahan Kebutuhan Menggunakan Improved Framework. Metode improved framework diajukan oleh Minhas, dkk (2014) untuk membenahi framework manajemen perubahan kebutuhan yang sudah ada karena terdapat kekurangan pada sisi komunikasi,
koordinasi, dan kontrol. Metode Improved Framework dipakai pada sistem ini karena metode ini yang mencakup semua elemen seperti komunikasi, koordinasi, dan kontrol yang dibutuhkan untuk RCM pada sisi rekayasa kebutuhan (Minhas, 2014). Sistem ini menerapkan seluruh alur yang ada pada metode improved framework. Sistem ini diharapkan dapat memecahkan masalah yang ada pada proses RCM dan membantu analis serta Change Control Board (CCB) dalam menganalisis maupun memutuskan perubahan kebutuhan yang diajukan oleh pemangku kepentingan.
2. LANDASAN KEPUSTAKAAN
2.1 Improved Framework
Gambar 1. Improved Framework untuk global software development
Notifikasi diberikan pada semua member CCB, Untuk dilakukan voting pada hasil evaluasi. Batas waktu diberikan pada CCB melalui sistem secara otomatis. Hasil voting didapatkan dari semua member CCB, untuk menentukan setuju atau tidak setuju mengimplementasikan perubahan. Keputusan tentang persetujuan atau penolakan perubahan diputuskan dari hasil voting yang telah diberikan kepada semua member CCB. Jika semua member setuju pada hasil keputusan, perubahan dinyatakan diterima dan disetujui untuk kemudian diimplementasikan atau tidak. Hasil final dari keputusan CCB kemudian disimpan pada basis data RCM.
Komunikasi pada framework ini dilakukan pada setiap kebutuhan yang ada. Setelah analis melakukan analisis terhadap sebuah kebutuhan, maka terdapat tombol untuk mengirim kepada CCB. Tombol tersebut akan mengirimkan email kepada setiap CCB yang ada pada proyek dipilih. Koordinasi pada framework ini terletak pada penentuan jumlah pengembang yang akan mengerjakan perubahan kebutuhan. Saat analis menganalisis perubahan kebutuhan, maka terdapat kolom untuk menentukan jumlah pengembang yang akan mengerjakan perubahan kebutuhan tersebut.
Kontrol pada framework ini terdapat pada sinkronisasi antara kode yang ditulis oleh pengembang dengan dampak dari perubahan kebutuhan yang akan ditulis oleh analis. Kode
yang ditulis oleh pengembang akan diunggah ke dalam sistem untuk nantinya menjadi bahan analis menentukan jumlah baris kode per function point. Dokumen analisis juga akan diunggah untuk menentukan jumlah file, query, tabel pada basis data, masukan dari pengguna, dan dokumentasi.
2.2 Method of Requirement Change Management
Metode yang diajukan oleh Ali (2015) dibagi menjadi 3 tahap yaitu: memahami perubahan, melakukan analisis terhadap perubahan, dan proses finalisasi. Namun yang dipakai pada penelitian ini hanyalah tahap analisis terhadap perubahan Ali (2015) memberikan persamaan untuk menghitung perkiraan waktu yang diperlukan untuk menyelesaikan pengembangan perangkat lunak. Berikut adalah persamaan yang di usulkan:
n FPs factor Nw
E (1)
E = Perkiraan waktu pengembangan (jam) Nw = Waktu pengerjaan dalam sehari
factors = Baris kode pada perangkat lunak per function point
FP = Function Point
n = Jumlah baris kode per hari
Nw E
TR
(2)
TR = Waktu untuk implementasi perubahan E = Perkiraan waktu pengembangan Nw = Waktu pengerjaan dalam sehari
2.3 Function Point
perangkat lunak setiap modul, yaitu: Number of inputs to the application (I), Number of outputs (O), Number of user inquiries (Q), Number of files used (F), Number of external interfaces (X).
Tabel 1. TabelWeighting Factor
Penghitungan FP menggunakan weighting factors yang setiap aspek merefleksikan kesulitan untuk diimplementasikan. Koefisien ini bervariasi bergantung pada kesulitan implementasinya. Untuk menghitung FP adalah sebagai berikut: Q = Number of user inquiries F = Number of files
X = Number of external interfaces WF = Weighting Factor value
2.4 First Time Yield
First Time Yield merupakan pembagian antara hasil jumlah unit yang bagus dengan jumlah unit yang masuk kedalam proses (Raju, 2013). FP dapat diaplikasikan kepada tahap kebutuhan dalam lingkup pengembangan
perangkat lunak. Dalam perspektif
pengembangan perangkat lunak, First Time Yield dapat didefinisikan sebagai jumlah FP yang sukses terpenuhi dibagi dengan jumlahFPyang direncanakan pada iterasi tersebut. Persamaan 4 adalah persamaan yang diajukan.
Yn = Nilai function point sesuai banyak iterasi
3. METODOLOGI PENELITIAN
Pada bab ini dijelaskan langkah – langkah yang akan dilakukan dalam perancangan, implementasi, dan pengujian dari aplikasi perangkat lunak yang akan dibuat terlihat pada Gambar 2 secara diagram alur. Kesimpulan dan saran disertakan sebagai catatan atas aplikasi dan kemungkinan arah pengembangan aplikasi selanjutnya.
Gambar 2. Diagram alir metode penelitian
4. ANALISIS KEBUTUHAN
4.1 Kebutuhan Fungsional
Kebutuhan fungsional merupakan
kebutuhan utama yang dibutuhkan dari sebuah sistem. Sistem perubahan kebutuhan menggunakan improved framework memiliki kebutuhan fungsional sebagai berikut:
Tabel 2. Tabelkebutuhan fungsional
ID Kebutuhan
F.01 Sistem harus dapat memisahkan hak akses antar pengguna.
F.02 Sistem harus dapat menyimpan
kebutuhan yang didefinisikan oleh analis. F.03 Sistem harus dapat menampilkan semua
kebutuhan yang sudah disimpan kedalam sistem.
F.04 Sistem harus dapat menyediakan sarana untuk mengubah kebutuhan yang sudah ada didalam sistem.
F.05 Sistem harus dapat menyediakan sarana untuk menghapus kebutuhan yang sudah ada didalam sistem.
F.06 Sistem harus dapat menyimpan pengajuan perubahan kebutuhan yang diajukan pemangku kepentingan. F.07 Sistem harus dapat menampilkan semua
perubahan yang diajukan oleh pemangku kepentingan.
F.08 Sistem harus dapat menyediakan form
analisis perubahan kebutuhan yang dapat
Parameter Simple Average Complex
Number of
Number of user inquiries
3 4 6
menghitung hari dan harga dari perubahan.
F.09 Sistem harus dapat melakukan
otomatisasi penentuan jangka waktu bagi CCB untuk melakukan voting.
F.10 Sistem harus dapat menampilkan daftar kebutuhan yang diubah bagi CCB. F.11 Sistem harus dapat menyediakan kolom
pilihan untuk CCB melakukan voting
perubahan kebutuhan.
F.12 Sistem harus dapat menyimpan pengguna baru kedalam sistem.
F.13 Sistem harus dapat menyediakan sarana untuk pengguna keluar dari sistem. F.14 Sistem harus dapat menampung dokumen
yang diunggah oleh analis dan pengembang.
F.15 Sistem harus dapat mengirimkan email kepada CCB apabila ada perubahan kebutuhan baru yang sudah dikirim oleh analis.
F.16 Sistem harus dapat menumpuk kebutuhan yang telah disetujui oleh semua CCB. F.17 Sistem harus dapat menyediakan halaman
detil perubahan kebutuhan yang lengkap dengan dampak pada kebutuhan lainnya. F.18 Sistem harus dapat menyimpan
konfigurasi proyek yang dibuat dan didefinisikan oleh analis.
F.19 Sistem harus dapat menyimpan konfigurasi proyek apabila dilakukan perubahan oleh analis.
F.20 Sistem harus dapat menghapus proyek yang ada didalam sistem.
F.21 Sistem harus dapat menyediakan sarana untuk admin mengubah pengguna yang ada didalam sistem.
F.22 Sistem harus dapat menyediakan sarana untuk admin menghapus pengguna yang ada didalam sistem.
F.23 Sistem harus dapat mengirimkan email kepada pemangku kepentingan ketika keputusan perubahan kebutuhan telah dilakukan.
4.2 Kebutuhan Non Fungsional
Tabel 3 merupakan kebutuhan non fungsional yang ada dalam sistem. Terdapat kebtuhan non fungsional portability dan security yang nantinya ada didalam sistem. Kebutuhan non fungsional didapatkan dari pengumpulan data pada perusahaan Inagata Technosmith. Kebutuhan non fungsional dibutuhkan untuk menunjang sistem perubahan kebutuhan menggunakan improved framework, apabila kebutuhan non fungsional tidak didefinisikan maka sistem yang dibuat tidak akan berguna.
Tabel 3. Tabelkebutuhan non fungsional
ID Parameter Deskripsi
NF.01 Compatibility Sistem dapat diakses diberbagai jenis browser
seperti Mozilla firefox, Google chrome, dan Microsoft edge NF.02 Security Sistem menggunakan
enkripsi md5 untuk mengenkripsi password
yang ada didalam
database
5. PERANCANGAN DAN
IMPLEMENTASI
5.1 Perancangan Algoritme
Pada bagian perancangan algoritme ini akan dijelaskan algoritme yang dipakai untuk membangun sistem perubahan kebutuhan menggunakan improved framework.
Tabel 4. Pseudocode menentukan dampak kebutuhan
Int entry_screens, external files, reports, queries, database_tables, code_per_fp, es_wf, ef_wf, r_wf, q_wf, dt_wf, jumlah_pekerja, waktu_kerja_perhari,
jumlah_kode_perhari, harga_perjam, deadline_proyek, functional_points, expected_hours, time_to_implement, time_acceptance, total_cost;
functional_points = (entry_screens * es_wf) + (external_files * ef_wf) + (reports * r_wf) + (queries * q_wf) + (database_tables * dt_wf);
expected_hours = waktu_kerja_perhari * (code_per_fp * functional_points / jumlah_kode_perhari);
time_to_implement = (expected_hours / waktu_kerja_perhari) /
jumlah_pekerja;
time_acceptance = deadline_proyek - time_to_implement;
total_cost = expected_hours * harga_perjam;
Tabel 5 merupakan pseudocode untuk menentukan jumlah rework yang dibutuhkan. Pseudocode ini menentukan jumlah First Time Yield yang dibutuhkan untuk perubahan kebutuhan serta menentukan jumlah rework yang dibutuhkan. Hasil dari perhitungan ini adalah dalam bentuk persen.
Tabel 5. Pseudocode menentukan rework yang dibutuhkan
1 Fty = (function_points /
planned_function_points) * 100 Rework = 100 - ((function_points / planned_function_points) * 100)
5.2 Implementasi
Gambar 3 merupakan halaman fitur menganalisis perubahan kebutuhan. Pada halaman ini analis disediakan dokumen pendukung untuk kebutuhan yang akan dirubah, permintaan perubahan dari pemangku kepentingan dan perkiraan dampak perubahan kebutuhan.
Gambar 4 merupakan halaman fitur melihat detil perubahan. Fitur ini dapat diakses oleh CCB atau analis untuk melihat kebutuhan yang diminta oleh pemangku kepentingan dan hasil Analisis dari analis.
Gambar 3. Fitur menganalisis perubahan kebutuhan
Gambar 4. Fitur melihat detil perubahan
Gambar 5. Fitur melihat daftar analisis perubahan kebutuhan
6. PENGUJIAN
6.1 Pengujian white box
Pengujian white box dilakukan dengan pengujian basis path pengujian dilakukan pada fitur melihat detil perubahan. Operasi-operasi
yang akan diuji adalah
cekPersetujuanImplementasi(),
cekPengirimanCCB(), dan cekPersetujuan(). Operasi cekPersetujuanImplementasi adalah untuk mengetahui status perubahan kebutuhan. Operasi cekPengirimanCCB adalah untuk status perubahan kebutuhan telah dikirim ke CCB atau belum dan untuk mengetahui apakah perubahan kebutuhan ditolak atau diterima oleh CCB. Sedangkan operasi cekPersetujuan adalah untuk mengetahui apakah CCB yang sedang masuk kedalam sistem telah melakukan voting atau belum pada suatu perubahan kebutuhan.
Pengujian tersebut menghasilkan 6 cyclomatic complexity pada operasi
cekPersetujuanImplementasi dan
cekPersetujuan serta menghasilkan 5 cyclomatic complexity pada operasi cekPengirimanCCB. Pengujian pada masing-masing jalur telah dilakukan dan menghasilkan status yang valid pada setiap jalur.
6.2 Pengujian black box
Dari 22 pengujian fungsional yang telah dilakukan yaitu pengujian login, pengujian logout, pengujian melihat daftar perubahan kebutuhan sudah dianalisis, pengujian melihat daftar perubahan kebutuhan, pengujian melihat kebutuhan, pengujian menambahkan pengguna, pengujian mendapatkan waktu voting, pengujian mengajukan perubahan kebutuhan, pengujian
menganalisis kebutuhan, pengujian
menambah dokumen, pengujian menambah proyek, pengujian menerima email keputusan, pengujian menerima email perubahan kebutuhan, pengujian menghapus pengguna, pengujian menghapus proyek, pengujian mengubah pengguna, pengujian mengubah proyek, pengujian menumpuk kebutuhan. Semua pengujian tersebut menghasilkan status yang valid, sehingga pengujian fungsional sistem dinyatakan berhasil dengan tingkat keberhasilan sebesar 100%.
Pengujian terhadap portability dan security yang ada pada kebutuhan non fungsional sistem telah dilakukan dan semuanya mendapatkan hasil yang valid. Sehingga pengujian terhadap non fungsional sistem dinyatakan berhasil dengan tingkat keberhasilan 100%.
7. KESIMPULAN
. Pembangunan sistem perubahan kebutuhan
menggunakan improved framework
menggunakan framework CodeIgniter dan
Bahasa pemrograman PHP. Bahasa
pemrograman php digunakan untuk tahap pengerjaan kode dan framework CodeIgniter untuk kemudahan pengerjaan sistem.
Sedangkan untuk pengujiannya
menggunakan white box dan black box. 2. Dari 3 pengujian white box yang dilakukan
semuanya menghasilkan status yang valid. Kemudian untuk pengujian black box kebutuhan fungsional, dari 22 pengujian didapatkan 22 status yang valid. Sedangkan untuk 3 pengujian black box kebutuhan non fungsional didapatkan 3 pengujiannya valid. Sehingga dapat disimpulkan bahwa pengujian white box dan black box sistem memiliki tingkat keberhasilan sebesar 100%. 3. Pada sistem perubahan kebutuhan
menggunakan improved framework, analisis perubahan kebutuhannya dapat menghitung harga, waktu untuk implementasi, dan dampak pada dokumen maupun kebutuhan lainnya. Sedangkan untuk implementasi perubahan kebutuhan, hasil analisis perubahan kebutuhan harus disetujui oleh semua CCB. Jika ada salah satu CCB yang melakukan penolakan maka perubahan
kebutuhan tersebut tidak akan
diimplementasikan. Hal ini dapat membantu dalam proses perubahan kebutuhan pada lingkup pengembangan perangkat lunak.
DAFTAR PUSTAKA
Ali, N., & Lai, R. (2016). A method of requirements change management for global software. Information and Software Technology, 70, 49–67.
Khan, A., Basri, S., Dominic, P., & Amin, F. (2012). A Propose Framework for Requirement Change Management in
Global Software Development.
International Conference on Computer & Information Science (ICCIS), 944-947.
Lai, R., & Ali, N. (2013). Requirements Management Method for Global Software Development. Advances in Information Science, 38-58.
Minhas, N., Qurat-ul-Ain, Zafar-ul-Islam, & A., Z. (2014). An Improved Framework for Requirement Change Management in Global Software Development. Journal of Software Engineering and Applications, 7, 779-790.
Raju, H., & Krishnegowda, Y. (2013). Software Sizing and Productivity with Function Points, Vol. 1, No. 2. Lecture Notes on Software Engineering.
Sultana, R., Fahad, J., Ahmad, M., & Ahmad, A. (2012). Empirical and Qualitative Studies by Analyzing Requirement in Global Software Development (GSD). International Journal of Management, IT and Engineering, 1-18.
