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: abubakar.nabil@gmail.com 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
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)
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,43Berdasarkan 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 Proj e...
System
user
Manage Proj ect
Show Result Show Proj ect Use
cases
Show All av ailable Proj ects
Create Proj ect
Edit Proj ect
Delete Proj ect «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.
