1
PERBAIKAN DAN PENGUKURAN KUALITAS KEBUTUHAN PERANGKAT LUNAK SSN MENGGUNAKAN METODE REFACTORING DAN MATRICS SQUARE Artha Patra Pradana, Feby Artwodini Muqtadiroh, S.Kom, M.T, Hanim Maria Astuti, S.Kom, M.Sc Jurusan Sistem Informasi, Fakultas Teknologi Informasi, Institut Teknologi Sepuluh Nopember Kampus Keputih, Sukolilo, Surabaya 60111, Indonesia Email :
[email protected],
[email protected],
[email protected]
Abstrak—Pada sebuah proyek IT perubahan dan permasalahan pada kebutuhan perangkat lunak dapat terjadi kapan saja. Misalnya adanya kebutuhan perangkat lunak yang tidak sesuai dengan harapan pengguna, adanya perubahan yang terjadi dalam kebutuhan perangkat lunak, ketidaksesuaian antara kebutuhan dengan desain sehingga mengakibatkan terjadinya kesalahpahaman dalam mengartikan kebutuhan perangkat lunak. Permasalahan dalam kebutuhan perangkat lunak tersebut dapat mengakibatkan buruknya kualitas dari perangkat lunak yang dihasilkan. Hal tersebut disebabkan oleh informasi kebutuhan perangkat lunak yang memiliki kualitas yang kurang baik. Untuk meminimalisir terjadinya hal tersebut, maka diperlukan untuk melakukan peningkatan kualitas kebutuhan perangkat lunak salah satunya dengan menggunakan refactoring. Refactoring sangat membantu dalam meningkatkan pemahaman kebutuhan perangkat lunak tanpa mengubah proses bisnis dari perangkat lunak tersebut. Setelah proses refactoring dilakukan, selanjutnya perlu dilakukan pengukuran kualitas dari kebutuhan perangkat lunak tersebut untuk mengetahui sejauh mana kualitas dari kebutuhan perangkat lunak yang dibuat. Pengukuran kualitas dilakukan dengan menggunakan metrics SQuaRE yang dilakukan dengan cara menentukan karakteristik dari kualitas yang nantinya akan diukur dan dihitung kualitasnya. Hasil akhir dari pengerjaan tugas akhir ini adalah sebuah kebutuhan perangkat lunak yang telah di refactoring serta sebuah pengukuran kualitas dari kebutuhan perangkat lunak setelah di refactoring pada studi kasus aplikasi SSN. Output yang dihasilkan dari tugas akhir berupa prosesntase kualitas kebutuhan perangkat lunak yang nantinya akan dibandingkan dengan kualitas kebutuhan perangkat lunak sebelumnya dan diharapkan dapat digunakan sebagai perbaikan pembangunan aplikasi SSN selanjutnya. Kata kunci: Jaringan Tv Kabel, Cost & Benefit analysis, Dissount rate, Depresiasi.
I.
INTRODUCTION
Pada sebuah proyek IT, rekayasa kebutuhan perangkat lunak menjadi sebuah metode dan teknik “wajib” untuk melakukan identifikasi, analisis, melakukan spesifikasi, mengelola, memverifikasi, dan memvalidasi sebuah kebutuhan perangkat lunak. Rekayasa kebutuhan perangkat lunak merupakan bagian dari SDLC (System Development Life Cycle) yang menjadi proses utama dalam pengembangan perangkat lunak.
Banyak sekali metode yang digunakan dari SDLC untuk melakukan pengembangan sebuah aplikasi sistem informasi yang bertujuan untuk memberikan panduan agar dapat menghasilkan sebuah aplikasi sistem informasi yang berkualitas yang mampu mencakup segala kebutuhan penggunanya. Faktor utama yang mempengaruhi kualitas dari sebuah aplikasi sistem informasi diantaranya adalah proses identifikasi kebutuhan yang mencakup segala aspek fungsionalitas dari sebuah sistem informasi yang akan dibuat. Semakin detail dan komprehensif informasi yang ada di dalam proses identifikasi kebutuhan (Requirements) maka sistem informasi tersebut akan mampu mencakup segala aspek fungsional sebuah aplikasi seperti aspek usability, re-usability, maintainability dan aspek lainnya sehingga dapat memenuhi kebutuhan penggunanya. (1) Peniliti menemukan bahwa masih ada pengembangan sebuah aplikasi sistem informasi yang menghasilkan aplikasi yang tidak berkualitas. Ada banyak factor yang menyebabkan aplikasi yang dibangun tidak berkualitas diantaranya adalah kebutuhan pengguna yang sering berubah. Namun pada paper (2) menemukan adanya isu kurang baik yang sangat mempengaruhi kualitas pengembangan suatu perangkat lunak, yaitu pada proses identifikasi kebutuhan (Requirements). Buruknya kualitas pada tahap identifikasi kebutuhan akan menyebabkan kegagalan dalam mengetahui aspek fungsionalitas dan kebutuhan pengguna. Contohnya adalah identifikasi kebutuhan dalam skala besar yang mengakibatkan kurangnya kejelasan terhadap aspek fungsionalitas yang terdapat pada aplikasi sistem informasi tersebut yang berdampak pada munculnya lazy requirements, adanya aktivitas yang sama dalam satu proses (duplikat), dan sebagainya. Permasalahan ini lah yang sering ditemui dalam aktivitas indentifikasi kebutuhan dalam proses pengembangan sistem informasi. (3) Untuk meminimalisir terjadinya permasalahan diatas, maka dibutuhkan peningkatan terhadap kualitas pengembangan sistem informasi terutama dari aspek identifikasi kebutuhan sebuah sistem informasi. Metode yang digunakan diantaranya adalah Refactoring, Requirement Management Plan, dan Quality Modelling. Namun metode yang paling cocok digunakan dan berfokus pada fungsionalitas sistemnya adalah Refactoring. Kedua metode yang lain tersebut berfokus pada keseluruhan aspek kebutuhan pengembangan perangkat lunak. Secara teoritis refactoring menurut (4) adalah teknik melakukan restrukturisasi pada kode
2 pemrograman tanpa merubah fungsionalitasnya. Definisi ini kemudian disesuaikan dan diterapkan pada tahap identifikasi kebutuhan pengembangan aplikasi sistem informasi. Pada pengerjaan tugas akhir ini dilakukan restrukturisasi informasi pada identifikasi kebutuhan pengguna dengan menggunakan teknik refactoring dan pengukuran kebutuhan perangkat lunak menggunakan metriks SQuaRE. Teknik ini akan diterapkan pada studi kasus dokumen kebutuhan perangkat lunak SSN (School Social Network). Sehingga diharapkan kualitas dari kebutuhan aplikasi SSN nantinya akan meningkat dan mampu mencakup seluruh aspek fungsionalitas aplikasi sistem informasi dan kebutuhan pengguna serta akan menghasilkan sebuah sistem informasi yang berkualitas . II.
LANDASAN TEORI
A. Software Development Life Cycle SDLC adalah serangkaian aktivitas terstruktur pada proses pengembangan perangkat lunak. Aktivitas ini terdiri dari beberapa tahapan-tahapan penting dalam keberadaan perangkat lunak dilihat dari aspek pengembangannya. Tujuannya adalah untuk mempermudah pengembang dalam menciptakan sebuah perangkat lunak yang baik dan terstruktur serta meminimalisir terjadinya kesalahan dalam pengembangan perangkat lunak.. Semakin berkembangnya teknologi maka semakin berkembang pula model pengembangan perangkat lunak menggunakan SDLC. Ada beberapa model yang ditawarkan dan dari setiap model tersebut memiliki karakteristik masing-masing yang disesuaikan dengan kebutuhan pengembangan perangkat lunak. Diantaranya : 1) Waterfall model 2) Spiral Model 3) Iterative and Incremental development 4) Agile development 5) Rapid Application development B. Software Quality Software Quality menurut (1) adalah software dikatakan berkualitas apabila sesuai dengan kebutuhan yang telah ditentukan. Secara detail (1) mengatakan software quality mengacu pada kesesuaian antara perangkat lunak yang dibangun dengan spesifikasi dan kebutuhan yang telah ditentukan oleh pengguna dan para professional Dampak lain yang akan ditumbulkan dari kesalahan dalam melakukan dokumentasi adalah kebingungan bagi pengguna akhir dalam mengoperasikan perangkat lunak. Kesalahan ini terjadi pada pembuatan user guide / user manual. Kesalahan yang terjadi biasanya adalah : - Kesalahan dalam mendeskripsikan instruksi penggunaan perangkat lunak - Memberikan panduan yang tidak terdapat pada aplikasi yang digunakan
C. Requirement Analysis Tujuan utama dari aktivitas analisis kebutuhan perangkat lunak adalah untuk mendapatkan dan mengidentifikasi kebutuhan perangkat lunak yang akan dibangun dan kondisi-kondisi yang harus dipenuhi selama pengembangan perangkat lunak. Menurut (6) analisis kebutuhan perangkat lunak merupakan salah satu factor penentu kesuksesan dari proyek pengembangan perangkat lunak. Secara konseptual, ada 3 aktivitas utama dalam analisis kebutuhan perangkat lunak diantaranya : 1) Eliciting Requirements Kegiatan melakukan identifikasi kebutuhan perangkat lunak yang diambil dari beberapa sumber termasuk dokumentasi proyek (Project charter), business process documentation, dan stakeholder interviews. Aktivitas ini biasa disebut dengan Requirement Gathering. 2) Analyzing Requirements Kegiatan ini bertujuan untuk menentukan apakah kebutuhan yang telah didapat jelas (clear), lengkap (complete), konsisten (consistent), tidak ambigu (unambiguous). 3) Recording Requirements Kegiatan ini bertujuan untuk mendokumentasikan kebutuhan yang telah didapat dari aktivitas yang telah dijelaskan sebelumnya. Bentuk dokumentasi yang dilakukan diantaranya adalah berupa use case, user stories, dan process specification. D. Use Case Beberapa peneliti memberikan definisi tentang use case. Menurut (7) use case menggambarkan interaksi antara actor dengan sistem yang saling berhubungan diantara keduanya. Use case merupakan bagian dari use case diagram. Use case diagram sangat penting dalam menjelaskan apa yang dilakukan oleh sebuah system yang kemudian dispesifikasikan cara kerjanya oleh Flow of Event. Flow of Event menjelaskan use case dalam bentuk sebuah tulisan yang jelas, serta menginformasikan bagaimana use case dimulai dan berakhir. Gambar 1. contoh penggunaan use case
3 E. Refactoring Menurut (4) refactoring adalah suatu teknik untuk melakukan restrukturisasi kode pemrograman tanpa mengubah fungsionalitas dari pemrograman itu sendiri. Tujuan dari refactoring adalah untuk meningkatkan pemahaman dari kode pemrograman yang ditulis dan mengurangi kompleksitas yang berdampak pada peningkatan maintainability dari kode pemrograman itu sendiri. Developer biasanya menyebut istilah code smell atau bad smell pada kode pemrograman saat akan melakukan refactoring. Contohnya adalah adanya sebuah method dalam pemrograman yang cukup banyak / terduplikasi dengan method yang lain. Ada 2 keuntungan yang didapatkan dari penggunaan metode refactoring yaitu : 1) Maintainability Refactoring akan membuat kode pemrograman lebih mudah dipahami terutama pada saat melakukan perbaikan terhadap bug yang ditemukan dalam perangkat lunak. 2) Extensibility Refactoring akan mempermudah melakukan extend terhadap kapabilitas dari suatu perangkat lunak.
Suatu kondisi dimana sebuah penamaan dalam kebutuhan perangkat lunak tidak mengacu pada konsep yang telah ditentukan atau suatu kondisi dimana penamaan yang sama digunakan untuk konsep yang berbeda (Ambigu). 5.
Duplicate Activities
Suatu kondisi dimana sebuah kebutuhan perangkat lunak yang sama memiliki duplikat pada tempat yang berbeda pada dokumen kebutuhan perangkat lunak. Salah satu contohnya adalah dimana sebuah main flow atau alternative flow diulang pada sebuah kebutuhan perangkat lunak III.
METODE PENELITIAN
Metodologi dalam penelitian diperlukan sebagai panduan dalam proses pengerjaan agar tahapan dalam pengerjaan dapat berjalan secara terarah dan sistematis. Berikut ini adalah gambaran metodologi yang digunakan dalam penelitian ini:
Pada paper [2] dijabarkan mengenai apa saja yang harus diperhatikan sebelum menentukan use case narrative yang dapat diperbaiki menggunakan refactoring. Hal-hal tersebut adalah sebagai berikut : 1. Large Requirements Suatu kondisi dimana sebuah use case mencoba untuk mengakomodasi beberapa fungsi / tujuan sekaligus atau sebuah use case yang memiliki alternative flows dan langkahlangkah yang berlebihan. 2.
Complex Conditional Structure Suatu kondisi dimana sebuah use case kebutuhan perangkat lunak memiliki struktur yang kompleks atau kebutuhan perangkat lunak tersebut membutuhkan beberapa kebutuhan perangkat lunak lain agar menjadi satu kesatuan kebutuhan perangkat lunak yang baik. Kondisi lainnya yang muncul adalah ketika adanya sebuah nested conditional . 3. Lazy Requirement - Suatu kondisi dimana fungsi / peran sebuah kebutuhan perangkat lunak memiliki impact yang tidak jelas terhadap system - Suatu kondisi dimana sebuah kebutuhan perangkat lunak tidak mengakomodasi seluruh aktivitas yang dimaksud / incomplete requirements
4.
Naming Problems
Gambar 2. Metodologi penelitian
3.1.
Studi Literatur Studi literature bertujuan untuk mempelajari mengenai teori apa saja yang digunakan dalam pengerjaan tugas akhir ini diantaranya mengenai refactoring, dan pengukuran kualitas kebutuhan perangkat lunak serta apa saja kriteria-kriteria kebutuhan perangkat lunak yang berkualitas. Hasil dari studi literature ini adalah pemahaman mengenai teori yang akan digunakan untuk mengerjakan tugas akhir. 3.2. Pengambilan Data Pengambilan data dilakukan dengan cara menemui pihak developer dari aplikasi SSN. Pengambilan data ini penting karena data inilah yang akan digunakan untuk melakukan perbaikan dan pengukuran kualitas kebutuhan perangkat lunak. Data yang digunakan adalah use case scenario aplikasi SSN.
4 3.3.
Establish Evaluation Requirements Tahap ini merupakan tahap awal dari melakukan pengukuran kualitas kebutuhan perangkat lunak. Data yang telah didapat dari pertemuan dengan developer aplikasi SSN nantinya akan di analisis oleh expert. Analisis oleh expert dilakukan untuk mengetahui sejauh mana kualitas dari use scenario aplikasi SSN berdasarkan 4 kriteria kualitas (completeness, correctness, consistency, Non-Ambiguity) yang dijelaskan pada paper [14] dan apakah use case scenario tersebut memiliki refactoring oppurtunites. Untuk mengetahui kualitas dari use case scenario tersebut, maka disiapkan beberapa pertanyaan verifikasi yang akan diajukan kepada pihak expert yang mengacu kepada 4 kriteria kualitas kebutuhan perangkat lunak yang telah dijelaskan sebelumnya. 3.4. Specification of Evaluation Tahap ini merupakan tahap kedua dari proses pengukuran kualitas use case scenario aplikasi SSN. Setelah mendapatkan use case scenario apa saja yang kurang berkualitas langkah selanjutnya adalah menentukan bobot dari masing-masing kriteria kualitas serta menentukan rating level dari masing-masing use case scenario. Hasil dari proses ini adalah ditetapkan bahwa untuk use case scenario yang berkualitas diberi nilai 1, sedangkan untuk use case scenario yang tidak memenuhi kualitas diberi nilai 0. Selanjutnya untuk pembobotan dari masing-masing kriteria kualitas yang diberikan oleh expert berdasarkan tingkat kebenarannya adalah : Correctness 90% Completeness 75% Consistency 75% Non-Ambiguity 70% Hasil dari pembobotan dan pemberian rating level ini nantinya akan digunakan untuk perhitungan pengukuran kualitas use case scenario aplikasi SSN. 3.5. Design of evaluation Tahap ini merupakan tahap ketiga dari proses pengukuran kualitas use case scenario aplikasi SSN. Pada tahap ini akan dibuatkan sebuah dokumen evaluation plan yang berisi tentang proses pengukuran kualitas use case scenario aplikasi SSN. 3.6. Execution of evaluation Tahap ini merupakan tahap terakhir dari proses pengukuran kualitas use case scenario aplikasi SSN. Pengukuran dilakukan dengan menggunakan bobot serta rating level yang telah diberikan kemudian dimasukkan ke dalam rumus perhitungan kualitas. Hasil dari perhitungan ini nantinya yang akan menentukan apakah use case scenario tersebut berkualitas atau tidak. 3.7.
Melakukan refactoring Hasil pengukuran kualitas use case scenario sebelumnya akan dijadikan input pada tahap ini. Hasil tersebut diolah menggunakan refactoring. Ada 5 cara yang dapat dilakukan untuk melakukan perbaikan
menggunakan refactoring yang dapat digunakan sesuai kebutuhan diantaranya : Extract Requirements Proses ini dilakukan apabila ada informasi kebutuhan perangkat lunak dalam skala besar yang dapat dibagi menjadi 2 atau lebih sebagai kebutuhan yang baru (dalam konteks yang sama). Menurut paper [2] Kebutuhan perangkat lunak ini mengandung banyak informasiinformasi penting dan sulit untuk dipahami sehingga untuk selanjutnya sangat tidak mudah dalam menemukan informasi yang dibutuhkan dengan cepat. Rename Requirements Pemberian nama pada kebutuhan perangkat lunak disesuaikan dengan konteks dari kebutuhan perangkat lunak tersebut. Pemberian nama yang baik akan mempermudah komunikasi dan pemahaman terhadap abstraksi system dan penggunaan kosa kata secara umum yang akan mempermudah tim pengembang [2]. Move Activity Proses ini dilakukan untuk meningkatkan modularitas dan menyeimbangkan aktivitas antara kebutuhan perangkat lunak. Proses ini bisa juga terjadi pada saat proses ekstraksi kebutuhan (Extract Requirement) dengan memindahkan aktivitas ke kebutuhan yang diinginkan. [12] mengatakan bahwa peningkatan modulartias pada kebutuhan perangkat lunak akan mengarahkan pada pemahaman yang lebih baik terhadap system dalam jangka panjang. Inline Requirement Proses ini dilakukan untuk mengurangi kompleksitas dari kebutuhan perangkat lunak dengan cara menggabungkan beberapa kebutuhan perangkat lunak yang ada. Jika sebuah kebutuhan perangkat lunak tidak cukup penting untuk digunakan, maka pengembang dapat melakukan inline, merging terhadap kebutuhan perangkat lunak yang lain. Setiap artifak dari perangkat lunak menuntut waktu dan sumber daya untuk memahami dan me maintain perangkat lunak tersebut. [13] Extract Alternative Flows Proses ini dilakukan pada saat information flow pada kebutuhan perangkat lunak melakukan beberpa scenario dalam waktu yang bersamaan sehingga terjadi penumpukan informasi yang berakibat pada pemahaman requirement responsibilities dan information flow yang minim dan sulit. Alternative scenario adalah cara yang tepat untuk mengelola alur informasi yang kompleks dengan struktur kondisi tertentu. [13]
5 3.8.
Melakukan Verifikasi use case scenario aplikasi SSN Setelah memperbaiki use case scenario menggunakan refactoring, langkah selanjutnya adalah melakukan verifikasi kembali oleh pihak expert. Proses verifikasi sama dengan pada saat proses awal sebelum melakukan refactoring. Proses verifikasi ini untuk mengetahui sejauh mana kualitas dari use case scenario aplikasi SSN jika dilihat dari 4 kriteria kualitas. Penyusunan Buku Tugas Akhir Setelah melakukan seluruh proses sebelumnya, maka selanjutnya adalah melakukan penyusunan buku tugas akhir yang bertujuan untuk mendokumentasikan seluruh proses pengerjaan dari awal hingga akhir sehingga menghasilkan buku tugas akhir. IV.
harus diperbaiki diantaranya (penjelasan lebih detail ada di bagian appendix pada buku ini): Table 2. Pemilihan use case scenario menggunakan expert judgment
HASIL DAN PEMBAHASAN
4.1.
Pemilihan use case scenario berdasarkan literature review Pemilihan use case scenario ini difokuskan pada use case yang memiliki oopurtunity untuk dilakukan refactoring. Berdasarkan hasil pengamatan dan anlisis yang sesuai dengan penjelasan dari paper [2] maka use case scenario yang akan dipilih untuk dilakukan perbaikan melakukan refactoring adalah sebagai berikut (penjelasan lebih detail ada di bagian appendix dari buku ini) : Table 1. Pemilihan use case menggunakan literature review
Paper yang digunakan
Use Case yang bermasalah
Improving the Quality of Requirements with Refactoring [2]
UC-05 Melihat Profil UC-06 Melihat feed Profil UC-12 Konfirmasi Pertemanan UC-26 Konfirmasi Kehadiran UC-35 Melihat Nilai Rapor
Expert 1
Expert 2
Expert 3
UC-04 Mengirim Komentar UC-05 Melihat Profil UC-06 Melihat feed profil UC-12 Konfirmasi Pertemanan UC-26 Konfirmasi Kehadiran UC-27 Berkomentar pada event UC-35 Melihat Nilai Rapor UC-36 Mengirim buku penghubung
UC-04 Mengirim Komentar UC-06 Melihat feed profil UC-12 Konfirmasi Pertemanan UC-26 Konfirmasi Kehadiran UC-27 Berkomentar pada event UC-35 Melihat Nilai Rapor UC-36 Mengirim buku penghubung
UC-04 Mengirim Komentar UC-06 Melihat feed profil UC-12 Konfirmasi Pertemanan UC-26 Konfirmasi Kehadiran UC-27 Berkomentar pada event UC-35 Melihat Nilai Rapor UC-36 Mengirim buku penghubung
4.1.
Pengukuran Kualitas Use Case Scenario Pengukuran kualitas use case scenario ini akan menghasilkan 2 jawaban yaitu kualitas sebelum dilakukan refactoring dan kualitas setelah dilakukan refactoring. Proses pengukuran terdiri dari interview, pengukuran, dan melakukan penarikan kesimpulan. Interview dilakukan berdasarkan kuisioner yang dapat ditemukan pada Appedix kedua pada akhir buku ini. Hasil dari proses interview tersebut adalah seperti pada tabel berikut :
Table 1. Nilai kualitas kebutuhan perangkat lunak pada use case scenario pada setiap kriteria kualitas
Use Case Scenario 4.2.
Pemilihan use case menggunakan expert judgment Selanjutnya untuk lebih memastikan use case scenario mana saja yang harus dilakukan perbaikan, maka langkah selanjutnya adalah dengan menggunakan metode expert judgment. Metode ini dilakukan dengan cara menghubungi beberapa expert yang telah berpengalaman di bidangnya untuk melakukan analisis terhadap use case scenario aplikasi SSN. Untuk memilih use case scenario ini, menggunakan 3 orang expert yang berpengalaman di bidangnya untuk melakukan analisis use case scenario berdasarkan refactoring oppurtunities dan Hasil analisis yang dilakukan oleh seorang expert tersebut menghasilkan beberapa use case scenario yang
Quality Characteristic
Nilai
UC-04 Mengirim Komentar
Correctness Unambiguity Completeness Consistency
1 1 1 0
UC-06 Melihat Feed Profil
Correctness Unambiguity Completeness Consistency
0 0 0 1
UC-12 Konfirmasi Pertemanan
Correctness Unambiguity
0 0
6
UC-26 Konfirmasi Kehadiran
UC-27 Berkomentar pada event
UC-35 Melihat Nilai Rapor
UC-36 Mengirim Buku Penghubung
Completeness
1
Consistency
0
Setelah didapatkan hasil IRQ, pengukuran dilanjutkan dengan mengalikan setiap nilai karakteristik kualitas dengan nilai bobot yang diberikan oleh pihak expert :
Correctness Unambiguity Completeness Consistency
0 0 1 1
Table 3. Hasil perhitungan Individual Requirement Quality yang telah diberikan bobot
Correctness Unambiguity Completeness Consistency
1 1 1 0
Correctness Unambiguity Completeness Consistency
0 0 0 1
Correctness Unambiguity Completeness Consistency
1 0 1 1
Hasil nilai didapatkan dari questionnaire yang dilakukan pihak expert. Pihak expert menilai 7 Use Case dengan melihat 4 kriteria kualitas. Masing – masing kriteria kualitas memiliki nilai 1 dan 0. Apabila kriteria kualitas bernilai 1 maka kualitas dari use case tersebut telah terpenuhi, dan apabila 0 maka use case tersebut tidak memenuhi kriteria kualitas. Hasil data dari interview tersebut dimasukkan dalam formula 4 karakteristik kualitas. Berikut adalah proses memasukkan data hasil interview tersebut dalam rumus 4 karakteristik kualitas. Table 2. Proses Pengukuran kualitas kebutuhan perangkat lunak
No.
Quality Characteristic
IRQ (Individual Requirements Quality)
1. 2. 3. 4.
Correctness Completeness Consistency Unambiguity
0,43 0,71 0.57 0,29
Bobot
IRQ*Bobot
1,5 1 1 0,5 Jumlah
0,645 0,71 0,57 0,145 2,07
Setelah mendapatkan nilai hasil perkalian dengan bobot pada setiap karakteristik kualitas, maka selanjutnya adalah mencari rata – rata dari nilai setiap karakteristik kualitas. Dengan begitu didapatkan hasil Requirements Quality seperti berikut : Requirements Quality =
Equation 1. Hasil perhitungan Requirement Quality
Berdasarkan range pada kualitas kebutuhan perangkat lunak yang telah ditetapkan pada proses kuesioner dan diskusi dengan para expert, nilai hasil pengukuran Requirements Quality tersebut menunjukkan hasil sebesar 39% yang dapat dinyatakan kurang memenuhi kualitas. Pada gambar tersebut dapat dilihat dengan jelas perbedaan antara nilai sempurna dari tiap karakteristik kualitas dan nilai setelah pengukuran 4.2.
Proses Refactoring Proses refactoring dilakukan berdasarkan hasil analisis dan pengukuran dari use case scenario pada aplikasi SSN. Hasil analisis yang berupa use case scenario pada aplikasi SSN yang bermasalah kemudian dicocokkan dengan langkah-langkah perbaikan yang terdapat dalam metode refactoring : • UC-04 Mengirim komentar
Pada proses pengukuran 4 karakteristik kualitas tersebut diperoleh hasil Individual Requirements Quality (IRQ). IRQ mempresentasikan kualitas dari setiap karakteristik yang ada yaitu berupa rata – rata dari keseluruhan nilai kualitas karakteristik yang telah didapatkan dari hasil kuesioner.
Permasalahan : Penggunaan kata pelanggan pada actor tidak konsisten dengan yang lainnya Oppurtunities : Naming Problem Refactoring : Rename Requirement Solusi : Mengubah kata pelanggan sesuai dengan konteks yang lainnya Motivation : Pada paper [2] menjelaskan bahwa penggunaan nama yang
7 baik akan membuat pemahaman dan komunikasi menjadi lebih mudah bagi para tim pengembang. Mekanisme : 1) Pilih requirement yang akan diubah 2) Ubah bagian dari requirement tersebut yang perlu dirubah / disesuaikan 3) Sesuiakan konten dari requirement yang telah dirubah Hasil : Merubah kata pelanggan pada actor menjadi pengguna sehingga sesuai dengan konten yang ada pada UC-04 Mengirim komentar •
UC-36 Mengirim buku penghubung Permasalahan : Penggunaan kata pelanggan pada actor tidak konsisten dengan yang lainnya Oppurtunities : Naming Problem Refactoring : Rename Requirement Solusi : Mengubah kata pelanggan sesuai dengan konteks yang lainnya Motivation : Pada paper [2] menjelaskan bahwa penggunaan nama yang baik akan membuat pemahaman dan komunikasi menjadi lebih mudah bagi para tim pengembang. Mekanisme : 1) Pilih requirement yang akan diubah 2) Ubah bagian dari requirement tersebut yang perlu dirubah / disesuaikan 3) Sesuiakan konten dari requirement yang telah dirubah Hasil : Merubah kata pelanggan pada actor menjadi pengguna sehingga sesuai dengan konten yang ada pada UC-36 Mengirim komentar
Proses selanjutnya adalah mengukur kembali kualitas dari use case scenario yang telah di refactoring berdasarkan 4 kriteria kualitas yaitu Correctness, Completeness, Consistency dan Non-Ambiguity. Hasil nilai didapatkan dari questionnaire yang dilakukan pihak expert. Pihak expert menilai 7 Use Case dengan melihat 4 kriteria kualitas. Masing – masing kriteria kualitas memiliki nilai 1 dan 0. Apabila kriteria kualitas bernilai 1 maka kualitas dari use case tersebut telah terpenuhi, dan apabila 0 maka use case tersebut tidak memenuhi kriteria kualitas. Hasil data dari interview tersebut dimasukkan dalam formula 4 karakteristik kualitas. Berikut adalah proses memasukkan data hasil interview tersebut dalam rumus 4 karakteristik kualitas.
Table 4. Proses Pengukuran kualitas kebutuhan perangkat lunak
Pada proses pengukuran 4 karakteristik kualitas tersebut diperoleh hasil Individual Requirements Quality (IRQ). IRQ mempresentasikan kualitas dari setiap karakteristik yang ada yaitu berupa rata – rata dari keseluruhan nilai kualitas karakteristik yang telah didapatkan dari hasil kuesioner. Setelah didapatkan hasil IRQ, pengukuran dilanjutkan dengan mengalikan setiap nilai karakteristik kualitas dengan nilai bobot yang diberikan oleh pihak expert :
Table 5. Hasil perhitungan Individual Requirement Quality yang telah diberikan bobot
No .
Quality Characteris tic
1.
Correctnes s Completen ess Consistenc y Unambigui ty
2. 3. 4.
IRQ (Individual Requireme nts Quality) 1
Bobot
IRQ*Bob ot
1,5
1,5
1
1
1
1
1
1
1
0,5
0,5
Jumla h
4
Setelah mendapatkan nilai hasil perkalian dengan bobot pada setiap karakteristik kualitas, maka selanjutnya adalah mencari rata – rata dari nilai setiap karakteristik kualitas. Dengan begitu didapatkan hasil Requirements Quality seperti berikut : Requirements Quality =
Equation 2. Hasil perhitungan Requirement Quality
Berdasarkan hasil pengukuran kebutuhan perangkat lunak pada use case scenario aplikasi SSN yang telah diperbaiki menggunakan refactoring dan bobot yang diberikan oleh expert, maka nilai hasil pengukuran Requirements Quality tersebut menunjukkan hasil sebesar 100 % yang dapat dinyatakan berkualitas. Berikut adalah grafik perbandingan antara kualitas use case scenario sebelum diperbaiki menggunakan refactoring dengan kualitas use case scenario setelah dilakukan refactoring.
8 mengingat tujuan dari refactoring sendiri adalah untuk mempermudah sebuah use case untuk dipahami dan dimengerti.
VI.
V.
KESIMPULAN & SARAN
A. Kesimpulan Simpulan yang dapat diambil dari pengerjaan tugas akhir ini adalah sebagai berikut : 1. Berdasarkan pengukuran kondisi awal dari use case scenario dari aplikasi SSN menghasilkan kualitas sebesar 50% yang menunjukkan bahwa kualitas perangkat lunak aplikasi SSN sebelum diperbaiki masih rendah 2. Berdasarkan perbaikan yang dilakukan menggunakan refactoring maka dapat disimpulkan adanya peningkatan kualitas dari use case scenario aplikasi SSN sebesar 50% menjadi 100% 3. Setelah menggunakan refactoring use case scenario aplikasi SSN bertambah menjadi 6 use case hasil dari perbaikan menggunakan refactoring 4. Pengukuran kualitas menggunakan Metrics SQuaRE sangat membantu dalam mengetahui sejauh mana kualitas dari sebuah kebutuhan perangkat lunak. B. Saran Saran yang diharapkan dapat dikembangkan di masa mendatang adalah: 1. Sebaiknya kualitas dalam pembuatan use case skenario perlu diperhatikan lagi karena masih banyak terdapat beberapa use case skenario yang tidak sesuai dengan kondisi sistem yang ada sehingga akan menyebabkan kesulitan dalam pengembangan aplikasi SSN selanjutnya. 2. Proses refactoring telah selesai dilakukan apabila sebuah pemrograman telah di uji coba menggunakan test case untuk memastikan bahwa kode pemrograman yang telah di refactoring tidak mengubah perilaku sistem secara keseluruhan. Dikarenakan refactoring kali ini digunakan pada dokumen yang tidak bisa dilakukan uji coba (tes case) maka dibutuhkan penelitian lebih lanjut untuk memastikan bahwa dengan refactoring tidak akan merubah perilaku sistem secara keseluruhan
DAFTAR PUSTAKA
[1] Gallin, Daniel. Software Quality Assurance from Theory to Implementation. Edinburgh Gate : Pearson Education, 2004. [2] Improving The Quality of Requirements with Refactoring. Ramos, Ricardo, et al., et al. 2009. [3] Common Requirements Problems, Their NegativeConsequences, and the Industry Best Practices to Help Solve Them. Firesmith, Donald. s.l. : ETH Zurich, 2007, Vol. 6. [4] Kerievsky, Joshua. Refactoring to Patterns. s.l. : Addison Wesley, 2005. [5] Lyytinen, Kalle, et al., et al. Design Requirement Engineering: A Ten-Year Perspective. Ohaio : Springer, 2009. [6] Chapter 2 : Software Requirements Guide to the software engineering body of knowledge. Abran, Alain, et al., et al. s.l. : IEEE Computer Science Press, 2007. [7] Writing Effective Use Case. Cockburn, Alistair. s.l. : Addison-Wesley, 2001. [8] Managing Requirements & Improving Quality. Roy, Shambavi. s.l. : TraceCloud, 2009. [9] Improving Requirements Engineering by Quality Modelling - A Quality-Based Requirements Engineering Framework. Donzelli, Paolo and Bresciani, Paolo. 2009. [10] Suryn, Witold and Abran, Alain. 2003. ISO/IEC SQuaRE. The second generation of standards for software product quality. [11] Essado, Marcelo and Ambrosio, Ana Maria. A Requirement Metric Applied on the ITASAT-1:A Small Technological Sattelite. [12] Software Engineering. Sommerville, I. s.l. : Pearson Education, 2004. [13] Use Cases and Aspects - Working Seamlessly Together. Jacobson, Ivar. Zurich : ETH Zurich, 2003.
[14] The Three Cs of Requirements: Correctness, Completeness,Consistency.Zowghi D., Gervasi V. s1. : University of Technology, Sidney. 2009
