Embed Size (px)
Citation preview
Nabil, Bambang Setiawan,S.Kom,M.T Sistem Informasi, Fakultas Teknologi Informasi, Institut Teknologi Sepuluh Nopember (ITS)
Jl. Arief Rahman Hakim, Surabaya 60111
E-mail: [email protected]
Abstrak- Kebutuhan perangkat lunak merupakan salah satu
faktor penentu keberhasilan dalam membangun sebuah perangkat
lunak. Berdasarkan beberapa penelitian yang ada, baik atau
buruknya sebuah perangkat lunak sangat bergantung pada
kualitas kebutuhan perangkat lunaknya.
Pada sebuah proyek IT seperti School Social Network (SSN),
beberapa permasalahan pada kualitas kebutuhan perangkat lunak
dapat terjadi sewaktu - waktu. Seperti misalnya pada perubahan
kebutuhan perangkat lunak, atau mungkin terjadi hilangnya
salah satu kebutuhan perangkat lunak, atau bahkan perangkat
lunak yang sulit dimengerti.
Permasalahan yang sering terjadi pada kebutuhan
perangkat lunak tersebut, dapat membuat output akhir yang
dihasilkan dari proses development berbeda dengan pendefinisian
kebutuhan fungsional pada awal proyek. Hal tersebut disebabkan
karena perangkat lunak yang dihasilkan pada awal proses
development memiliki kualitas yang kurang baik.
Untuk mengetahui sejauh mana kualitas dari kebutuhan
perangkat lunak , salah satu cara yang dapat dilakukan adalah
dengan melakukan pengukuran. Pengukuran ini didasarkan pada
matriks Requirements Structural Model yang didalamnya berisi 6
karakteristik yang digunakan sebagai tolak ukur pengukurannya.
Hasil akhir dari tugas akhir ini adalah sebuah pengukuran
kualitas terhadap kebuuhan perangkat lunak menggunakan
matriks Requirement Structural Model pada studi kasus aplikasi
School Social Network (SSN). Pengukuran diukur menggunakan
tolak ukur beberapa karakteristik kualitas sehingga output yang
dihasilkan dari matriks ini dapat digunakan sebagai perbaikan
pembangunan aplikasi School Social Network (SSN) selanjutnya.
Selain itu, sebuah aplikasi pengukuran kualitas kebutuhan
perangkat lunak berbasis PHP Codeigniter juga dibuat untuk
memudahkan pengukuran berdasarkan karakteristik kualitas
kebutuhan pernagkat lunak.
Kata kunci : Kualitas kebutuhan perangkat lunak, Kebutuhan
perangkat lunak, School Social Network, SSN, Matriks kualitas
kebutuhan perangkat lunak, Quality Characteristic,
Requirements Structural Model, Aplikasi pengukuran kualitas
kebutuhan perangkat lunak
I. PENDAHULUAN
Pada sebuah proyek IT, kebutuhan perangkat lunak pasti
tidak akan pernah luput dari proses pembangunan perangkat
lunak. Hal tersebut dikarenakan sebuah kebutuhan perangkat
lunak adalah acuan dalam membangun sebuah perangkat
lunak itu sendiri. Proses pembangunan perangkat lunak itu
sendiri sering disebut dengan proses System Development
Life Cycle (SDLC). Pada SDLC, kebutuhan perangkat lunak
berada pada fase System Analysis/Requirement Definition.
Fase tersebut merupakan fase terpenting dalam pembangunan
perangkat lunak. (R M. , 2006)
Namun kenyataanya, kebutuhan perangkat lunak sering
diabaikan sehingga kualitas perangkat lunak yang
dibangunpun tidak tepat sasaran. Kejadian seperti ini sering
terjadi pada proses pembangunan sebuah perangkat lunak.
Padahal idealnya, sebuah perangkat lunak yang baik
membutuhkan kualitas kebutuhan perangkat lunak yang baik
pula.
Untuk mengetahui sejauh mana kualitas kebutuhan
perangkat lunak, sebuah pengukuran kualitas dapat
dilakukan. Namun pengukuran kualitas kebutuhan perangkat
lunak sering diabaikan sehingga kualitas kebutuhan
perangkat lunak menjadi buruk dan output yang
dihasilkanpun menjadi buruk pula.
Pada proyek School Social Network (SSN) pengukuran
terhadap kualitas kebutuhan perangkat lunak belum
dilakukan. Dengan menggunakan beberapa karakteristik
sebagai tolak ukur kualitasnya, pengukuran terhadap
kebutuhan perangkat lunak dapat menjadi lebih efektif dan
terarah.
Pada penelitian kali ini, akan dilakukan pengukuran
sebuah kualitas kebutuhan perangkat lunak pada sebuah studi
kasus applikasi School Social Network (SSN) Al Azhar
Surabaya. Output yang dihasilkan berupa hasil penilaian
pengukuran kualitas kebutuhan perangkat lunak dengan
menggunakan matriks dan aplikasi pengukran kualitas
kebutuhan perangkat lunak berbasis PHP Codeigniter yang
dapat digunakan untuk bahan pertimbangan perbaikan
aplikasi kedepanya.
II. KAJIAN PUSTAKA
A. System Development Life Cycle (SDLC)
System Development Life Cycle adalah sebuah konseptual
model atau sebuah proses yang digunakan pada manajemen
proyek yang mendeskripsikan beberapa tahapan pada
pembuatan sebuah system informasi (Pavel). Beberapa
tahapan tersebut adalah :
1. Project Planning
Pada fase ini para developer harus mempelajari dan
mengetahui apa yang benar – benar mereka inginkan.
Mereka juga dapat mempelajari bagaimana sebuah
perangkat lunak akan berpengaruh pada pengguna
nantinya.
Rancang Bangun Aplikasi Pengukuran Kualitas Kebutuhan
Perangkat Lunak Berdasarkan Matriks Structural Model Studi
Kasus : Aplikasi School Social Network (SSN)
2. System Analysis, Requirement Definition
Setelah membuat perencanaan yang matang dan juga
mengetahui apa saja yang pengguna inginkan, developer
harus mencari tahu beberapa kebutuhan teknis dari
pengguna. Pada fase ini seorang developer membuat
workflow yang berbasis pada keinginan pengguna
tersebut.
3. System Design
Mendeskripsikan beberapa fitur secara lebih detail, seperti
screen layout, business rules, process diagram,
pseudocode dan dokumentasi lainya.
4. Development
Pada fase ini developer membangun perangkat lunak
berdasarkan semua keinginan user dan arsitektur
perencanaan yang telah dibuat pada fase sebelumnya.
5. Integration and Testing
Setelah sebuah perangkat lunak terbangun, developer
akan melakukan pengetestan terhadap setiap komponen
yang telah dibangun pada perangkat lunak tersebut untuk
memastikan seluruh kode benar – benar bekerja.
6. Acceptance, Installation, Deployment
Sebuah perangkat lunak secara utuh telah dibangun pada
fase ini, dan dapat mulai dipublikasikan.
7. Maintenance
Sebuah perangkat lunak yang sudah jadi tidak menjamin
akan bekerja dengan baik. Developer dapat melakukan
monitoring performa perangkat lunak dan juga membuat
pengaturan yang diperlukan.
Tahapan diatas merupakan tahapan standard dari proses
SDLC. Namun disamping itu, beberapa metodologi seperti
Waterfall, Spiral, Joint Application Design (JAD), Agile
Development dll telah diciptakan untuk memudahkan para
developer bekerja berdasarkan proses utama SDLC tersebut.
Pada proses SDLC, kebutuhan perangkat lunak berada
pada fase ke-2. Secara konseptual, fase ini terdiri dari 3
aktivitas :
Eliciting Requirements
Mengidentifikasi beberapa kebutuhan perangkat lunak
dari sumber yang berbeda – beda seperti dokumentasi
proyek, dokumentasi proses bisnis, dan interview kepada
para stakeholder. Terkadang proses ini juga disebut
sebagai Requirements Gathering.
Analyzing Requirements
Penentuan apakah kebutuhan perangkat lunak sudah jelas,
komplit, konsisten dan tidak ambigu.
Dokumentasi
Kebutuhan perangkat lunak juga dapat didokumentasikan
menjadi berbagai template. Biasanya meliputi sebuah list
ringkasan, use cases, atau seperti user specification.
Apabila dilihat lebih seksama, fase pendefinisian
kebutuhan perangkat lunak ini sangatlah penting. Karena fase
ini sangat berpengaruh besar pada fase – fase berikutnya.
Contohnya seperti fase Development, seorang developer
tentunya akan membuat sebuah system berdasarkan
keinginan dari pengguna atau end-user.
B. School Social Network (SSN)
School Social Network adalah salah satu bagian dari
aplikasi SLIMS+ (Sistem Layanan Informasi Manajemen
Sekolah Plus) yang dibangun untuk memberikan layanan
manajemen dan informasi kepada guru, karyawan, musrid
dan orang tua siswa, terkait dengan hal – hal yang
berhunungan dengan sekolah.
Gambar 1 Aplikasi - aplikasi pada SLIMS+
Aplikasi pada SSN memiliki 3 fitur yaitu fitur Siswa,
Guru dan Orang tua 1. Fitur Siswa
Pada Fitur Siswa terdapat beberapa fasilitas seperti :
a. Membuat suatu feed
Dengan fitur siswa ini, siswa dapat mempublikasikan
feed (berita, status, informasi) yang dapat diakses oleh
rekan – rekannya. Bukan hanya siswa, guru pun dapat
memberikan informasi kepada siswa melalui fitur ini.
b. Memanajemen profil
Pada manajemen profil ini, para siswa dapat
mengubah profil yang telah dibuat sebelumnya.
c. Membuat pesan
Merupakan fasilitas pengiriman dan pengelolaan
pesan kepada teman siswa seperti halnya email.
d. Mengelola pertemanan
Merupakan fasilitas untuk menambah, melihat, dan
menghapus teman dalam SSN.
e. Mengelola grup
Merupakan fasilitas yang dapat digunakan oleh siswa
untuk membuat, melihat, menghapus, dan bergabung
dengan suatu grup.
f. Manajemen acara
Dalam fasilitas ini, siswa dapat mengakses informasi –
informasi acara di sekolah mereka.
g. Manajemen Agenda
Dengan manajemen agenda, siswa dapat membuat,
melihat, dan menghapus agenda yang mereka buat.
h. Manajemen Akademik
Melalui fasilitas ini, siswa dapat mengakses nilai,
jadwal, dan kehadiran siswa.
Gambar 2 Fitur pada Siswa
2. Fitur Guru
Fasilitas yang terdapat pada fitur guru hampir sama
dengan siswa. Hanya saja pada Fitur Guru terdapat beberapa
fasilitas – fasilitas yang hanya dapat diakses oleh guru itu
sendiri. Seperti guru memberikan layanan informasi pada
siswa, sehingga siswa hanya dapat membaca informasi
tersebut.
3. Fitur Orang Tua
Sama dengan fitur guru, pada fitur orang tua terdapat
beberapa fasilitas yang hanya dapat diakses oleh orang tua
saja.
Gambar 3 Fitur pada Orang Tua
C. Expert Judgement
Expert judgement adalah sebuah ekspresi seseorang atau
dalam suatu grup untuk mencari satu solusi dan response
mereka dari pengalaman atau pengetahuan atau dari
keduanya. Metode ini sering dipakai pada perusahaan untuk
mencari solusi terbaik dari apa yang mereka lakukan. Salah
satu contoh dari expert judgement adalah Delphi Method.
Metode Delphi adalah sebuah metode peramalan yang
didasarkan pada hasil kuisioner hasil kuisioner yang
dikerjakan oleh para ekspert. Kuisioner dibagikan kepada
beberapa orang dan jawabanya dibagikan lagi kepada ekspert
untuk diperiksa dan dibenarkan. Dengan demikian, jawaban
para ekspert ini dapat disatukan dan hasilnya adalah hasil
yang maksimal. Metode ini merupakan metode yang paling
banyak dipakai pada expert judgement.
D. SQuaRE Matriks
Berdasarkan pada paper (Suryn & Abran, ISO/IEC
SQuaRE. The second generation of standards for software
product quality) proses pengukuran kualitas kebutuhan
perangkat lunak dengan menggunakan Metrics adalah seperti
berikut :
Gambar 4 Proses evaluasi pada sebuah matriks SQuaRE (Suryn &
Abran, ISO/IEC SQuaRE. The second generation of standards for
software product quality)
Berdasarkan gambar diatas, proses pengukuran kualitas
kebutuhan perangkat lunak terdiri dari 4 tahapan pokok yaitu
:
Establish Evaluation Requirements
Fase ini terdiri dari 3 tahapan, pertama yaitu menetapkan
tujuan sebenarnya dari pengukuran yang akan dilakukan,
kedua menetapkan produk yang akan diukur dan ketiga
menetapkan kualiti model.
Output dari fase ini adalah sebuah kebutuhan untuk
pengukuran kebutuhan perangkat lunak.
Specification of the Evaluation
Fase ini terdiri dari pemilihan matriks yang akan
dilakukan untuk pengukuran kualitas kebutuhan perangkat
lunak, lalu pembuatan rating level, dan membuat kriteria
penilaian yang digunakan untuk dibandingkan dengan output
penilaian.
Output dari fase ini adalah sebuah matriks, rating level,
dan kriteria yang ditentukan untuk dibandingkan dengan
output Requirement Quality.
Design of the Evaluation
Berisi tentang perencanaan pengukuran secara
menyeluruh seperti tools yang akan dipakai, biaya
pengukuran, jadwal pengukuran, metode reporting, dll.
Execution of the Evaluation
Ini merupakan fase final dari keseluruhan fase, yaitu
terdiri dari pengukuran karakteristik pruduk, lalu
pembandingan hasil penghitungan karakteristik dengan
kriteria yang telah ditentukan pada fase “Specification of the
evaluation”. Dan yang terakhir menilai hasil akhir dari proses
evaluasi tersebut.
E. Kebutuhan perangkat lunak pada aplikasi School Social
Network
Dalam pembuatan sebuah perangkat lunak tentu
memerlukan sebuah kebutuhan sebagai acuan untuk proses
development-nya. Salah satu kebutuhan perangkat lunak yang
umum dipakai adalah kebutuhan perangkat lunak use case.
Pada School Social Network, use case telah dibuat, yaitu
berupa diagram dan naratif. Sedangkan yang dipakai untuk
pengukuran kali ini adalah use case naratif dari aplikasi SSN.
Berikut ini adalah deskripsi dari setiap use case naratif yang
ada pada aplikasi School Social Network (SSN).
No. Nama Use
Case
Deskripsi
Aktifitas
Login
1. Flow of event
login.
Use case ini digunakan
untuk melakukan
authentikasi terhadap user
yang akan masuk, dan disini
juga akan diatur bagaimana
hak akses masing-masing
pengguna.
Aktifitas Wall
2. Flow of event
membuat
status.
Use case untuk melakukan
proses pembuatan status.
3. Flow of event
membuat pesan
dinding.
Selain status, pengguna juga
bisa membuat pesan dinding
yang ditujukan kepada wall
dinding teman.
4. Flow of event
mengirim
komentar.
Use case untuk memberikan
komentar pada sebuah
status.
5. Flow of event
melihat profil.
Use case untuk melihat
profil dari pengguna lain
yang terdapat dalam aplikasi
social network ini ataupun
profil dari aktor itu sendiri.
6. Flow of event
melihat feed
profil.
Use case untuk melihat
status yang dibuat dan
kiriman wall yang telah
dilakukan oleh pengguna
lain pada wall aktor tersebut.
7. Flow of event
melihat feed.
Use case untuk melihat
aktivitas kiriman dari
pengguna lain yang menjadi
teman aktor.
8. Flow of event
menghapus
komentar.
Use case untuk menghapus
komentar pada status.
Komentar yang bisa dihapus
hanya komentar yang
memiliki id pemberi
komentar sama dengan id
yang sedang login.
Aktifitas
Pertemanan
9. Flow of event
melihat daftar
teman.
Use case untuk melihat
daftar teman.
10. Flow of event
menghapus
teman.
Use case untuk menghapus
teman.
11. Flow of event
melihat daftar
permintaan
teman.
Use case untuk melihat
daftar permintaan
pertemanan.
12. Flow of event
konfirmasi
pertemanan.
Use case untuk
mengonfirmasi permintaan
pertemanan yang telah
diajukan oleh pengguna lain.
13. Flow of event
meminta
pertemanan.
Use case untuk
mengirimkan permintaan
pertemanan kepada
pengguna lain.
14. Flow of event
mencari
pengguna lain.
Use case untuk mencari
pengguna yang terdapat
dalam social network.
Aktifitas
Pesan
15. Flow of event
menghapus
pesan.
Use case untuk menghapus
pesan yang telah dibuat
actor.
16. Flow of event
melihat pesan.
Use case untuk melihat
daftar pesan.
17. Flow of event
mengirim
pesan.
Use case untuk mengirim
pesan baru kepada pengguna
lain.
18. Flow of event
hapus group.
Dalam group terdapat
thread, member, dan
komentar dari thread.
Penghapusan group, secara
otomatis juga akan
menghapus thread, member,
dan komentar daru group
yang bersangkutan. Hanya
admin yang bisa menghapus
group. Hal ini bertujuan
untuk moderasi konten pada
group
19. Flow of event
lihat daftar
group.
Use case untuk melihat
group. Di dalam group
terdapat 3 jenis: group
sekolah, ekstrakulikuler dan
kelas.
20. Flow of event
melihat daftar
thread.
Use case untuk melihat
daftar list Thread. Di dalam
Thread merupakan materi
pembicaraan yang bisa di
create oleh member dalam
suatu group
21. Flow of event
membuat
thread.
Use case untuk membuat
thread baru pada suatu
group.
22. Flow of event
hapus thread.
Use case untuk menghapus
thread pada suatu group.
Thread hanya bisa dihapus
oleh admin. Hanya admin
yang bisa menghapus
thread. Hal ini bertujuan
untuk moderasi konten pada
group
Aktifitas
Notifikasi
23. Flow of event
melihat
notifikasi.
Use case untuk melihat
pemberitahuan yang
ditujukan pada aktor
tersebut.
24. Flow of event
menghapus
notifikasi.
Use case untuk menghapus
notifikasi yang ada pada
daftar notifikasi.
Aktifitas
Event
25. Flow of event
melihat daftar
event.
Use case untuk melihat
daftar dari event.
26. Flow of event
konfirmasi
kehadiran.
Use case untuk
mengonfirmasi kehadiran
pengguna terhadap suatu
event yang akan diadakan.
27. Flow of event
berkomentar
Use case untuk memberikan
komentar pada sebuah
pada event. event.
28. Flow of event
membuat
event.
Use case untuk membuat
event baru.
29. Flow of event
mengundang.
Use case untuk mengundang
teman dalam event.
30. Flow of event
menghapus
event.
Use case untuk menghapus
event.
Aktifitas
Agenda
31. Flow of event
membuat
agenda.
Use case untuk membuat
agenda baru untuk masing-
masing pengguna..
32. Flow of event
melihat agenda.
Use case untuk melihat
daftar agenda.
33. Flow of event
event
menghapus
agenda.
Use case untuk menghapus
agenda yang telah dibuat.
34. Flow of event
merubah
agenda.
Use case untuk merubah
agenda yang telah dibuat.
Aktifitas
Akademik
35. Flow of event
nilai rapor.
Use case untuk mengetahui
nilai rapor dari seorang
murid, rapor murid berbeda
antara TK dan SD. Pada
rapor SD terdapat 3 tipe,
yaitu rapor pengembangan
diri, cambridge dan mata
pelajaran.
36. Flow of event
mengirim buku
penghubung.
Use case untuk
mengirimkan buku
penghubung, sesuai dengaan
kolom buku penghubung
yang telah disediakan.
37. Flow of event
melihat jadwal.
Use case untuk melihat
jadwal bagi seorang murid.
F. Quality Characteristic
Pada matriks kali ini distandardkan seperti halnya pada
paper (Essado & Ambrosio). Matriks ini sedikit berbeda
dengan Matriks SquaRE, pada tahapan “Specification of the
Evaluation”, Matriks ini tidak menggunakan penetapan rating
level (Establish rating levels for Metrics), sehingga dapat
langsung dilanjutkan pada tahapan proses selanjutnya.
Matriks yang dipakai kali ini bernama Requirement
Structural Model yang diciptakan oleh (R H. , 1993) yang
mengasumsikan untuk setiap karakteristik kebutuhan
perangkat lunak mempunyai nilai 0 dan 1. Hal tersebut
bergantung dengan apakah seluruh kebutuhan perangkat
lunak mempunyai kecacatan 0 atau tidak 1. Langkah –
langkah untuk mencari nilai tersebut adalah seperti berikut :
a. Mengklasifikasi kriteria berdasarkan karakteristik
Matriks
b. Menetapkan masing – masing element yang
terdidentifika\si pada langkah berikutnya.
c. Menganalisa setiap kebutuhan perangkat lunak
berdasarkan 10 karakteristik dengan nilai 1 apabila
betul dan 0 apabila salah.
d. Mengevaluasi setiap kebutuhan perangkat lunak pada
langkah (a) terhadap 10 karakteristik dengan menilai 1
apabila memuaskan dan 0 apabila tidak memuaskan.
e. Menghitung Requirements Quality dengan membagi
Individual Requirement Quality dengan jumlah
seluruh kebutuhan perangkat lunak.
Pada paper (R H. , 1993) kualitas kebutuhan perangkat
lunak distandardkan pada karakteristik – karakteristik berikut
:
No. Quality
Characteris
tics
Definisi Penjelasan
1. Correctness Apakah ada
atau
tidaknya
kesalahan
pada
kebutuhan
perangkat
lunak.
Seberapa banyak
jumlah error yang
ditemukan pada use
case scenario?
2. Completenes
s
Semua
kebutuhan
perangkat
lunak yang
berisi semua
informasi
tentang
kendala dan
kondisi yang
memungkink
an proses
Bagaimana
kelengkapan
kebutuhan
perangkat lunak?,
Seberapa banyak
jumlah kebutuhan
perangkat lunak
yang masih harus
ditambah?
pelaksanaan
atau proses
verifikasi.
3. Consistency Kebutuhan
perangat
lunak tidak
bertentangan
satu sama
lain.
Apakah
maksud/tujuan dari
kebutuhan
perangkat lunak
saling kontradiktif
antara satu dengan
lainya? Seberapa
banyak jumlah
kebutuhan
perangkat lunak
yang tidak
berkaitan?
4. Clarity Kebutuhan
perangkat
lunak harus
mudah
dimengerti
tanpa
menggunaka
n analysis
semantik
Apakah
user/developer
dapat mengerti
dengan mudah
kebutuhan
perangkat lunak?
Berapa banyak
kebutuhan
perangkat lunak
yang masih perlu
dijelaskan lagi?
5. Non-
ambiguity
Kebutuhan
perangkat
lunak harus
mudah
dimengerti
dengan tidak
lupa
memerhatika
n kata – kata
yang
digunakan
pada
kebutuhan
perangkat
lunak
Berapa banyak
jumlah kebutuhan
perangkat lunak
yang memiliki kata
– kata yang susah
dimengerti?
6. Connectivity Apakah satu
kebutuhan
perangkat
lunak saling
terkait satu
Apakah use case
scenario saling
berkaitan antara
satu dengan lainya?
Berapa banyak use
sama lain
case yang masih
bertentangan satu
dengan lainya?
7. Singularity Kebutuhan
perangkat
lunak yang
kurang jelas
dapat
dinyatakan
sebagai 2
atau lebih
kebutuhan
perangkat
lunak yang
memiliki arti
yang
berbeda
Apakah kebutuhan
perangkat lunak
masih harus
didetailkan lagi?
Seberapa banyak
perangkat lunak
yang harus di
explode dan
didetailkan menjadi
kebutuhan
perangkat lunak
baru?
8. Testability Adanya
proses dan
objek yang
dapat
digunakan
untuk
memverifika
si bahwa
kebutuhan
perangkat
lunak telah
terpenuhi
Apakah kebutuhan
perangkat lunak
dapat dengan
mudah di test dan
digunakan?
9. Modifiability Beberapa
perubahan
pada
kebutuhan
perangkat
lunak dapat
dibuat
dengan baik
dan
konsisten
untuk
memenuhi
karakteristik
kebutuhan
perangkat
lunak
sebelumnya
Apakah kebutuhan
perangkat lunak
dapat dengan
mudah dimodifikasi
untuk kedepanya?
10. Feasibility Kelayakan
kebutuhan
perangkat
lunak untuk
diimplement
asikan pada
proyek.
Apakah kebutuhan
perangkat sudah
lunak layak untuk
digunakan?
Namun pada pengukuran kali ini hanya di ukur
berdasarkan beberapa karakteristik saja. Yaitu Non-
Ambiguity, Correctness, Consistency, Clarity, Connectivity
dan Singularity. Hal tersebut dikarenakan karena pada 4
karakteristik kualitas kebutuhan perangkat lunak lainya
mengacu pada kualitas SRS document.
Hasil pada masing – masing karakteristik dapat
disubtitusi kepada table berikut.
Kebutuhan
perangkat
lunak
Quality
Characteristic
Interval
1 Ambiguity 1(Permisalan)
Correctness 0
Modifiable 0
Clarity 1
2 Ambiguity 1
Correctness 1
Modifiable 0
Clarity 0
3, 4, dst…
Beberapa karakteristik tersebut diukur dengan
melakukan survey pada beberapa user serta melakukan expert
judgment. Setelah didapatkan nilai dari masing – masing
karakteristik, proses pengukuran dapat dilanjutkan dengan
memasukkan jumlah nilai masing – masing karakteristik pada
rumus – rumus berikut :
Quality
Characteristic
Jumlah
Nilai 1
Jumlah
Nilai 0
Rumus Hasil/
IRQ
Non-Ambiguity 40
(Permis
alan)
7
(Permis
alan)
Correctness 35 12
Consistency 33 14
Clarity 42 5
Connectivity
Singularity
Jumlah IRQ =
Dari jumlah IRQ dapat dihitung jumlah dari
RQ(Requirements Quality)
RQ =
G. Bahasa Pemrograman PHP
Menurut (Widigdo, 2003) PHP adalah bahasa
pemrograman yang menyatu dengan HTML dan dijalankan
pada server side. Artinya semua sintaks yang kita berikan
akan sepenuhnya dijalankan pada server sedangkan yang
dikirimkan ke browser hanya hasilnya saja.
Pada sumber lain (Pionermedia, 2013) disebutkan
bahwa PHP: Hypertext Preprocessor adalah bahasa skrip
yang dapat ditanamkan atau disisipkan ke dalam HTML. PHP
banyak dipakai untuk memrogram situs web dinamis. PHP
dapat digunakan untuk membangun sebuah CMS.
Menurutnya, pemrograman PHP memiliki beberapa
keunggulan yaitu :
1. Bahasa Pemrograman PHP mendukung komunikasi
dengan layanan seperti protocol IMAP, SNMP, NNTP,
POP3 bahkan HTTP.
2. Security: Tingkat keamanan yang cukup tinggi dan
stabil.
3. Access: Akses ke sistem Database yang lebih fleksibel,
seperti MySQL.
4. Easy & Faster: Dalam sisi pemahamanan, PHP adalah
bahasa pemrograman yang paling mudah karena
memiliki referensi yang banyak dan berkecepatan
tinggi.
5. Cross platform yaitu PHP dapat berjalan lintas platform,
yaitu dapat berjalan dalam sistem operasi seperti
Windows, Linuz, MacOS dan OS lainnya dan web
server apapun.
6. Free: Dapat digunakan secara gratis.
7. Termasuk bahasa yang embedded, yakni dapat
diletakkan dalam tag HTML.
8. Termasuk jenis server side programming, sehingga
kode asli/source code PHP tidak dapat dlihat di browser
pengguna, yang terlihat hanya kode dalam format
HTML.
9. Dapat memanfaatkan sumber-sumber aplikasi yang
dimiliki oleh server misalnya untuk keperluan
Database connection.
10. PHP dapat melakukan semua aplikasi program CGI,
seperti mengambil nilai form, menghasilkan halaman
web yang dinamis, mengirimkan dan menerima cookies.
11. On The Fly: PHP sudah mendukung on the fly, artinya
dengan php anda dapat membuat document text, Word,
Excel, PDF, menciptakan image dan flash, juga
menciptakan file-file seperti zip, XML, dan banyak lagi.
12. Dalam sisi pengembangan lebih mudah, karena
banyaknya milis - milis dan developer yang siap
membantu dalam pengembangan.
Namun disamping itu, PHP memiliki beberapa
kekurangan seperti :
1. Tidak detail untuk pengembangan skala besar
2. Tidak memiliki sistem pemrogaman berorientasi objek
yang sesungguhnya.
3. Tidak bisa memisahkan antara tampilan dengan logic
dengan baik.
4. PHP memiliki kelemahan security tertentu apabila
programmer tidak jeli dalam melakukan pemrogaman
dan kurang memperhatikan isu konfigurasi PHP.
5. Kode PHP dapat dibaca orang, dan kompilasi hanya
dapat dilakukan dengan tool yang mahal dari Zend.
A. Codeigniter
Framework yang digunakan dalam pembuatan aplikasi
pengukuran kualitas kebutuhan perangkat lunak adalah
Codeigniter yaitu sebuah aplikasi open source yang berupa
framework dengan model MVC (Model, View, Controller)
untuk membangun aplikasi dinamis dengan menggunakan
PHP.
1. View, merupakan bagian yang menangani presentation
logic. Pada suatu aplikasi web bagian ini biasanya
berupa file template HTML, yang diatur oleh controller.
2. Model, biasanya berhubungan langsung dengan
database untuk memanipulasi data (insert, update,
delete, search), menangani validasi dari bagian
controller, namun tidak dapat berhubungan langsung
dengan bagian view.
3. Controller, merupakan bagian yang mengatur hubungan
antara bagian model dan bagian view, controller
berfungsi untuk menerima request dan data dari user
kemudian menentukan apa yang akan diproses oleh
aplikasi.
B. MySQL
Sedangkan untuk manajemen database, aplikasi
pengukurang kualitas kebutuhan perangkat lunak
menggunakan MySQL. Yaitu sebuah perangkat lunak sistem
manajemen basis data SQL (bahasa Inggris: database
management system) atau DBMS yang multithread, multi-
user, dengan sekitar 6 juta instalasi di seluruh dunia.
III. Hasil dan Analisa
A. Penetapan kebutuhan pengukuran
Tujuan dari proses pengukuran kualitas kebutuhan
perangkat lunak ini adalah mencari nilai rata - rata kualitas
kebutuhan perangkat lunak berdasarkan 6 karakteristik
kualitas. 6 karakteristik kualitas ini mengacu pada Quality
model yang digunakan pada paper (Essado & Ambrosio).
Namun pada penelitian kali ini hanya digunakan 6
karakteristik kualitas saja karena 4 karakteristik kualitas
lainya mengacu pada kualitas dokumen Software
Requirements Specifications (SRS).
B. Spesifikasi Pengukuran
Matriks yang digunakan adalah matriks Requirements
Structural Model. Proses yang dilakukan padamatriks ini
hampir sama dengan proses yang dilakukan pada matriks
SQuaRE, namun terdapat beberapa langkah yang tidak
dilalui.
Sedangkan Quality Model yang diapakai mengacu pada
paper (Essado & Ambrosio). Dalam paper tersebut terdapat
10 karakteristik kualitas. Namun kali ini akan dipakai 6
kualitas karakteristik saja, karena dari 10 karakteristik
kualitas pada paper tersebut 4 diantaranya mengacu pada
kualitas Software Requirements Specification(SRS).
Sedangkan pada penelitian kali ini lebih fokus pada
kebutuhan perangkat lunak fungsional saja.
C. Mendesain pengukuran
Sebelum melakukan pengukuran, pembuatan evaluation
plan diperlukan untuk melihat secara jelas gambaran proses
pengukuran. Evaluation plan telah dibuat dan dapat dilihat
pada bab Appendix pada akhir buku Tugas Akhir.
D. Eksekusi Pengukuran
Proses pengukuran terdiri dari interview, yaitu
memberikan beberapa questionnaire pada experts. Dalam
questionnaire tersebut terdapat pertanyaan untuk menganalisa
37 use case berdasarkan pada 6 karakteristik kualitas. Masing
– masing jawaban karakteristik kualitas tersebut memliki
nilai 1 dan 0. Yaitu nilai 1 apabila use case memebuhi
persyaratan karakteristik dan 0 apabila use case tidak
memenuhi persyaratan karakteristik.
Hasil data dari interview tersebut dimasukkan dalam
formula 6 karakteristik kualitas. Berikut adalah proses
memasukkan data hasil interview tersebut dalam rumus 6
karakteristik kualitas :
Quality
Characteristic
Jumlah
Nilai 1
Jumlah
Nilai 0
Rumus Hasil
/IRQ
Correctness 2 35
0,05
Clarity 24 13
0,64
Consistency 34 3
0,91
Non-
Ambiguity
31 6
0,83
Singularity 36 1
0,98
Connectivity 33 4
0,89
Jumlah IRQ = 4,3
Pada proses pengukuran 6 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 proses interview.
Setelah didapatkan hasil IRQ, pengukuran dilanjutkan
dengan mengalikan setiap nilai karakteristik kualitas dengan
nilai bobot yang didapat dari survey pada expert :
No. Quality
Characteristic
IRQ
(Individual
Requirements
Quality)
Bobot IRQ*Bob
ot
1. Correctness 0,05 0,95 0,04
2. Clarity 0,64 0,70 0,44
3. Consistency 0,91 0,75 0,68
4. Non-
Ambiguity
0,83 0,70 0,58
5. Singularity 0,98 0,50 0,49
6. Connectivity 0,89 0,40 0,35
Jumlah 2,58
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 :
= = 0,43
Berdasarkan range pada kualitas kebutuhan perangkat
lunak yang telah ditetapkan pada proses interview. Nilai hasil
pengukuran Requirements Quality tersebut menunjukkan
hasil cukup yaitu 43% dari nilai sempurna.
Gambar berikut ini menunjukkan perbandingan antara
nilai sempurna dari karakteristik kualitas dengan hasil
pengukuran :
Pada gambar tersebut dapat dilihat dengan jelas
perbedaan antara nilai sempurna dari tiap karakteristik
kualitas dan nilai setelah pengukuran.
Correctness
Dari hasil pengukuran terlihat bahwa nilai kebenaran
dari kebutuhan perangkat lunak SSN sangat minim sekali.
Artinya, hampir semua dari use-case yang dianalisa adalah
salah. Kesalahan tersebut kebanyakan berupa kesalahan
dalam penulisan. Hal ini sangat berpengaruh pada satu
karakteristik kualitas lainya yaitu “Clarity”.
Clarity
Karena banyaknya kesalahan yang ada pada kebutuhan
perangkat lunak, maka hal tersebut berpengaruh pada nilai
kejelasan kebutuhan perangkat lunak tersebut. Apabila dilihat
pada grafiknya, nilai kejelasan menjadi ikut menurun
dikarenakan nilai kebenaran yang sangat minim. Hal ini
disebabkan karena cara penulisan yang tidak baik atau
banyaknya kata – kata yang tidak jelas di dalamnya.
Consistency
Dari segi kualitas Consistency isi dari semua use case
sudah konsisten dan benar. namun terdapat beberapa use case
yang mungkin perlu dijelaskan tujuannya untuk membuat use
case tersebut lebih konsisten.
Non Ambiguity
Salah satu factor yang berpengaruh pada nilai kebenaran
dan kejelasan adalah kata – kata ambigu yang ditemukan
pada use case. Dalam analisa kali ini, kata – kata ambigu
masih jarang ditemukan. Sehingga hasil analisa, nilai dari
ketidak ambiguan menjadi tinggi.
Singularity
Use case yang dianalisa sudah cukup detil, hal ini dilihat
dari nilainya yang paling tinggi dan mendekati nilai
sempurna. Dengan demikian use case tidak perlu
dibreakdown atau diperjelas lagi menjadi use case baru.
Namun apabila dilihat kembali pada pembobotan, nilai dari
Singularity tidak terlalu tinggi. Artinya nilai tersebut tidak
berperan besar pada Requirements Quality.
Connectivity
Secara keseluruhan, use case sudah saling berhubungan
satu sama lainya. Namun masih terdapat use case yang masih
perlu penjelasan lebih detil keterkaitanya dengan use case
lainya. Karakteristik kualitas ini memiliki nilai bobot yang
paling rendah. Sehingga nilainya yang tinggi tidak terlalu
berpengaruh pada nilai Requirements Quality.
E. Pembuatan Aplikasi
Aplikasi dibangun menggunakan framework codeigniter
dengan bahasa pemrograman php. Aplikasi ini adalah
aplikasi pengukuran kualitas kebutuhan perangkat lunak
berbasis web yang dapat digunakan oleh computer mana saja,
asalkan terdapat koneksi internet yang tersambung langsung
dengan komputer tersebut.
Namun sayangnya aplikasi ini masih belum
dikembangkan untuk mobile-view. Sehingga apabila diakses
pada perangkat keras mobile/tab, aplikasi ini akan
memunculkan tampilan yang sama seperti di komputer. Jalan
koneksi yang terjadi dalam mengakses aplikasi ini adalah :
Alur proses pada akses aplikasi adalah dimulai dari user
yang mencoba mengakses halaman pada perangkat keras
yang dimilikinya. Kemudian request tersebut
dikomunikasikan pada server melalui internet. Dari server
request dilanjutkan ke database. Kemudian database
memberikan data yang di telah direquest pada server dan
mengkomunikasikanya lagi pada perangkat keras yang
dimiliki oleh user.
A. Use Case Diagram
Use Case Login
uc Login
System
User
Login
Register
Seperti layaknya aplikasi berbasis web lainya, pada
aplikasi pengukuran kualitas kebutuhan perangkat lunak, user
juga dapat memiliki wewenang untuk login dan register.
Register yaitu membuat akun baru untuk menjadi salah satu
member dari aplikasi pengukuran kebutuhan perangkat lunak.
Sedangkan login sebagai pintu gerbang untuk memasuki
aplikasi dengan mencocokan username dan password yang
diinputkan user dengan data yang sudah terdaftar pada
database aplikasi.
Projects
uc Proje...
System
user
Manage Project
Show Result
Show Project Use
cases
Show All av ailable
Projects
Create Project
Edit Project
Delete Project
«extend»
«extend»
«extend»
Pada aplikasi ini, seorang user dapat menginputkan
sebuah project yang berisi beberapa use case didalamnya.
Use case yang ada pada project ini nantinya akan melalui
analisa survey dari user lain dan nantinya akan dikalkulasi
kualitasnya. Sehingga dari hasil seluruh use case yang ada
pada project ini, seorang user dapat melihat sejauh mana
kualitas kebutuhan perangkat lunak pada projectnya. Seorang
user yang terdaftar juga dapat melihat project dan use case
yang dimiliki user lainya dan melakukan survey didalamnya.
Use Cases
uc Use Case
System
User
Manage Use case
Show use case
quality
Create Use case
Edit use case
Delete use case
Calculate
«extend»
«extend»
«extend»
Seorang user juga dapat menginputkan beberapa use
case pada projectnya . Tujuanya adalah agar use case – use
case tersebut dapat disurvey dan dikalkulasi oleh user lainya.
Selain itu fitur user lainya adalah kalkulasi dan melakukan
manajemen use case yang ada.
Survey
uc Surv ...
System
user
Surv ey
Input Surv ey
Edit Surv ey
«extend»
«extend»
Seorang user pada aplikasi ini dapat mengisi kuisioner
usecase kepunyaan user lain. Sehingga user lain tersebut
dapat melakukan kalkulasi pada use casenya. Didalam
kuisioner tersebut akan ditampilkan use case dan penjelasan
dari 6 kualitas karakteristik berdasarkan matriks structural
model. Setelah itu, user dapat mengisi jawaban dan
menginputkanya pada database.
B. Interface Aplikasi
Berikut ini adalah tampilan tatap muka aplikasi
Pengukuran kualitas kebutuhan perangkat lunak yang telah
dibuat.
Halaman Login
Pada halaman ini, user menginputkan username dan
password untuk diautentikasi sistem. Apabila username dan
password cocok dengan yang ada pada database, maka sistem
akan meminta penginputan ulang.
Registrasi User
Pada halaman registrasi, user melakukan penginputan
pada masing – masing form untuk mendaftar menjadi user
baru. Apabila user telah terdaftar, maka sistim tidak akan
menerima penginputan username yang sama.
Project
Merupakan Tampilan home setelah user melalui proses
login. Yaitu berisi daftar project yang dimiliki, Add Project
dan Edit Project, dan Halaman Result.
Halaman add project berisi form prasyarat untuk
menambah project yang dimiliki user.
Halaman edit project berisi form untuk merubah
keterangan form yang tersimpan dalam database.
Halaman result berisi kalkulasi test validasi dan
reliabilitas dari semua use case, dan kalkulasi kualitas
kebutuhan perangkat lunak pada project tersebut.
Halaman All project berisi seluruh use case project yang
belum/sudah diisi oleh user tersebut.
Use Case
Merupakan beberapa use case yang ada pada satu
project. Pada halaman ini user dapat melakukan manajemen
use case seperti, Add, Delete edit dan Mengkalkulasi hasil
survey pada usecase tersebut
Halaman Add Use case berisi form untuk menambah
use case berserta keteranganya pada database.
Pada halaman Edit Use case, user dapat
melakukan perubahan keterangan use case yang
dimiliki oleh database.
Survey
Pada halaman survey terdapat keterangan setiap
karakteristik kualitas kebutuhan perangkat lunak yang
baik, Use case beserta keteranganya dan Beberapa
pertanyaan yang dapat diisi oleh user.
IV. Kesimpulan
Berdasarkan hasil pengerjaan pengukuran kualitas
kebutuhan perangkat lunak, terdapat beberapa kesimpulan
sebagai berikut:
1. Dari proses pengukuran manual, didapatkan nilai akhir
rata – rata 0,43 atau 43% dari nilai sempurna kualitas
kebutuhan perangkat lunak. Apabila dilihat pada range
yang telah ditetapkan pada bab sebelumnya, nilai
tersebut termasuk pada nilai cukup. Sedangkan apabila
dilakukan pengukuran dengan menggunakan aplikasi,
nilai dari kualitas kebutuhan perangkat lunak
menunjukkan hasil yang lebih akurat. Karena pada
aplikasi ini dapat dilakukan survey pada lebih dari 1
responden. User yang dapat mengakses aplikasi ini ada
3 yaitu: Use case owner, Assessor dan Admin. Tentunya
dengan adanya ke-3 user dan fungsi survey tersebut,
nilainya akan menjadi lebih baik pula.
2. Proses pengukuran kualitas kebutuhan perangkat lunak
dengan menggunakan Metrics Structural Model dapat
diimplementasikan dalam sebuah aplikasi. Namun
aplikasi yang dibuat belum maksimal dan perlu revisi
lebih lanjut. Setelah dilakukan pengujian pada aplikasi
tersebut, dapat dilihat bahwa fungsi – fungsi utama pada
aplikasi tersebut sudah berjalan dengan baik. Hanya
mungkin fungsi – fungsi tambahan seperti pencarian
pada database perlu ditambahkan dan diuji coba
kembali.
3.
V. DAFTAR PUSTAKA
CIO. (2013, January 10). CIO Survey: Why Do 37% of IT Projects
Fail? Retrieved from CIOZone.com:
http://www.ciozone.com/index2.php?option=com_content&do_pd
f=1&id=10193
Corporation, I. (2008). Get it Right the First Time: Writing Better
Requirements.
Essado, M., & Ambrosio, A. (n.d.). A Requirement Metric Applied
on the ITASAT-1:A Small Technological Sattelite.
J. Costello, R., & Liu, D.-B. (1995). Metrics for Requirements
Engineering.
Javeed Ali, M. (2006). Metrics for Requirements Engineeriing.
Pavel, J. (n.d.). System Development Life Cycle.
R, H. (1993). Requirement Metrics:The Basis of Informed
Requirements Engineering Management.
R, M. (2006). System Development Life Cycle Framework.
Sommerville, I. (2004). Software Engineering. Pearson Education.
Suryn, W., & Abran, A. (ISO/IEC SQuaRE. The second generation
of standards for software product quality). 2003.
Wiegers, K. (2003). Software Requirements.
Wikipedia. (n.d.). Grading System. Retrieved October Saturday,
2013, from Wikipedia:
http://en.wikipedia.org/wiki/Grading_%28education%29
Zuse, H., & Bollman, P. (1989). Software Metrics : using
measurement theory to describe the properties and scales of
static software complexity metrics.
