KAKAS BANTU ANALISIS KERANCUAN KEBUTUHAN PERANGKAT LUNAK BERBASIS ATURAN 1,2,3
Yunata Dede Pratiwi1, Daniel Oranova S 2, Sarwosri3 Jurusan Teknik Informatika, Fakultas Teknologi Informasi, Institut Teknologi Sepuluh Nopember Kampus ITS Sukolilo Surabaya, 60111, Indonesia 1
[email protected],
[email protected],
[email protected]
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. kebutuhan perangkat lunak berbasis aturan. Kakas bantu ini dapat membantu tim 1. Pendahuluan pengembang perangkat lunak untuk mendeteksi Tahap awal dari suatu pembangunan sistem kalimat rancu dalam kebutuhan spesifik sebuah perangkat lunak adalah proses analisis dokumen SKPL beserta pemberian rekomendasi kebutuhan sistem. Di tahap awal ini terjadi kepada pengguna terhadap kerancuan yang interaksi antara calon pengguna sistem dan terjadi dalam kalimat tersebut. Kakas bantu ini pihak pengembang perangkat lunak, dimana hanya melayani analisis kerancuan pada mereka harus memiliki persepsi yang sama atas dokumen SKPL berbahasa inggris, sesuai spesifikasi perangkat lunak yang dibangun. dengan format IEEE dan memiliki ekstensi Kumpulan dari spesifikasi kebutuhan berkas .docx . dikumpulkan dalam bentuk Dokumen Spesifikasi Kebutuhan Perangkat Lunak (SKPL). Dokumen SKPL disusun menggunakan 2. Tinjauan Pustaka bahasa alamiah, yaitu bahasa yang kita gunakan 2.1 Kebutuhan Perangkat Lunak dalam percakapan sehari-hari. Penggunaan Kebutuhan perangkat lunak (software bahasa alamiah memiliki kelemahan yaitu pada requirements) adalah atribut-atribut yang saat makna dari kalimat tersebut memiliki arti bersifat spesifik yang merupakan spesifikasi atau penafsiran yang berbeda-beda pada masingkebutuhan fungsional dan kebutuhan non masing orang. Dalam konteks ini, dokumen fungsional dari sebuah sistem perangkat SKPL dapat ditafsirkan berbeda-beda oleh tim lunak. pengembang perangkat lunak. Dengan kata lain, Kebutuhan perangkat lunak dijabarkan dokumen SKPL tersebut bersifat rancu karena dalam sebuah dokumen formal yang disebut dapat memilki arti yang berbeda-beda. Dokumen dokumen Spesifikasi Kebutuhan Perangkat SKPL yang bersifat rancu dapat menyebabkan Lunak (SKPL). Spesifikasi yang harus kegagalan dalam pengembangan proyek terkandung dalam sebuah dokumen kebutuhan perangkat lunak karena tujuan proyek tidak perangkat lunak antara lain: fungsionalitas, tercapai. antarmuka eksternal, performa, atribut dan Kerancuan dalam sebuah dokumen SKPL batasan perancangan. Gambar 1 menunjukkan disebabkan penggunaan kata yang rancu dalam pokok-pokok bahasan dalam sebuah dokumen menyusun kalimat-kalimat kebutuhan. SKPL. Untuk itu pada tugas akhir ini dibangun sebuah kakas bantu analisis kerancuan 1
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.
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.
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
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 2
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.
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 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
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. Ekstraksi Dokumen SKPL Kebutuhan Spesifik à Pernyataan Kebutuhan
Deteksi Kalimat Utuh
Ekstraksi Berdasarkan Struktur Kalimat Analis Kebutuhan Dokumen SKPL
Antarmuka Pengguna
Analisis Ambiguitas
Cetak Hasil
Pemberian Rekomendasi
Gambar Error! No text of specified style in document.. Arsitektur Sistem Analisis Kerancuan
3
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.
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.
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
Mulai Lokasi Berkas Baca isi keseluruhan Dokumen String Paragraf Cek Tabel dan Cek Id Kebutuhan Spesifik
Format Sesuai IEEE? YA
Kebutuhan Spesifik Cek Keutuhan Kalimat Kalimat Utuh?
TIDAK
Beri Tanda kalimat Tidak Utuh
IYA Kalimat Utuh Tampilkan Hasil Ekstraksi String Sentence Selesai
Gambar 4. Diagram Alir Ekstraksi Dokumen
4
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 String sentence Cek hasil Analisis
Mulai
Cetak Hasil “Tidak Perlu Rekomendasi”
YA
Pencocokan rekomendasi
Pemisahan kalimat berdasarkan POS
Rekomendasi Yang Tepat
Cetak Hasil : Kalimat Rancu
String tagged
Pencocokan Aturan Yang Tepat
Tampilkan Pernyataan Terklasifikas + Rekomendasinya
Ya
Cek Pola Kata Rancu Tanpa WordNet (Tampung Aturan)
Pola Penyebab Kerancuan
Cetak pernyataan terklasifikasi + rekomendasi pada berkas teks.
Rancu? TIDAK
Menanyakan Sinonim Kata Pada wordNet
YA
Selesai
Gambar 6. Diagram Alir Pemberian Rekomendasi
Pencocokan Aturan dengan bantuan wordNet
Tidak Rancu
TIDAK
Pola Penyebab Ambigu
String sentence
Cetak Hasil Tidak Rancu
Ambigu?
TIDAK
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.
Rancu? Selesai
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.
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 Acuan [4] : “Avoid ambiguities such as some, several, many”
menggunakan kata-kata seperti some, several dan many dalam sebuah kalimat pernyataan kebutuhan perangkat lunak, maka kalimat tersebut dipastikan akan bersifat rancu. Contoh 5
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.
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.
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 contoh: it
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
orang,
6
menunjukkan implementasi analisis kerancuan pada kelas AturanSmartModel dimana kelas tersebut berfungsi sebagai jembatan antara sistem dengan tabel basis data aturan.
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.
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.
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.
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 7
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.
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.
Tabel 2. Hasil Perhitungan Hasil Analisis Kerancuan
Kakas Bantu Ahli Rancu
Rancu
Tidak 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
Gambar 11. Hasil Analisis dan Pemberian Rekomendasi Dokumen argos_urd.docx
8
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.
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 14th 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”.
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 9
