ANALISIS AMBIGUITAS KEBUTUHAN PERANGKAT LUNAK BERDASARKAN ACUAN SMART REQUIREMENTS

Transkripsi

1 ANALISIS AMBIGUITAS KEBUTUHAN PERANGKAT LUNAK BERDASARKAN ACUAN SMART REQUIREMENTS I Wayan Muliawan, Daniel Oranova Siahaan, Sarwosri Jurusan Teknik Informatika ITS muliawan@cs.its.ac.id ABSTRAK Kegagalan dalam suatu proyek pengembangan perangkat lunak berakar dari kesalahan yang terjadi pada proses penspesifikasian kebutuhan. Pada prakteknya, spesifikasi kebutuhan dinyatakan dalam bahasa alamiah. Hal ini membuat spesifikasi tersebut menjadi tercemar oleh berbagai bentuk ambiguitas, yang pada akhirnya berkontribusi pada kegagalan kritis dalam tahapan proses pengembangan berikutnya. Untuk itu, perlu suatu metode untuk mendeteksi sedini mungkin ambiguitas yang mungkin muncul atau terkandung di dalam suatu spesifikasi kebutuhan. Dalam penelitian ini diajukan sebuah metode untuk menganalisis ambiguitas kebutuhan perangkat lunak berdasarkan kriteria kebutuhan yang spesifik dalam acuan SMART Requirements dengan menggunakan teknik pengolahan bahasa alamiah (Natural Language Processing - NLP) dan dibantu oleh WordNet sebagai repositori kata-kata yang tidak diinginkan (non-desired words) yang bersifat andal dan dinamis, yaitu mudah menyesuaikan diri dengan sistem yang akan dibangun. Dengan pendekatan ini diharapkan ruang lingkup dari daftar kata-kata yang tidak diinginkan menjadi lebih luas. Penelitian ini menghasilkan sebuah metode yang dapat mengidentifikasi kebutuhan yang bersifat ambigu maupun tidak ambigu dengan indeks Kappa = , lebih baik dari penelitian sebelumnya. Kata kunci: Ambiguitas Kebutuhan Perangkat Lunak, SMART Requirements, Natural Language Processing (NLP), WordNet PENDAHULUAN Analisis kualitas kebutuhan perangkat lunak merupakan fase penting dalam sebuah proyek pengembangan perangkat lunak (Bucchiarone et al., 2008). Kebutuhan perangkat lunak dapat dikatakan berkualitas jika kebutuhan tersebut bersifat Specific, Measurable, Attainable, Realisable, dan Traceable (SMART) (Mike & Berry, 1995). Menciptakan kebutuhan perangkat lunak yang berkualitas adalah langkah awal untuk menciptakan perangkat lunak yang berkualitas pula (Giuseppe, 2005). Penelitian yang dilakukan oleh The Standish Group di tahun 1995 (Standish, 1995) menunjukkan bahwa kegagalan dalam suatu proyek pengembangan perangkat lunak berakar dari kesalahan yang terjadi pada proses penspesifikasian kebutuhan. Pada prakteknya, spesifikasi kebutuhan dinyatakan dalam bahasa alamiah. Hal ini membuat spesifikasi tersebut menjadi tercemar oleh berbagai bentuk ambiguitas, yang pada akhirnya berkontribusi pada kegagalan kritis dalam tahapan proses pengembangan berikutnya. Untuk itu, perlu suatu metode untuk mendeteksi sedini mungkin ambiguitas yang mungkin muncul atau terkandung di dalam suatu spesifikasi kebutuhan. Bagi seorang pengembang perangkat lunak, memeriksa secara manual satu demi satu pernyataan kebutuhan yang sedang disusun merupakan pekerjaan yang memakan banyak waktu dan tenaga. Oleh karena itu para peneliti giat melakukan penelitian untuk

2 menciptakan kakas bantu yang mampu mendeteksi ambiguitas kebutuhan secara otomatis dengan tingkat akurasi yang sebaik mungkin. Automated Requirements Measurement (ARM) merupakan sebuah kakas bantu yang mampu menganalisis kualitas kebutuhan perangkat lunak secara otomatis yang dikembangkan oleh Software Assurance Technology Center (SATC) NASA. Pengembangnya, (Wilson, 1997) dan (Wilson et al., 1996) membuat 9 kategori indikator kualitas kebutuhan perangkat lunak, yaitu: 1. Keharusan (imperatives), 2. Kelanjutan (continuances), 3. Arahan (directives), 4. Pilihan (options), 5. Frasa lemah (weak phrases), 6. Ukuran (size), 7. Kedalaman spesifikasi (specification depth), 8. Keterbacaan (readability), dan 9. Struktur teks (text structure) Lima pertama dari kategori tersebut berdasarkan frekwensi munculnya kata-kata tertentu dalam konteks ambiguitas. Sedangkan empat sisanya berhubungan dengan pengorganisasian dokumen Spesifikasi Kebutuhan Perangkat Lunak (SKPL). Kelemahan kakas bantu ini yaitu mengabaikan penggunaan metode-metode NLP terkini (misal: analisis morfologi dan analisis sintaktik) yang tentunya bisa meningkatkan performa kakas bantu tersebut dalam menganalisis ambiguitas kebutuhan perangkat lunak. Sekelompok peneliti dari Formal Method and Tool (FMT) Group memperkenalkan kakas bantu yang bernama Quality Analyzer of Requirements Specifications (QuARS) (Fabbrini et al., 2001)(Giuseppe, 2005). QuARS didasarkan pada model kualitas yang mengukur kemampuan untuk dapat diuji (testability), kelengkapan (completeness), kemampuan untuk dapat dimengerti (understandability), dan konsistensi (consistency) dari spesifikasi kebutuhan perangkat lunak yang ditulis dalam bahasa alamiah. Kakas bantu ini menganalisis struktur dokumen Spesifikasi Kebutuhan Perangkat Lunak serta sintaktik dan semantik dari tiap-tiap pernyataan kebutuhan. Struktur dokumen dibandingkan terhadap dokumen standar SKPL dari Rational Unified Process (RUP), sedangkan kepatuhan sintaktik dan semantik diperiksa terhadap satu set kata kunci yang telah ditetapkan yang merupakan kata-kata yang tidak diinginkan. Tiap-tiap domain permasalahan membutuhkan repositori khusus yang memuat kata-kata yang tidak diinginkan pada ruang lingkup permasalahan tersebut. Hal ini sekaligus sebagai kelemahan kakas bantu ini karena ruang lingkup repositori katakata yang tidak diinginkan bersifat terbatas. Requirements Specification Ambiguity Checker (ReqSAC) dikembangkan oleh (Hussain, 2007). Di dalam buku tesisnya ia menuliskan bahwa tujuan dari penelitiannya adalah untuk menghasilkan sebuah metode beserta kakas bantu yang mampu mendeteksi secara otomatis ambiguitas kebutuhan pada fase elisitasi. Untuk mendeteksi ambiguitas digunakan metode klasifikasi teks dengan menggunakan algoritma C4.5 di dalamnya. Kualitas, kuantitas, dan ruang lingkup data latih akan sangat menentukan performa ReqSAC dalam menganalisis ambiguitas kebutuhan perangkat lunak. Jumlah ahli yang terlibat akan menentukan kualitas data latih (Hussain, 2007). Sedangkan di dalam penelitiannya (Hussain, 2007) hanya melibatkan tiga orang ahli untuk membentuk data latih pada analisis tingkat kalimat (sentence-level analysis). Ditinjau dari sisi kuantitas dan ruang lingkup data latih yang digunakan masih bersifat terbatas C-28-2

3 pada 25 buah topik proyek perangkat lunak. Kemudian yang tak kalah menariknya adalah repositori kata-kata yang bersifat ambigu diciptakan secara otomatis berdasarkan data latih yang digunakan. Hal ini sekaligus sebagai kelemahan ReqSAC karena repositori yang dihasilkan tersebut tentu saja belum andal dan ruang lingkupnya masih bersifat terbatas. METODA Pengidentifikasian Acuan SMART Requirements Tahap ini adalah tahap pengidentifikasian acuan SMART Requirements yang bertujuan untuk menghasilkan aturan SMART. Aturan SMART ini nantinya akan disimpan di dalam repositori aturan SMART menggunakan DBMS MySQL. Contoh aturan SMART (difokuskan pada aturan spesifik) yang dibangun adalah sebagai berikut: Acuan: Avoid ambiguities such as some, several, many (Mike & Berry, 1995). Berdasarkan acuan tersebut maka aturan SMART yang perlu dibangun adalah: 1. Jika terdapat struktur some/jj + NNS, maka struktur tersebut dapat dikategorikan ambigu. Contoh kalimat berikut Part of Speech (POS)-nya: The/DT system/nn provides/vbz some/jj languages/nns./.. 2. Jika terdapat struktur several/jj + NNS, maka struktur tersebut dapat dikategorikan ambigu. Contoh kalimat berikut POS-nya: The/DT system/nn provides/vbz several/jj languages/nns./.. 3. Jika terdapat struktur many/jj + NNS, maka struktur tersebut dapat dikategorikan ambigu. Contoh kalimat berikut POS-nya: The/DT system/nn provides/vbz many/jj languages/nns./.. Pada saat makalah ini ditulis, telah dihasilkan 27 buah aturan SMART. Perancangan Metode Perancangan Metode adalah tahap inti dalam penelitian ini yang bertujuan untuk menghasilkan sebuah metode yang dapat digunakan untuk menganalisis ambiguitas kebutuhan perangkat lunak berdasarkan kriteria kebutuhan yang spesifik dalam acuan SMART Requirements Arsitektur sistem yang diajukan dalam penelitian ini adalah sebagai berikut: Gambar 1. Arsitektur Sistem C-28-3

4 Daerah yang berwarna abu-abu adalah ruang lingkup dari penelitian ini. Berikut dijelaskan tiap-tiap komponen dalam arsitektur sistem di atas. Preprocessing Stanford POS Tagger digunakan untuk menandai POS setiap kata pada pernyataan kebutuhan agar bisa diproses lebih lanjut oleh Modul SMART. Contoh masukan: The system provides several languages.. Keluaran yang dihasilkan: The/DT system/nn provides/vbz several/jj languages/nns./. Repositori Aturan SMART Repositori aturan SMART dibuat menggunakan DBMS MySQL. Kata-kata yang bersifat ambigu beserta POS-nya disimpan dalam sebuah tabel yang bernama aturansmart (gambar 2.2). Field pos2 menunjukkan pasangan POS yang membuat sebuah kalimat menjadi ambigu. Contoh: several/jj + languages/nns. Isi field pos nantinya digunakan oleh Modul SMART dalam proses pemilihan aturan yang tepat dalam rangka menganalisis ambiguitas sebuah pernyataan kebutuhan. Gambar 2. Tabel aturansmart WordNet Menggunakan RiTa WordNet yang telah dilengkapi dengan WordNet dictionary. RiTa WordNet bertugas untuk memberikan rekomendasi berupa sinonim dari kata-kata yang bersifat ambigu yang ada di dalam tabel aturansmart. Dalam implementasinya akan menggunakan Java sebagai bahasa pemrograman. Kemudian untuk mencari sinonim digunakan metode getallsynonyms. Gambar 3. Metode getallsynonyms Modul SMART Modul SMART adalah modul utama yang bertugas untuk menganalisis ambiguitas setiap pernyataan kebutuhan yang telah diproses sebelumnya. Proses analisis C-28-4

5 dibantu oleh repositori aturan SMART dan WordNet. Modul SMART memiliki 6 tugas utama, yaitu memilih aturan yang tepat, mendeteksi frase ambigu, mendeteksi ambiguitas tanpa bantuan sinonim dari WordNet, menanyakan sinonim kata ambigu kepada WordNet, mendeteksi ambiguitas dengan bantuan sinonim dari WordNet, dan mencetak hasil analisis yang disertai dengan catatan mengapa sebuah pernyataan kebutuhan dinilai ambigu dengan menunjukkan bagian mana yang bersifat ambigu. Hasil analisis berupa kesimpulan apakah pernyataan kebutuhan yang telah dianalisis bersifat ambigu atau tidak ambigu. Jika ambigu, maka akan disertai catatan mengapa sebuah pernyataan kebutuhan dinilai ambigu dengan menunjukkan bagian mana yang bersifat ambigu. Hasil analisis kemudian dikoreksi oleh seorang ahli rekayasa kebutuhan, yaitu Dr. Daniel Oranova Siahaan dari Jurusan Teknik Informatika ITS. Pengujian Untuk mengetahui performa metode yang diajukan di dalam penelitian ini, maka pengujian dilakukan dengan cara membandingkan pengetahuan yang dimiliki oleh seorang ahli dengan keluaran yang dihasilkan oleh kakas bantu. Ahli bertindak sebagai penguji pertama, kakas bantu bertindak sebagai penguji kedua. Sedangkan analisis terhadap hasil pengujian dilakukan dengan menggunakan Kappa Statistics (Cohen, 1960). Kappa Statistics digunakan untuk menganalisis hasil pengujian karena tidak adanya data set dalam penelitian ini. Disamping itu, subyektivitas dari seorang ahli rekayasa kebutuhan sebagai penguji pertama adalah pertimbangan lain mengapa Kappa Statistics digunakan untuk menganalisis hasil pengujian. Gambar 4. Kakas Bantu C-28-5

6 Dalam pengujian menggunakan 30 buah kalimat pernyataan kebutuhan. Terjadi 1 kali misclassification dalam mendeteksi ambiguitas, dimana kalimat yang ambigu menurut ahli, dideteksi sebagai kalimat yang tidak ambigu oleh kakas bantu. HASIL Kappa Statistics digunakan untuk menganalisis hasil pengujian. κ P(A) P(E) = indeks Kappa = proporsi berapa kali para penguji diamati setuju = proporsi berapa kali para penguji diharapkan setuju Kakas Bantu Kakas Bantu Ambigu Ahli Ambigu 19 1 Tidak Ambigu Ahli Tidak Ambigu 0 10 Gambar 5. Jawaban Ahli dan Kakas Bantu Setiap pernyataan kebutuhan diuji oleh seorang ahli dan sebuah kakas bantu. Ahli maupun kakas bantu memiliki dua kemungkinan jawaban: ambigu atau tidak ambigu. Berdasarkan gambar 5 di atas terlihat bahwa 19 buah pernyataan kebutuhan dinyatakan ambigu oleh ahli maupun kakas bantu dan 10 buah pernyataan kebutuhan dinyatakan tidak ambigu. Berdasarkan data tersebut maka P(A) = ( ) / 30 = Kemudian untuk menghitung P(E) dilakukan dengan cara sebagai berikut: Ahli menjawab ambigu sebanyak 19 kali dan tidak ambigu sebanyak 1 kali, maka prosentase ahli menjawab ambigu = % Kakas bantu menjawab ambigu sebanyak 19 kali dan tidak ambigu sebanyak 10 kali, maka prosentase kakas bantu menjawab ambigu = % Probabilitas para penguji menjawab ambigu adalah * = Probabilitas para penguji menjawab tidak ambigu adalah * = P(E) = = Setelah itu nilai κ (indeks Kappa) dapat ditentukan dengan mudah: κ = ( ) / ( ) = / = ( lebih tinggi dari pada penelitian sebelumnya yang dilakukan oleh (Hussain, 2007)). KESIMPULAN Berdasarkan indeks Kappa yang telah didapat serta dengan melihat indeks Kappa penelitian sebelumnya yang dilakukan oleh (Hussain, 2007), maka dapat disimpulkan bahwa metode yang diajukan dalam penelitian ini memiliki performa yang lebih baik dalam mendeteksi ambiguitas yang terkandung di dalam kalimat pernyataan kebutuhan. C-28-6

7 DAFTAR PUSTAKA Cohen, J. (1960). A coefficient of agreement for nominal scales. Educational and Psychological Measurement. Mannion, M., Keepence, B. (1995). SMART Requirements. ACM Sigsoft. The Standish Group International, Inc. (1995). The CHAOS Report. Wilson, W., Rosenberg, L., & Hyatt, L. (1996) Automated Quality Analysis of Natural Language Requirement Specifications. Proceedings 14 th Annual Pacific Northwest Software Quality Conference, Portland, Wilson, W. (1997). Writing Effective Requirements Specifications. USAF Software Technology Conference, Utah. Fabbrini, F., Fusani, M., Gnesi, S., dan Lami, G. (2001). An Automatic Quality Evaluation for Natural Language Requirements. Seventh International Workshop on Requirements Engineering: Foundation for Software Quality (REFSQ'01) Interlaken, Switzerland. Lami, G. (2005). QuARS: A Tool for Analyzing Requirements. Technical Report CMU/SEI-2005-TR-014 ESC-TR 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. Bucchiarone, A., Fantechi, A., Gnesi, S., Lami, G., dan Trentanni, G. (2008). QuARS Express - An Automatic Analyzer of Natural Language Requirements. Proceeding ACM International Conference on Automated Software Engineering, , L'Aquila, Italy. C-28-7