Rating pada faktor kompleksitas

Tabel 4. Rating pada faktor kompleksitas

Elemen

Rating

Faktor beban (Carrol, 2001)

Tfactor

Solusi yang terdistribusi

Kebutuhan akan performa yang spesifik

Kebutuhan akan efisiensi yang spesifik

Bisnis proses yang kompleks

Kode yang reusable

Kemudahan instalasi

Mudah dirubah dan dikostumisasi

Mendukung penggunaan secara bersamaan

Fitur keamanan yang spesifik

Interoperabilitas dengan aplikasi lain

Kebutuhan pelatihan pengguna yang spesifik

Total TFactor

Berdasarkan Tabel 4 diperoleh nilai total TFactor adalah 30,5. Hasil dari total Tfaktor ini dapat menjadi dasar untuk melakukan perhitungan Technical Complexity Factor (TCF) dengan rumus sebagai berikut. TCF = (Tfactor x

= (30.5 x

Berdasarkan perhitungan pada rumus (1) ditemukan nilai TCF sebesar 0,905. Nilai TCF tersebut kemudian dikalikan dengan user story point yang terdapat pada Tabel 1 yaitu sebesar 60 poin. Hasil kali antara TCF dengan user story point pada GXP dinamakan dengan Software Complexity. Software Complexity = TCF x User Story Point

= 0,905 x 60 = 54,3

Hasil perhitungan kompleksitas perangkat lunak menunjukan angka 54,3. Sedangkan user story point pada Tabel 1 menghasilkan total nilai 60. Apabila dibandingakan, maka user story point (60) > software complexity (54,3). Sehingga dapat dikatakan proyek pembuatan aplikasi forum diskusi ini dapat dikuasai/dikerjakan oleh tim. Hal yang menyebabkan software complexity tidak terlalu besar adalah karena penggunaan framework yang memudahkan dalam reusable code dan dapat mendukung penggunaan kode secara bersama-sama

2.3 Fase Iterasi

Fase iterasi atau dikenal dengan fase konstruksi merupakan fase terpanjang dan menjadi fase penentu keberhasilan sebuah proyek. Pada metode GXP, fase iterasi melakukan berbagai hal umum yang dilakukan dalam pengembangan kode perangkat lunak meliputi.

a. Pengembangan dan desain arsitektur sistem.

b. Pembuatan dan pengujian unit kode.

c. Penjaminan kualitas dan integrasi modul.

2.3.1 Pengembangan dan Desain Arsitektur Sistem

Sebagaimana dipaparkan pada latar belakang bahwa aplikasi forum diskusi online ini dibuat dengan menggunakan framework Rails atau lebih dikenal dengan sebutan Ruby on Rails. Seperti pada umumnya web framework, Ruby on Rails yang menerapakan arsitektur MVC. Cara kerja dari model MVC ini yaitu memisahkan data (Model) dari tampilan (View) dan cara mengaksesnya (Controller). Arsitektur dari MVC pada sebuah pengembangan web, ditunjukan pada Gambar 3.

Gambar 3. Arsitektur web MVC (Verma, 2014)

Penjelasan mengenai arsitektur MVC pada Gambar 3 adalah sebagai berikut.

1. User melakukan request ke browser.

2. Setiap request yang diberikan oleh user, akan ditangani oleh Controller.

3. Kemudian dari Controller akan dilanjutkan ke Model.

4. Saat mengakses Model, dilakukan pengecekan mengenai kebutuhan database.

5. Jika memerlukan database maka Model akan mengambil data dari database, namun jika tidak maka dari Controller akan langsung ke proses View

6. Informasi dari Model dikembalikan ke Controller, kemudian Controller melanjutkan ke state View untuk ditampilkan di browser.

7. View menampilkan antarmuka pengguna dan juga informasi yang telah diperoleh dari database.

Pada penjelasan tersebut dapat disimpulkan bahwa setiap berkas ruby yang diletakan pada beberapa direktori sesuai dengan fungsinya. Pengembang akan lebih mudah bekerja karena direktori untuk mengatur tampilan, mengatur database dan mengatur akses sudah dikelompokan. Selain itu juga memudahkan pengembang dalam membagi pekerjaan dari masing-masing fitur. Penerapan arsitektur MVC pada GXP dapat mengurangi kompleksitas proyek karena memungkinkan kolaborasi antar anggota tim.

2.3.2. Pembuatan dan Pengujian Kode Unit

Salah satu hal yang menarik pada GXP adalah teknik test first, code later yang diusulkan berdasarkan pada model utama dari eXtreme Programming (XP). Inti dari test first design pada GXP memfokuskan bahwa pengujian aplikasi harus terencana dan sama pentingnya dengan pengkodean itu sendiri.

Hasil dari langkah ini adalah suatu dokumen pengujian yang akan dilakukan oleh tim penguji dalam menguji suatu user story. Tabel 5 mendeskripsikan contoh spreadsheet yang digunakan sebagai artifak pengujian sistem.

Tabel 5. Pengujian sistem pada iterasi satu

Iteration One

Notes DC-001

User Story ID Test Case ID

Test Case Scenario

Tested by

Tested At

T001-001

Login dengan email dan passwod

boy

Login salah muncul alert

yang salah

T001-002

Login dengan email dan password

boy

Masuk ke halaman forum

sesuai hak aksesnya DC-002

yang benar

T002-001

Membuat thread baru

afandi

Muncul thread baru di halaman forum

T002-002

Mengedit dan menghapus thread

afandi

Thread dapat diubah dan dihapus sesuai user yang membuatnya

Tabel 5 menunjukan iterasi pertama yang pada iterasi tersebut memiliki enam kolom yaitu id user story, id test case (id pengujian), skenario pengujian, anggota tim yang melakukan pengujian, waktu pengujian, dan catatan hasil pengujian. Proses pengujian dari tiap-tiap test case dilakukan dua kali, yakni sebelum fungsi modul tersebut selesai dan setelah modul fungsi tersebut selesai. Proses pengujian pada forum diskusi masih berjalan manual, yaitu menguji tiap-tiap fungsi tanpa menggunakan tools pengujian.

2.3.3. Integrasi Modul

A. Relasi antar Tabel

Gambar 4. ERD dari forum diskusi

Aplikasi forum diskusi dibangun menggunakan basis data PosgreSQL. Dimana PosgreSQL merupakan RDBMS yang antar tabelnya saling terhubung satu sama lain. Gambar 4 menjelaskan bahwa terdapat tiga tabel yang saling berintegrasi. Penjelasan dari hubungan masing-masing tabel adalah sebagai berikut.

 Tabel users berisi data-data dari pengguna forum. Satu user dapat membuat lebih dari satu thread dan juga lebih dari satu post.  Tabel forum_thread berisi data-data dari thread. Hubungannya dengan tabel yang lain yaitu satu user dapat membuat banyak thread, dan satu thread dapat memiliki banyak post.  Tabel forum_post berisi data-data dari post (komentar) yang diberikan oleh user. Satu user dapat memberikan banyak post dan satu thread dapat pula terdapat banyak post.

B. Perancangan diagram use case

Pada tahap ini, ditentukan sebuah alur proses dari masing-masing pengguna. Setiap pengguna memiliki fitur- fitur tertentu dalam mengakses forum diskusi yang dibuat. Terdapat tiga pengguna yang berperan dalam menggunakan forum diskusi ini. Adapun diagram use case dari forum diskusi, ditunjukan pada Gambar 5.

Gambar 5. Diagram use case dari forum diskusi

Gambar 5 menunjukan terdapat tiga pengguna yang dapat mengakses forum diskusi. Tamu (guest) adalah user yang hanya dapat melihat isi percakapan dari diskusi (thread) dan hanya dapat melihat komentar dari thread. Apabila guest mendaftar ke forum lalu melakukan login, maka status dari guest akan berubah menjadi member. Setelah menjadi member maka hak yang dimiliki adalah dapat menambah, mengubah dan menghapus thread yang dibuat dan dapat menambahkan komentar. Sedangkan pada admin memiliki hak-hak yang semakin luas, diantaranya dapat mengelola pengguna yang mendaftar dan dapat menambahkan sticky note pada thread.

C. Refactoring Program

Tujuan refactoring adalah untuk menghasilkan clean code yang mudah dibaca, tidak mengandung duplikasi, dan mudah dilakukan maintenance. Menurut Martin (2008) dalam bukunya menerangkan bahwa cara untuk memenuhi deadline dan bekerja dengan cepat adalah sebisa mungkin menjaga agar tercipta clean code. Oleh karena itu, pada aplikasi forum diskusi online ini dilakukan refactoring kode program seperti ditunjukan pada Gambar 6.

Gambar 6. Penerapan r efactoring pada modul

Gambar 6 menunjukan bahwa berkas form.html.erb berisi template yang digunakan bersama oleh new.html.erb dan edit.html.erb. Sehingga isi dari berkas new.html.erb dan edit.html.erb hanya berisi satu Gambar 6 menunjukan bahwa berkas form.html.erb berisi template yang digunakan bersama oleh new.html.erb dan edit.html.erb. Sehingga isi dari berkas new.html.erb dan edit.html.erb hanya berisi satu

D. Pair Programming

Pair programming merupakan suatu teknik menyelesaikan sebuah program, dimana programmer bekerja bersama-sama dari lokasi yang berbeda. Adanya pair programming sangat membantu programmer dalam menyelesaikan program dengan cepat. Sebab antar programmer saling membagi pekerjaan, dapat mengoreksi kesalahan masing-masing, dan dapat saling mem-backup data setelah dilakukan commit.

Pembuatan forum diskusi ini juga menerapkan pair programming dengan cara memanfaatkan layanan version control seperti github. Kemudian penulisan program juga dilakukan secara bersama-sama walaupun lokasi antar programmer terpisah. Hal ini dapat dilakukan dengan bantuan editor vim ditambah program tmux sehingga memprogram seperti selayaknya menjalankan remote desktop.

2.4 Fase Produksi

Fase produksi adalah fase yang menentukan selesai atau tidaknya pekerjaan. Pada fase ini dilakukan berbagai evaluasi untuk memastikan bahwa hasil yang dicapai sesuai dengan fase perencanaan. Salah satu upaya yang dilakukan adalah melakukan kegiatan produksi sesuai iterasi yang terjadi dalam suatu solusi. Hasil dari fase produksi adalah sebuah aplikasi web yang sebelumnya telah direncanakan yaitu forum diskusi.

2.4.1 Tampilan Antarmuka Forum

Forum diskusi yang dibuat memiliki 2 pengguna yang memiliki wewenang untuk memulai diskusi. Kedua pengguna tersebut adalah admin dan member. Apabila ingin bergabung sebagai member, maka pengunjung harus mendaftar terlebih dahulu. Adapun tampilan dari halaman admin ditunjukan pada Gambar 7. Tampilan dari halaman member sama dengan admin, hanya saja tidak terdapat pilihan untuk edit member.

Gambar 7. Tampilan halaman admin forum diskusi

Antara member dan admin, memiliki hak akses masing-masing. Member memiliki wewenang untuk membuat thread diskusi, mengedit dan menghapus thread yang telah dibuat, serta memberikan komentar pada semua thread. Sedangkan admin hak aksesnya lebih luas yaitu selain dapat membuat, mengedit dan menghapus setiap thread, dapat pula menambahkan sticky note.

2.5 Fase Perawatan

Kualitas sebuah perangkat lunak yang dibangun tidak hanya sebatas bekerja sesuai dengan kebutuhan penggunanya. Kualitas perangkat lunak adalah bagaimana perangkat lunak tersebut dapat berevolusi dan terus berbenah untuk menangani kesalahan (bugs). Perkembangan b erkelanjutan atau lebih dikenal dengan “kaizen” adalah salah satu karakteristik yang menandakan bahwa suatu solusi senantiasa berkembang dan memperbaiki diri. Gambar 8 menujukan diagram pengembangan berkelanjutan dari forum diskusi yang dibuat.

Gambar 8. Diagram pengembangan berkelanjutan

Sumbu X menunjukan iterasi yang dibutuhkan oleh sistem. Sementara sumbu Y menunjukan jumlah commit atau build yang dilakukan selama pembuatan sistem. Commit atau check-in adalah istilah umum digunakan dalam dunia source code versioning. Gambar 9 menunjukan bahwa tingkat kesulitan program berada pada tengah-tengah proyek sebab pada iterasi kedua terjadi banyak commit. Kemudian semakin lama grafik semakin menurun yang menandakan bahwa revisi program satu per satu dapat diatasi dan program dapat selesai dikerjakan.