KAKAS BANTU ANALISIS KERANCUAN KEBUTUHAN PERANGKAT LUNAK BERBASIS ATURAN

KAKAS BANTU ANALISIS KERANCUAN KEBUTUHAN PERANGKAT LUNAK BERBASIS ATURAN

Yunata Dede Pratiwi

¹

, Daniel Oranova S

²

, Sarwosri

³

1,2,3

Jurusan Teknik Informatika, Fakultas Teknologi Informasi, Institut Teknologi Sepuluh Nopember

Kampus ITS Sukolilo Surabaya, 60111, Indonesia

1

ata_chan@cs.its.ac.id,

²

daniel@if.its.ac.id,

³

sri@cs.its.ac.id

Abstrak

Analisis kebutuhan adalah fase yang penting dalam pengembangan sebuah perangkat lunak.

Otomatisasi evaluasi terhadap bahasa alamiah yang digunakan dalam dokumen kebutuhan telah ditetapkan untuk meningkatkan kualitas dari sebuah sistem sebelum memulai fase pembangunan sistem.

Kakas Bantu Analisis Kerancuan Kebutuhan Perangkat Lunak Berbasis Aturan ini adalah suatu kakas bantu yang dapat membantu otomatisasi dalam evaluasi dokumen kebutuhan perangkat lunak. Kakas bantu ini mengekstraksi dokumen kebutuhan perangkat lunak menjadi kebutuhan spesifik. Kakas bantu melakukan analisis kerancuan pada kebutuhan spesifik dan memberikan rekomendasi atas kerancuan yang terjadi didalamnya.

1. Pendahuluan

Tahap awal dari suatu pembangunan sistem perangkat lunak adalah proses analisis kebutuhan sistem. Di tahap awal ini terjadi interaksi antara calon pengguna sistem dan pihak pengembang perangkat lunak, dimana mereka harus memiliki persepsi yang sama atas spesifikasi perangkat lunak yang dibangun.

Kumpulan dari spesifikasi kebutuhan dikumpulkan dalam bentuk Dokumen Spesifikasi Kebutuhan Perangkat Lunak (SKPL). Dokumen SKPL disusun menggunakan bahasa alamiah, yaitu bahasa yang kita gunakan dalam percakapan sehari-hari. Penggunaan bahasa alamiah memiliki kelemahan yaitu pada saat makna dari kalimat tersebut memiliki arti atau penafsiran yang berbeda-beda pada masing- masing orang. Dalam konteks ini, dokumen SKPL dapat ditafsirkan berbeda-beda oleh tim pengembang perangkat lunak. Dengan kata lain, dokumen SKPL tersebut bersifat rancu karena dapat memilki arti yang berbeda-beda. Dokumen SKPL yang bersifat rancu dapat menyebabkan kegagalan dalam pengembangan proyek perangkat lunak karena tujuan proyek tidak tercapai.

Kerancuan dalam sebuah dokumen SKPL disebabkan penggunaan kata yang rancu dalam menyusun kalimat-kalimat kebutuhan.

Untuk itu pada tugas akhir ini dibangun sebuah kakas bantu analisis kerancuan

kebutuhan perangkat lunak berbasis aturan.

Kakas bantu ini dapat membantu tim pengembang perangkat lunak untuk mendeteksi kalimat rancu dalam kebutuhan spesifik sebuah dokumen SKPL beserta pemberian rekomendasi kepada pengguna terhadap kerancuan yang terjadi dalam kalimat tersebut. Kakas bantu ini hanya melayani analisis kerancuan pada dokumen SKPL berbahasa inggris, sesuai dengan format IEEE dan memiliki ekstensi berkas .docx .

2. Tinjauan Pustaka

2.1 Kebutuhan Perangkat Lunak

Kebutuhan perangkat lunak (software requirements) adalah atribut-atribut yang bersifat spesifik yang merupakan spesifikasi kebutuhan fungsional dan kebutuhan non fungsional dari sebuah sistem perangkat lunak.

Kebutuhan perangkat lunak dijabarkan

dalam sebuah dokumen formal yang disebut

dokumen Spesifikasi Kebutuhan Perangkat

Lunak (SKPL). Spesifikasi yang harus

terkandung dalam sebuah dokumen kebutuhan

perangkat lunak antara lain: fungsionalitas,

antarmuka eksternal, performa, atribut dan

batasan perancangan. Gambar 1 menunjukkan

pokok-pokok bahasan dalam sebuah dokumen

SKPL.

Gambar 1. Bahasan Dalam Dokumen SKPL

Pada Tugas Akhir ini, bagian yang akan diekstraksi untuk melakukan analisis kerancuan adalah bagian ”Spesific Requirements” atau Kebutuhan Spesifik dengan format tabel.

Gambar 2 menunjukkan contoh format tabel kebutuhan spesifik yang akan diekstraksi.

Gambar Error! No text of specified style in document..

Format Tabel Kebutuhan Spesifik

Bagian yang diambil untuk diekstraksi adalah pada bagian kolom 2 tabel spesific requirements dimana dalam kolom tersebut terdapat daftar pernyataan kebutuhan.

2.2 Kerancuan Kebutuhan Perangkat Lunak Kerancuan dalam sebuah dokumen SKPL dapat terjadi dalam berbagai bentuk bahasa alamiah. Misalnya saja kita jumpai sebuah pernyataan:

“Design a program that allows a network operator to plan changes in every parameter of every cell in the network. These planned

changes should be verified for consistency and correctness and then applied to the network in the least disturbing way” [3].

Dalam pernyataan diatas, tidak dijelaskan bagaimana sebuah sistem memverifikasi sebuah konsistensi dan kebenaran lalu mengimplementasikannya dalam jaringan tersebut. Sehingga pernyataan ini tidak dapat diimpementasikan dalam rancangan sistem apalagi dibangun menjadi sebuah fungsi dari sistem.

Sehingga dapat kita lihat pentingnya sebuah pernyataan spesifikasi sistem dalam sebuah dokumen SKPL merupakan sebuah dasar yang kuat dalam membangun sebuah sistem.

Kesalahan kecil dalam membuat spesifikasi perangkat lunak dapat berakibat terjadinya kegagalan pengembangan sebuah sistem perangkat lunak.

2.3 Analisis Kerancuan Kebutuhan Perangkat Lunak Berbasis Aturan [2]

Aturan ini dibuat berdasarkan pola-pola kalimat yang dirumuskan berdasarkan aturan SMART Requirement yang dikerjakan pada penelitian sebelumnya [2]. Aturan ini dibangun untuk mendeteksi kerancuan dalam sebuah pernyataan spesifikasi kebutuhan perangkat lunak. Aturan ini mengacu pada sebuah aturan SMART Requirements dengan menggunakan pengolahan bahasa alamiah yang dibantu oleh WordNet. SMART Requirements adalah sebuah akronim yang merepresentasikan lima buah acuan yang menentukan kualitas kebutuhan perangkat lunak:

1. Specific

Pernyataan kebutuhan dikatakan berkualitas jika ia ditulis secara spesifik, yaitu tidak bersifat rancu, konsisten, sederhana, dan tepat.

2. Measurable

Dalam konteks rekayasa kebutuhan, measurable berarti bahwa ketika sistem telah dibangun nantinya, pernyataan kebutuhan harus bisa diverifikasi apakah sudah memenuhi atau belum.

3. Attainable

Attainable bermakna ”berdasarkan teori yang ada apakah sebuah pernyataan kebutuhan dapat dicapai atau tidak?”.

4. Realisable

Dengan sumber daya yang dimiliki saat ini,

”apakah sebuah pernyataan kebutuhan bisa direalisasikan atau tidak?”.

5. Traceable

Traceable bermakna bahwa sebuah pernyataan kebutuhan harus bisa dilacak mulai dari konsep hingga ke desain, implementasi, dan pengujian. Hal ini penting agar bisa diketahui apakah seluruh kebutuhan yang tertulis sudah diimplementasikan atau belum.

Bagian yang menjadi fokus utama dalam Tugas Akhir ini adalah bagian pertama yaitu spesific. Bagian spesific menjelaskan bahwa sebuah sebuah kebutuhan perangkat lunak tidak bersifat rancu.

3 Analisis dan Perancangan

3.1 Deskripsi Umum Perangkat Lunak

Pada Tugas Akhir ini akan dibuat suatu perangkat lunak berbasis aplikasi desktop yang akan membantu pengguna untuk menentukan kerancuan sebuah teks spesifikasi perangkat lunak. Aplikasi ini bekerja pada platform windows. Aplikasi ini membantu pengembang perangkat lunak untuk mengetahui kerancuan dari sebuah dokumen SKPL, dimana tingkat kerancuan dari sebuah teks dapat ditelaah secara pasti, bukan hanya melalui naluri alamiah penguji dokumen SKPL.

Adapun gambaran umum dari aplikasi ini, adalah sebagai berikut:

 Input : bagian tekstual dari dokumen Spesifikasi Kebutuhan Perangkat Lunak.

 Proses : ekstraksi dokumen SKPL untuk mendapatkan pernyataan kebutuhan yang terkandung di dalam bagian kebutuhan spesifik. Setelah proses ekstraksi dokumen dilakukan, pengecekan kalimat utuh akan dilakukan pada kebutuhan spesifik yang telah terekstrakasi. Setelah ditemukan kalimat kebutuhan yang merupakan kalimat utuh dalam bahasa ingrris, kalimat kebutuhan akan mengalami proses penandaan POS oleh pustaka stanford pos tagger. Keluaran dari proses tagging atau penandaan tersebut berupa teks yang telah ditandai berdasarkan

struktur kalimatnya atau POS nya. Lalu proses selanjutnya teks yang telah ditandai tersebut akan diproses oleh modul utama yang berisi aturan-aturan dan logika sistem.

Modul utama mengacu pada dua repositori kata, dua repositori kata itu terdiri repositori kata rancu beserta pos nya untuk mengetahui ada tidaknya penggunaan kata rancu dalam kalimat kebutuhan tersebut, dan juga terdapat repositori sinonim kata dari pustaka WordNet yang akan mendeteksi sinonim dari kata-kata rancu yang terdaftar dalam tabel repositori aturan. Dari pengecekan kata rancu akan dihasilkan apakah kalimat kebutuhan bersifat rancu atau tidak. Apabila ditemukan rancu, maka akan dilakukan proses pemberian rekomendasi pada kalimat rancu.

 Output: berupa informasi apakah pernyataan kebutuhan tersebut bersifat rancu atau tidak.

Dengan keterangan bagian dari kalimat tersebut yang menyebabkan ke rancuan, serta rekomendasi yang bisa digunakan untuk memperbaiki kerancuan tersebut.

3.2 Arsitektur Aplikasi

Arsitektur dari perangkat lunak ini dapat dilihat pada Gambar 3. Sistem ini hanya dapat diakses oleh pengguna dimana sistem terinstalasi. Pengguna dalam kasus ini adalah seorang analis sistem kebutuhan perangkat lunak. Pada Gambar 3 pengguna akan memasukan dokumen SKPL sebagai masukan sebagai sistem untuk mengetahui kerancuan dari dokumen SKPL tersebut.

Analis Kebutuhan Dokumen SKPL Antarmuka Pengguna

Ekstraksi Dokumen SKPL

Analisis Ambiguitas

Pemberian Rekomendasi Cetak Hasil

Ekstraksi Berdasarkan Struktur Kalimat

Deteksi Kalimat Utuh Kebutuhan Spesifik à Pernyataan Kebutuhan

Gambar Error! No text of specified style in document..

Arsitektur Sistem Analisis Kerancuan

Di dalam sistem, dokumen SKPL akan diekstraksi menggunakan bantuan dari pustaka Apache POI. Setelah dilakukan ekstraksi dokumen SKPL, sistem akan mengambil isi dari kebutuhan spesifik. Lalu akan dilanjutkan dengan pengecekan kalimat oleh pustaka openNLP. Setelah itu, kalimat yang berhasil lolos sebagai kalimat utuh, akan mengalami proses pemisahan kalimat berdasarkan strukturnya menggunakan pustaka Stanford Pos Tagger . Setelah kalimat terpecah berdasarkan POS nya, maka akan dilakukan analisis kerancuan dengan menggunakan aturan yang terdaftar dalam sebuah tabel aturan dalam basis data. Sehingga akan diperoleh hasil apakah kalimat tersebut rancu atau tidak. Sehingga dapat ditentukan rekomendasi yang akan diberikan. Dan hasil output akan dicetak dan ditampilkan pada pengguna.

3.3 Spesifikasi Kebutuhan Perangkat Lunak Aplikasi ini memiliki 3 proses utama, yaitu:

1. Proses Ekstraksi Dokumen

Masukan dokumen SKPL yang diproses adalah dokumen dengan ekstensi .docx. Gambar 4 menunjukkan diagram alir ekstraksi dokumen SKPL menjadi kebutuhan spesifik.

Mulai

Baca isi keseluruhan

Dokumen String Paragraf Cek Tabel dan Cek Id

Kebutuhan Spesifik

Format Sesuai IEEE?

Cek Keutuhan Kalimat

Selesai Tampilkan Hasil

Ekstraksi Kalimat Utuh Kebutuhan

Spesifik YA

String Sentence Lokasi

Berkas

Kalimat Utuh?

IYA

Beri Tanda kalimat Tidak

Utuh TIDAK

Gambar 4. Diagram Alir Ekstraksi Dokumen

Dokumen SKPL dengan ekstensi berkas .docx merupakan ekstensi berkas keluaran yang dihasilkan oleh Microsoft Word versi 2007 ke atas. Kebutuhan spesifik dokumen SKPL diperoleh dengan menggunakan pustaka apache POI. Pustaka apache POI akan membaca keseluruhan isi dokumen SKPL. Pembacaan dilakukan secara terurut berdasarkan baris paragrafnya dari awal hingga akhir dokumen.

Sehingga kita dapat menampung isi keseluruhan dari sebuah dokumen SKPL ke dalam sebuah variabel paragraf. Variabel paragraf akan diekstraksi kembali untuk mendapatkan bagian kebutuhan spesifik perangkat lunaknya saja. Id dari kebutuhan spesifik dan format tabel digunakan sebagai penanda kebutuhan spesifik yang akan diekstraksi. Setelah melalui proses ekstraksi, akan dilakukan proses pengecekan kalimat utuh dengan menggunakan pustaka OpenNLP. Pengecekan kalimat utuh dilakukan agar hanya kalimat bahasa Inggris yang utuh yang dapat masuk dalam proses analisis kerancuan.

2. Proses Analisis Kerancuan

Pemisahan kalimat berdasaran struktur kalimatnya atau POS nya dilakukan dengan menggunakan pustaka stanford pos taggers. Digunakan juga pustaka wordNet untuk membantu proses analisis kerancuan dengan menggunakan sinonim.

Pencocokkan aturan yang tepat dilakukan pada tabel aturansmart pada basis data mySql.

Untuk melakukan proses ini string kalimat disimpan dalam sebuah list yang menampung hasil dari proses pemecahan kalimat oleh stanford pos tagger. Proses analisis dimulai dengan mencocokkan masing-masing kata dalam kalimat dengan kata-kata rancu dalam tabel aturan. Jika terjadi kecocokan salah satu kata dengan kata yang tersimpan dalam tabel aturan, maka kalimat tersebut dinilai rancu.

Saat tidak ditemukan kata rancu yang persis sama dengan kata-kata rancu pada tabel aturan, dilakukan penyimpanan pos kalimat yang memiliki pos sama dengan pos kata rancu.

Disinilah pustaka wordNet bekerja untuk

mencari sinonim dari kata-kata rancu yang

terdapat dalam tabel aturan. Gambar 5

menunjukkan diagram alir dari proses

analisiskerancuan dari sistem ini. Pencarian sinonim hanya dilakukan pada kata yang memiliki pos sama dengan kata yang sedang diperiksa. Apabila sinonim ditemukan, maka kalimat tersebut akan dinyatakan rancu.

Mulai

Pemisahan kalimat berdasarkan POS

String sentence

String tagged

Cek Pola Kata Rancu Tanpa WordNet (Tampung Aturan)

Pencocokan Aturan Yang Tepat

Menanyakan Sinonim Kata Pada wordNet

Rancu?

Pencocokan Aturan dengan bantuan wordNet

Cetak Hasil : Kalimat Rancu

Selesai TIDAK

Ya

Rancu?

YA

Cetak Hasil Tidak Rancu ^TIDAK

Tidak Rancu

Pola Penyebab Kerancuan

Gambar 5. Diagram Alir Analisis Kerancuan

3. Proses Pemberian Rekomendasi

Setelah pengecekan kerancuan, kalimat kebutuhan akan diberi rekomendasi agar pengguna dapat memperbaiki kerancuan yang terjadi pada kalimat tersebut.

Rekomendasi hanya diberikan pada kalimat yang memiliki hasil analisis berupa kalimat rancu. Pemberian rekomendasi dilakukan dengan mencocokkan pola penyebab rancu dalam tabel basis data aturan dengan rekomendasi yang terdapat di dalamnya. Pada tabel basis data aturan pola penyebab rancu dan rekomendasinya tersimpan dalam satu baris yang sama. Ketika kerancuan disebabkan oleh penggunaan sinonim kata rancu, maka akan dilakukan pengecekan ulang terhadap pola kata penyebab rancu. Hal tersebut dilakukan untuk mendapatkan referensi pola penyebab kerancuan sehingga didapatkanlah hasil rekomendasinya.

Gambar 6 menunjukkan diagram alir dari proses pemberian rekomendasi.

Mulai

String sentence

Cek hasil Analisis

Ambigu?

Pencocokan rekomendasi

Tampilkan Pernyataan Terklasifikas + Rekomendasinya

Selesai

Cetak Hasil

“Tidak Perlu Rekomendasi”

TIDAK

Pola Penyebab Ambigu

YA

Rekomendasi Yang Tepat

Cetak pernyataan terklasifikasi + rekomendasi pada

berkas teks.

Gambar 6. Diagram Alir Pemberian Rekomendasi

3.4 Analisis Aktor

Pada sistem ini hanya terdapat satu aktor yaitu pengguna. Pengguna sistem ini merupakan analis sistem kebutuhan perangkat lunak yang sedang melakukan pengecekan kerancuan dari sebuah dokumen SKPL.

4. Implementasi

4.1 Implementasi Aturan dalam Basis Data Aturan penentuan kerancuan berasal dari beberapa sumber tertulis dan riset-riset sebelumnya mengenai penggunaan kalimat yang menyebabkan kerancuan dalam kalimat pernyataan kebutuhan perangkat lunak. Tabel aturan ditulis oleh Wayan Muliawan. Salah satu contoh pendekatan aturan kerancuan yang ditulis dalam daftar aturannya adalah sebagai berikut ini.

Acuan tersebut menyatakan apabila kita

menggunakan kata-kata seperti some, several dan many dalam sebuah kalimat pernyataan kebutuhan perangkat lunak, maka kalimat tersebut dipastikan akan bersifat rancu. Contoh

Acuan [4] :

“Avoid ambiguities such as some, several, many”

penggunaan kata-kata rancu dalam kalimat kebutuhan dapat kita amati pada contoh berikut ini:

 Jika dalam sebuah kalimat terdapat pola some/DT + NNS, maka kalimat tersebut dapat dikategorikan rancu. Contoh kalimat beserta Part of Speech (POS) untuk tiap-tiap katanya adalah: “The/DT system/NN provides/VBZ some/DT languages/NNS ./.”.

 Jika dalam sebuah kalimat terdapat pola several/JJ + NNS, maka kalimat tersebut dapat dikategorikan rancu. Contoh kalimat beserta POS untuk tiap-tiap katanya adalah:

“The/DT system/NN provides/VBZ several/JJ languages/NNS ./.”.

 Jika dalam sebuah kalimat terdapat pola many/JJ + NNS, maka kalimat tersebut dapat dikategorikan rancu. Contoh kalimat beserta POS untuk tiap-tiap katanya adalah:

“The/DT system/NN provides/VBZ many/JJ languages/NNS ./.”.

Pos kalimat yang digunakan adalah model Penn TreeBank yang digunakan dalam Tugas Akhir ini. Jumlah aturan yang digunakan dalam tugas akhir ini berjumlah 56 buah aturan.

Tabel 1. Simbol dan Definisi English POS Tag Model Penn TreeBank

No. Simbol Definisi Keterangan

1 DT Determiner Pada umumnya

berupa article seperti: the, a, an, all, dan some.

2 NNS Noun (plural) Kata benda bentuk jamak, contoh:

languages, books, hats, dan lain-lain.

3 NN Noun (singular) Kata benda bentuk tunggal, contoh:

language, book, hat, dan lain-lain.

4 VBZ Verb Kata kerja, contoh:

provides

5 JJ Adjective Kata sifat, contoh:

many

6 RB Adverb Kata keterangan,

contoh: clearly 7 PRP Personal Pronoun Kata ganti orang,

contoh: it

4.2 Implementasi Ekstraksi Dokumen

Pembacaan dokumen SKPL menggunakan pustaka Apache POI yang diinstansiasi dan diimplementasikan dalam kelas NewSkpl.Pembacaan dokumen dilakukan secara terurut. Agar lebih mudah dalam melakukan pengolahan string, isi dokumen dipotong dengan mendeteksi akhir dari satu baris bagian dokumen.

Cara yang digunakan untuk melakukan pengecekan terhadap kebutuhan spesifik dokumen SKPL adalah dengan mengidentifikasi id dari pernyataan kebutuhan yang terkandung dalam kebutuhan spesifik. Selanjutnya dilakukan pemecahan tabel dari kebutuhan spesifik.

Setelah kebutuhan spesifik didapatkan, dilakukan pengecekan terhadap kalimat utuh.

Dalam melakukan proses pengecekan kalimat utuh, pustaka openNLP digunakan sebagai pustaka pembantu. Fungsi openNLP yang digunakan pada proses ini adalah fungsi sentence detector. Gambar 7 menunjukkan implementasi dari ekstraksi dokumen pada kelas NewSKPL.

Gambar 7. Implementasi Ekstraksi Dokumen pada kelas NewSKPL

4.3 Implementasi Analisis Kerancuan

Proses analisis kerancuan merupakan proses utama dari aplikasi ini. Dalam proses ini, kalimat kebutuhan yang telah didapatkan dari proses ekstraksi, dianalisis kerancuannya dengan menggunakan bantuan dari basis data mySQL dan pustaka wordNet.

Kalimat kebutuhan dipecah dan ditandai

posnya oleh proses tagging menggunakan

stanford post tagger. Setelah melalui

proses penandaan pos dan pemisahan kata, maka

dilakukan proses analisis kerancuan. Pemisahan

kata dan posnya menghasilkan dua buah

keluaran yaitu k1 dan tag1. Gambar 8

menunjukkan implementasi analisis kerancuan pada kelas AturanSmartModel dimana kelas tersebut berfungsi sebagai jembatan antara sistem dengan tabel basis data aturan.

Gambar 8. Implementasi Analisis Kerancuan pada kelas AturanSmartModel

Mendeteksi kerancuan tanpa bantuan sinonim dari WordNet dilakukan terlebih dahulu. Proses ini mendeteksi pola-pola rancu berdasarkan tabel aturan dalam basis data mySql. Proses ke-2 dilakukan dengan memilih aturan yang tepat dalam tabel berdasarkan kata dan pos. Jika tidak ditemukan kata yang persis dalam basis data maka akan dilakukan Proses ke-3 yaitu pencarian sinonim kata rancu yang dibantu oleh WordNet berdasarkan kesamaan pos yang ditemukan. Dilanjutkan Proses ke-4 dengan mendeteksi kerancuan berdasarkan sinonim yang diperoleh dari WordNet. Maka akan diketahui adakah sionim kata rancu yang terdapat dalam kata yang sedang dianalisis.

Setelah hasil didapatkan dilakukan proses terakhirr yaitu mencetak hasil analisis. Pencarian sinonim dalam wordnet didasarkan pada kesamaan pos yang dimiliki oleh kata.

4.4 Implementasi Pemberian Rekomendasi Masing-masing aturan kalimat rancu memiliki rekomendasinya sendiri. Sehingga terdapat 56 butir rekomendasi untuk 56 aturan kalimat rancu. Pengimplementasian rekomendasi kalimat rancu ke dalam basis data mySQL menggunakan satu tabel bersamaan dengan basis data aturan untuk mempermudah pengambilan rekomendasi apabila ditemukan

kecocokan pola kalimat rancu dengan aturan dalam tabel. Pengambilan isi dari rekomendasi dilakukan dengan mencocokkan kata penyebab rancu dengan kata dan pos dengan tabel aturan mySQL. Implementasi dari pemberian rekomendasi terdapat pada kelas readAmbiguDoc seperti yang ditunjukkan pada Gambar 9.

Gambar 9. Implementasi Pemberian Rekomendasi pada kelas readAmbiguDoc pada

kelas AturanSmartModel

5. Uji Coba

Uji coba dibagi menjadi 2 bagian yaitu uji coba fungsionalitas dan uji coba non fungsionalitas. Uji coba fungsionalitas meliputi semua kebutuhan fungsional pada kakas bantu.

Sedangkan uji coba non fungsionalitas dilakukan untuk melihat performa dari kakas bantu beserta kepuasan pengguna terhadap performa yang dimiliki oleh kakas bantu.

5.1 Uji Coba Kebutuhan Fungsional 1. Uji Coba Ekstraksi Dokumen SKPL

Uji coba ini bertujuan untuk mengetahui apakah ektraksi terhadap dokumen SKPL berhasil dilakukan dengan sempurna pada dokumen uji. Uji coba dilakukan dengan memasukkan dokumen SKPL dengan format berkas .docx ke dalam kakas bantu dan pengguna memilih pilihan lakukan „Baca Berkas‟.

Parameter pengujian adalah tingkat kesamaan yang didapatkan dari pembandingan terhadap jumlah kebutuhan spesifik yang berhasil diekstraksi oleh kakas bantu dengan hasil perhitungan jumlah kebutuhan spesifik secara manual.

Gambar 10 menunjukkan salah satu

keberhasilan dari uji coba ini. Pada dokumen

argos_urd.docx terdapat 61 butir pernyataan

kebutuhan dalam kebutuhan spesifik dan kakas

bantu berhasil mengekstraksi ke 61 pernyataan

tersebut. Sehingga uji coba fungsionalitas

ekstraksi dokumen SKPL pada kakas bantu

dapat dinyatakan berhasil.

Gambar 10. Hasil ekstraksi Dokumen argos_urd.docx

2. Uji coba Analisis Kerancuan dan Pemberian Rekomendasi

Uji coba ini bertujuan untuk mengetahui apakah semua kebutuhan spesifik yang telah terekstraksi berhasil dianalisis dan diberikan rekomendasi. Cara pengujian adalah dengan mencocokkan jumlah pernyataan yang bersifat rancu dan hasil rekomendasi yang didapat dari sistem dan perhitungan manual.

Dalam uji coba yang dilakukan pada dokumen argos_urd.docx ini berhasil didapat 10 butir pernyataan kebutuhan bersifat rancu dan 10 butir pernyataan tersebut berhasil diberi rekomendasi. Gambar 11 menunjukkan keberhasilan uji coba ini.

Gambar 11. Hasil Analisis dan Pemberian Rekomendasi Dokumen argos_urd.docx

3. Uji coba Akurasi Performa Hasil Analisis Kerancuan

Uji coba ini bertujuan untuk mengetahui tingkat akurasi/ kebenaran dari analisis kerancuan yang dihasilkan sistem dengan mencari indeks Kappa(indeks kesepakatan anatara penguji 1 dan penguji 2). Dimana penguji 1 adalah seorang ahli kebutuhan perangkat lunak dan penguji 2 adalah kakas bantu analisis kerancuan berbasis aturan.

Dokumen yang digunakan dalam uji coba ini adalah dokumen uji dari penelitian ReqSac [1].

Dimana pernyataan kebutuhan dalam dokumen tersebut telah diklasifikasikan sebelumnya oleh ahli kebutuhan perangkat lunak. Hasil perhitungan manual hasil yang didapat dari uji coba ini terdapat pada tabel 2.

Tabel 2. Hasil Perhitungan Hasil Analisis Kerancuan Kakas Bantu Rancu Tidak Rancu Ahli Rancu 42 0

Tidak Rancu 8 15

Berdasarkan data tersebut maka P(A) = (42 + 16) / 65 = 0.8923. Kemudian untuk menghitung P(E) dilakukan dengan cara sebagai berikut:

1. Ahli menjawab rancu sebanyak 42 kali dan tidak rancu sebanyak 23 kali, maka prosentase ahli menjawab rancu = 64.61 % 2. Kakas bantu menjawab rancu sebanyak 49

kali dan tidak rancu sebanyak 16 kali, maka prosentase kakas bantu menjawab rancu adalah sebesar = 75.38 %

3. Probabilitas para penguji menjawab rancu adalah 0.6461 * 0.7538 = 0.4870

4. Probabilitas para penguji menjawab tidak rancu adalah (0.3539 * 0.2461) = 0.0870 5. P(E) = 0.4870 + 0.0870 = 0.5740

Setelah itu nilai κ (indeks Kappa) dapat ditentukan dengan:

κ = ( 0.8923 – 0.5740) / (1-0.5740) = 0.3183/0.426

= 0.7471

5.2 Uji Coba Kebutuhan NonFungsional 1. Uji Coba Penggunaan

Uji coba penggunaan dibagi menjadi 2 sesi,

setiap sesi diikuti oleh 5 partisipan. Partisipan

merupakan mahasiswa teknik informatika yang sering terlibat dengan kebutuhan perangkat lunak. Sesi pertama dilakukan untuk menguji kemudahan penggunaan aplikasi. Pada sesi pertama, setiap partisipan tidak akan diberikan arahan untuk menggunakan aplikasi. Setiap partisipan akan diberikan waktu maksimal selama 30 menit. Sesi kedua dilakukan pengujian menggunakan skenario pengujian ekstraksi dan analisis kerancuan serta penggunaan fitur-fitur pendukung pada kakas bantu. Waktu yang diberikan maksimal 30 menit. Setelah melakukan 2 sesi uji coba penggunaan, partisipan diberikan kuisioner. Hal ini dilakukan untuk mengetahui tingkat kesepakatan terhadap kepuasan partisipan sebagai pengguna terhadap kakas bantu ini.

Tabel 3 menyajikan hasil kuisioner yang didapat dari partisipan.

Tabel 3. Hasil Kuisioner Partisipan

Pernyataan Tingkat

Persetujuan Kakas bantu mudah digunakan. 70%

Tampilan kakas bantu menarik. 75%

Partisipan memahami kinerja kakas bantu. 70%

Partisipan memahami hasil keluaran yang dihasilkan oleh kakas bantu.

85%

Tingkat kepuasan yang didapat dari hasil keluaran kakas bantu.

80%

Partisipan merasa terbantu apabila kakas bantu digunakan dalam melakukan analisis kerancuan kebutuhan perangkat lunak

85%

6. Kesimpulan

Dari hasil pengamatan selama perancangan, implementasi, dan proses uji coba perangkat lunak yang dilakukan, penulis mengambil kesimpulan sebagai berikut:

1. Telah berhasil diimplementasikan sebuah kakas bantu yang dapat mengekstraksi sebuah dokumen SKPL menjadi kebutuhan spesifik yang dapat melakukan analisis kerancuan serta memberikan rekomendasi pada kerancuan yang terjadi.

2. Berdasarkan indeks kappa yang didapatkan dari hasil dokumen uji penelitian ReqSac

didapatkan hasil kappa sebesar 0,7079 yang artinya kakas bantu memiliki nilai proporsi kesepakatan Banyak (Substantial).

3. Kakas bantu berhasil memenuhi tujuan utamanya yaitu, dapat mempermudah pengoreksian kerancuan sebuah dokumen SKPL dengan memperoleh nilai kesepakatan dari responden sebesar 85%.

7. Daftar Pustaka

[1] Hussain, H. M. I. 2007. “Using Text Classification to Automate Ambiguity Detection in SRS Documents”. Tesis di Departemen Computer Science &

Software Engineering, Universitas Concordia , Canada [2]Muliawan, I Wayan (2011). “Analisis Ambiguitas Kebutuhan Perangkat Lunak berdasarkan Acuan Smart Requirement”. Tesis di Jurusan Teknik Informatika, Institut Teknologi Sepuluh Nppember, Surabaya.

[3]Wilson, W., Rosenberg, L., & Hyatt, L. (1996)

“Automated Quality Analysis of Natural Language Requirement Specifications”. Proceedings 14

^th

Annual Pacific Northwest Software Quality Conference, ortland.

[4]Mannion, M., Keepence, B. 1995. “SMART

Requirements”. ACM Sigsoft. The Standish Group

International, Inc. (1995). “The CHAOS Report”.