Pembangungan Sistem Perubahan Kebutuhan Menggunakan Improved Framework

  Vol. 2, No. 5, Mei 2018, hlm. 1947-1953 http://j-ptiik.ub.ac.id

  

Pembangungan Sistem Perubahan Kebutuhan Menggunakan Improved

₁ Framework _{2 3} Widya Bayu Wicaksono , Fajar Pradana , Bayu Priyambadha

  Program Studi Teknik Informatika, Fakultas Ilmu Komputer, Universitas Brawijaya _{1 2 3} Email: widyabayuwicaksono@gmail.com, fajar.p@ub.ac.id, bayu_priyambadha@ub.ac.id

  

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.

  (Minhas, 2014). Hal ini dibutuhkan untuk

   PENDAHULUAN

  memenuhi perubahan permintaan dari

  Requirement Change Management (RCM)

  pemangku kepentingan agar perangkat lunak merupakan proses untuk menafsirkan, yang dibuat dapat memenuhi kebutuhan yang mengelola, menganalisis, melacak, dan diminta. Apabila ada kebutuhan yang tidak mendokumentasi perubahan pada kebutuhan

  Fakultas Ilmu Komputer Universitas Brawijaya

1947 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 Framework ini telah diajukan oleh (Minhas,

  2014). untuk memecahkan masalah RCM pada lingkungan global. Seperti pada Gambar 1 fase inisiasi perubahan kebutuhan diambil dari beberapa pemangku kepentingan. Perubahan diterima pada Change Request Form (CRF). CRF berisikan tentang informasi berkaitan dengan permintaan pengubahan, detail kontak lengkap dari pencetus dan detail lengkap tentang permintaan pengubahan. Setelah CRF diisi, kemudian akan disimpan pada basis data RCM untuk kemudian diproses lebih lanjut. Langkah selanjutnya adalah analisis perubahan oleh analis yang dibantu dengan repositori kebutuhan berisikan informasi terkait kebutuhan sistem. Analisis dilakukan untuk menentukan harga, waktu, dan pemanfaatan sumber daya oleh analis kebutuhan. Hasil evaluasi kemudian disimpan pada basis data RCM. 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

         

  2.3 Function Point

   (2) T R = Waktu untuk implementasi perubahan E = Perkiraan waktu pengembangan Nw = Waktu pengerjaan dalam sehari

  Nw E T _R

  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 (1)

       n FPs factor

   

  member setuju pada hasil keputusan, perubahan

  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:

  2.2 Method of Requirement Change Management

  . Dokumen analisis juga akan diunggah untuk menentukan jumlah file, query, tabel pada basis data, masukan dari pengguna, dan dokumentasi.

  function point

  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

  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.

  dinyatakan diterima dan disetujui untuk kemudian diimplementasikan atau tidak. Hasil final dari keputusan CCB kemudian disimpan pada basis data RCM.

  Function points (FP) pertama kali diperkenalkan tahun 1970 an sebagai alternatif dalam menghitung jumlah baris yang sederhana berbasis metrik. Dasar dari FPs adalah dengan bertambah kuatnya suatu bahasa pemrograman di kembangkan, maka jumlah baris kode akan bertambah dan membuat fungsi-fungsinya kompleks (Raju, 2013). Bagaimanapun perhitungan harga per baris kode menunjukkan penurunan disisi produktivitas, karena harga pengembangan perangkat lunak tidak akan berubah. Pemecahannya adalah dengan menghitung fungsionalitas perangkat lunak menggunakan jumlah antarmuka antara modul dan sub sistem dalam program atau sistem. Keuntungan dari menggunakan FP metrik adalah dapat dihitung sebelum tahap implementasi dilakukan. Pada FP terdapat 5 karakteristik

• – 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.

  5

  3. METODOLOGI PENELITIAN

  Parameter Simple Average Complex Number of inputs

  3

  4

  6 Number of outputs

  4

  7 Number of user inquiries

  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).

  3

  4

  6 Number of files used

  7

  10

  Tabel 1. Tabel Weighting Factor

  Pada bab ini dijelaskan langkah

15 Number of

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:

  10

  7

  5

  external interfaces

  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:

  ) ( ) ( ) ( ) ( ) ( WF

  X WF F WF Q WF O WF

  I FP          

  (3) I = Number of inputs O = Number of outputs Q = Number of user inquiries F = Number of files X = Number of external interfaces WF = Weighting Factor value

  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. _n Y Y FTY    ... ₁

  (4) FTY = First Time Yield Yn = Nilai function point sesuai banyak iterasi

  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

  Gambar 2. Diagram alir metode penelitian 4.

  Tabel 2. Tabel kebutuhan fungsional

  ID Kebutuhan F.01 Sistem harus dapat memisahkan hak akses antar pengguna.

2.4 First Time Yield

PERANCANGAN DAN

  22

  14

  15

  16

  17

  18

  19

  20

  21

  23

  menghitung hari dan harga dari perubahan. F.09 Sistem harus dapat melakukan otomatisasi penentuan jangka waktu bagi

  24

  25

  26

  27

  28 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

  Tabel 4 merupakan pseudocode untuk menentukan dampak perubahan kebutuhan.

  Pseudocode ini dimulai dengan menghitung function points dari kebutuhan yang akan

  diubah, kemudian menghitung perkiraan waktu yang dibutuhkan untuk mengimplementasi perubahan (dalam jam). Setelah itu akan dihitung waktu yang dibutuhkan dalam hari, waktu yang tersisa dan total harga perubahan kebutuhan.

  13

  12

  11

  10

  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.

  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. Tabel kebutuhan 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.

  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

  1

  2

  3

  4

  5

  6

  7

  8

  9

• (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;

4.2 Kebutuhan Non Fungsional

  Tabel 5 merupakan pseudocode untuk menentukan jumlah rework yang dibutuhkan.

  Pseudocode ini menentukan jumlah First Time

  yang dibutuhkan untuk perubahan

  Yield

  kebutuhan serta menentukan jumlah rework yang dibutuhkan. Hasil dari perhitungan ini adalah dalam bentuk persen.

  Tabel 5. Pseudocode menentukan rework yang dibutuhkan Gambar 5. Fitur melihat daftar analisis perubahan

1 Fty = (function_points /

  kebutuhan planned_function_points) * 100 Rework = 100 - ((function_points / planned_function_points) * 100) 6.

   PENGUJIAN

5.2 Implementasi

  6.1 Pengujian white box

  Gambar 3 merupakan halaman fitur Pengujian white box dilakukan dengan menganalisis perubahan kebutuhan. Pada pengujian basis path pengujian dilakukan pada halaman ini analis disediakan dokumen fitur melihat detil perubahan. Operasi-operasi pendukung untuk kebutuhan yang akan dirubah, yang akan diuji adalah permintaan perubahan dari pemangku cekPersetujuanImplementasi(), kepentingan dan perkiraan dampak perubahan cekPengirimanCCB(), dan cekPersetujuan(). kebutuhan.

  Operasi cekPersetujuanImplementasi adalah Gambar 4 merupakan halaman fitur melihat untuk mengetahui status perubahan kebutuhan. detil perubahan. Fitur ini dapat diakses oleh

  Operasi cekPengirimanCCB adalah untuk status CCB atau analis untuk melihat kebutuhan yang perubahan kebutuhan telah dikirim ke CCB atau diminta oleh pemangku kepentingan dan hasil belum dan untuk mengetahui apakah perubahan Analisis dari analis. 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

  Gambar 3. Fitur menganalisis perubahan kebutuhan

  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,

  Gambar 4. Fitur melihat detil perubahan pengujian mendapatkan waktu voting, pengujian

  mengajukan perubahan kebutuhan, pengujian menganalisis kebutuhan, pengujian menganalisis perubahan kebutuhan, pengujian menghapus kebutuhan, pengujian mengubah kebutuhan, pengujian melakukan voting, pengujian melihat detil perubahan, pengujian

DAFTAR PUSTAKA

  Ali, N., & Lai, R. (2016). A method of requirements change management for global software.

  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%.

  Information and Software Technology, 70 , 49

• –67. Khan, A., Basri, S., Dominic, P., & Amin, F.

  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%.

  of Software Engineering and Applications, 7 , 779-790.

  Westfall, L. (2005). Software Requirements Engineering: What, Why, Who, When, and How.

  International Journal of Management, IT and Engineering , 1-18.

  (2012). Empirical and Qualitative Studies by Analyzing Requirement in Global Software Development (GSD).

  Sultana, R., Fahad, J., Ahmad, M., & Ahmad, A.

  Raju, H., & Krishnegowda, Y. (2013). Software Sizing and Productivity with Function Points, Vol. 1, No. 2. Lecture Notes on Software Engineering.

  Minhas, N., Qurat-ul-Ain, Zafar-ul-Islam, & A., Z. (2014). An Improved Framework for Requirement Change Management in Global Software Development. Journal

  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.

  Management Method for Global Software Development. Advances in Information Science , 38-58.

  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%.

  International Conference on Computer & Information Science (ICCIS) , 944-

  (2012). A Propose Framework for Requirement Change Management in Global Software Development.

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.

  947. Lai, R., & Ali, N. (2013). Requirements