Rancang Bangun Aplikasi Pengukuran Kualitas Kebutuhan Perangkat Lunak Berdasarkan Matriks Structural Model Studi Kasus : Aplikasi School Social Network (SSN) 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.
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
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
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.
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.
perangkat lunak dengan menggunakan Metrics adalah seperti berikut :
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
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 Deskripsi Case 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.
3.
4.
5.
6.
7.
8.
Flow of event membuat status.
Use case untuk melakukan proses pembuatan status.
Flow of event membuat pesan dinding.
Selain status, pengguna juga bisa membuat pesan dinding yang ditujukan kepada wall dinding teman.
Flow of event mengirim komentar.
Use case untuk memberikan komentar pada sebuah status.
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.
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.
Flow of event melihat feed.
Use case untuk melihat aktivitas kiriman dari pengguna lain yang menjadi teman aktor.
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.
20.
Flow of event lihat daftar group.
Use case untuk melihat group. Di dalam group terdapat 3 jenis: group sekolah, ekstrakulikuler dan kelas.
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
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
21.
Flow of event membuat thread.
Use case untuk membuat thread baru pada suatu group.
31.
Flow of event membuat agenda.
Use case untuk membuat agenda baru untuk masingmasing pengguna..
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
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 Notifikasi 23.
24.
Flow of event melihat notifikasi.
Flow of event menghapus notifikasi.
Use case untuk melihat pemberitahuan yang ditujukan pada aktor tersebut.
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.
Use case untuk menghapus notifikasi yang ada pada daftar notifikasi.
Aktifitas Event 25.
26.
27.
Flow of event melihat daftar event.
Use case untuk melihat daftar dari event.
Flow of event konfirmasi kehadiran.
Use case untuk mengonfirmasi kehadiran pengguna terhadap suatu event yang akan diadakan.
Flow of event berkomentar
Use case untuk memberikan komentar pada sebuah
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.
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.
Nonambiguity
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
Pada paper (R H. , 1993) kualitas kebutuhan perangkat lunak distandardkan pada karakteristik – karakteristik berikut : No.
1.
2.
Quality Characteris tics Correctness
Completenes s
Definisi
Penjelasan
Apakah ada atau tidaknya kesalahan pada kebutuhan perangkat lunak.
Seberapa banyak jumlah error yang ditemukan pada use case scenario?
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?
7.
8.
9.
10.
Singularity
Testability
Modifiability
Feasibility
sama lain
case yang masih bertentangan satu dengan lainya?
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?
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?
Namun pada pengukuran kali ini hanya di ukur berdasarkan beberapa karakteristik saja. Yaitu NonAmbiguity, 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 1
2
Quality Characteristic
Interval
Ambiguity Correctness Modifiable Clarity
1(Permisalan) 0 0 1
Ambiguity Correctness Modifiable Clarity
1 1 0 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 :
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?
Kelayakan kebutuhan perangkat lunak untuk diimplement asikan pada proyek.
Apakah kebutuhan perangkat sudah lunak layak untuk digunakan?
Quality Characteristic Non-Ambiguity
Correctness
Jumlah Nilai 1 40 (Permis alan) 35
Jumlah Nilai 0 7 (Permis alan) 12
Consistency
33
14
Clarity
42
5
Rumus
Hasil/ IRQ
Connectivity Singularity Jumlah IRQ =
Dari jumlah IRQ dapat RQ(Requirements Quality)
RQ =
dihitung
jumlah
dari
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 kekurangan seperti : 1. 2. 3.
itu,
PHP
memiliki
beberapa
Tidak detail untuk pengembangan skala besar Tidak memiliki sistem pemrogaman berorientasi objek yang sesungguhnya. Tidak bisa memisahkan antara tampilan dengan logic dengan baik.
4.
5.
PHP memiliki kelemahan security tertentu apabila programmer tidak jeli dalam melakukan pemrogaman dan kurang memperhatikan isu konfigurasi PHP. 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.
2.
3.
View, merupakan bagian yang menangani presentation logic. Pada suatu aplikasi web bagian ini biasanya berupa file template HTML, yang diatur oleh controller. 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. 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, multiuser, 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. 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.
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)
1. 2. 3. 4.
Correctness Clarity Consistency NonAmbiguity Singularity Connectivity
0,05 0,64 0,91 0,83
0,95 0,70 0,75 0,70
0,04 0,44 0,68 0,58
0,98 0,89
0,50 0,40 Jumlah
0,49 0,35 2,58
C.
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 Correctness Clarity
Jumlah Nilai 1 2
Jumlah Nilai 0 35
24
13
Rumus
Hasil /IRQ 0,05
IRQ*Bob ot
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
0,64
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 :
Consistency
34
3
0,91
NonAmbiguity
31
6
0,83
Singularity
36
1
0,98
Connectivity
33
4
0,89
Jumlah IRQ =
5. 6.
Bobot
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.
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.
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
Login
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 :
User
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
Survey
uc Proj e...
uc Surv ... System
System Create Proj ect
«extend» Manage Proj ect
Input Surv ey «extend»
«extend» Edit Proj ect
Show Proj ect Use cases
Surv ey
«extend»
user
user
«extend» Edit Surv ey
Delete Proj ect Show Result
Show All av ailable Proj ects
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
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
uc Use Case System
Create Use case
«extend»
Manage Use case «extend» User
Edit use case
«extend» Calculate
Delete use case
Show use case quality
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
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.
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 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 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 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.
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.
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
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.
