Perancangan Sistem / Perangkat Lunak

“Perancangan aplikasi web pencari lokasi daerah di Yogyakarta menggunakan Google Maps API”

Dari contoh pada web saya (http://standy-oei.web.ugm.ac.id/) yang menggunakan Google Maps API, maka saya dapat membuat suatu model rancangan dengan menggunakan UML.
1. Dengan Use Case Diagram

UseCaseDiagram

Klik pada gambar untuk melihat ukuran sebenarnya (lakukan zoom) ataupun untuk mendownloadnya (klik kanan => save image).

Dari diagram use case tersebut, kita bisa melihat proses – proses apa saja yang dilakukan di dalam sistem.

1. Seorang web user bisa melakukan pencarian peta yang diinginkan, baik dalam mode map, satellite, ataupun hybrid, ke dalam sistem (aplikasi web), kemudian aplikasi web tersebut akan melakukan permintaan kepada google map server berdasarkan apa yang diminta oleh web user.

2. Mengubah isi web terbagi atas 2 kasus, yakni:

- Update isi peta (proses zoom in/out, pemindahan posisi, dll), dilakukan oleh aplikasi web dengan meminta isi map yang akan ditampilkan kepada google map server.

- Mengubah desain web, pada umumnya termasuk menambah konten / isi web, dilakukan oleh web developer.

3. Secara rutin web developer akan melakukan perbaikan bugs yang ditemukan pada web, tetapi pada suatu saat akan terjadi perbaikan tambahan yang tidak dijadwalkan, misalnya sistem (aplikasi web) diserang (contohnya dideface) oleh cracker yang merusak aplikasi web tersebut.


2. Dengan Sequence Diagram


Klik pada gambar untuk melihat ukuran sebenarnya (lakukan zoom) ataupun untuk mendownloadnya (klik kanan => save image).

Sequence Diagram adalah diagram yang menunjukkan interaksi antar aspek (pengguna maupun sistem) terhadap waktu. Tujuan utama dari penggunaan diagram sequence adalah untuk menunjukkan interaksi diantara objek – objek, jadi kita harus berpikir dua kali sebelum menaruh self message (pemanggilan ke diri sendiri) ke dalam diagram. Karena itu saya, membuang self message dari diagram sequence di atas.

Didalam aplikasi ini, objek-objek yang terlibat adalah pengguna, web browser, web server, Google Maps server, dan Google Maps Database.

Proses pertama yang terjadi adalah pengguna membuka halaman situs, dan bentuk awal peta akan langsung di-load. Proses ini akan dijalankan oleh web server yang akan mengirimkan request ke Google Maps server. Google Maps server akan mengembalikan data dan link yang diminta. Web server akan kembali memproses link tersebut untuk selanjutnya di kirimkan ke web browser untuk di-compile.

Proses selanjutnya terjadi di saat pengguna memilih objek yang ingin dilihat. Saat pengguna menentukan pilihannya, web browser akan memproses pilihan tersebut ke web server dimana terjadi hubungan dengan database XML. Data dari XML yang antara lain berisi lokasi koordinat yang diperlukan akan dikirim ke Google Maps server. Setelah mendapat data yang diperlukan dari database-nya, data tersebut dikembalikan ke web server, untuk selanjutnya bersama data lain yang terdapat pada XML ditampilkan pada web browser.

Secara global, Arsitektur dari Web yang menggunakan Google Maps API, adalah sebagai berikut :
USER <——-> WEB INTERFACE <——-> WEB SERVER <——-> GOOGLE MAPS WEB SERVER + DATABASE

=======================================================
Requirement Sistem / Perangkat Lunak

Dari sebuah rancangan, kita bisa melihat requirement yang ada di dalam sistem.

Requirement tidak hanya ditulis oleh pembangun, tapi sebelumnya justru ditulis oleh klien yang memesan software. Klien menuliskan requirement dalam bentuk yang masih abstrak tentang kebutuhannya. Kemudian requirement tersebut diserahkan kepada tim pembangun. Saat sudah ada persetujuan pembangun pun kemudian menuliskan kemampuan sistem yang bisa dipahami oleh klien, inipun disebut requirement.

Definisi

Requirement adalah gambaran dari layanan (services) dan batasan bagi sistem yang akan dibangun. Atau requirement adalah pernyataan/gambaran pelayanan yang disediakan oleh sistem, batasan-batasan dari sistem dan bisa juga berupa definisi matematis fungsi-fungsi sistem.

Requirement berfungsi ganda yaitu:
• Menjadi dasar penawaran suatu kontrak –> harus terbuka untuk masukan
• Menjadi dasar kontrak –> harus didefinisikan secara detil

Proses menemukan, menganalisis, mendokumentasikan dan pengujian layanan-
layanan dan batasan tersebut disebut Requirement Engineering.

Pengumpulan requirement
- Interviews : Memberi informasi yang terbaik,mahal
- Questionnaires : Bagus jika banyak orang terlibat dan tersebar, respon cenderung kurang baik
- Observation : Akurat jika dilakukan dengan baik, mahal
- Searching : Informasi terbatas, cenderung tidak menampilkan hal-hal yang mungkin jadi masalah

Masalah yang mungkin terjadi dalam pendefinisian requirement adalah :

• Sulit mengantisipasi efek dari sistem baru terhadap organisasi

• Beda user, beda pula requirement dan prioritasnya – terpengaruh cara atau gaya kerja

• End-user sistem, dan organisasi yang membiayai sistem berbeda requirement

• Prototype sering dibutuhkan untuk menjelaskan requirement

• Masalah perbedaan bahasa alami

Software system requirement sering dibedakan dalam 3 katagori yaitu Functional requirement, Non Functional requirement dan domain requirement dengan masing-masing penjelasannya sebagai berikut :

1. Functional Requirement :
Merupakan penjelasan tentang layanan yang perlu disediakan oleh sistem, bagaimana sistem menerima dan mengolah masukan, dan bagaimana sistem mengatasi situasi-situasi tertentu. Selain itu kadang-kadang juga secara jelas menentukan apa yang tidak dikerjakan oleh sistem. Functional requirement menggambarkan system requirement secara detil seperti input, output dan pengecualian yang berlaku.

Contoh dalam kasus peminjaman buku di perpustakaan :

• Pengguna bisa mencari semua informasi tentang buku atau bisa memilih salah satu dari informasi tentang buku
• Semua peminjam memiliki pengenal yang unik
• Sistem mampu catat transaksi peminjaman, pengembalian dan denda secara lengkap
• Hari libur bisa di-set sejak awal, dan bisa menerima perubahan dengan otoritas khusus
• Harus komplit ( kebutuhan layanan jelas dan lengkap) dan konsisten (tidak kontradiksi dengan yang didefinisikan)

Masalah yang mungkin terjadi dalam menyusun functional requirement adalah :

1. Diintepretasikan/diartikan berbeda oleh user atau developer
2. Hasil intepretasi sering tidak menjawab kebutuhan klien
3. Untuk sistem yang besar, kelengkapan kebutuhan dan konsisten sulit dicapai karena kerumitan sistem
4. Perlu analisis yang dalam dan menyeluruh untuk mengurangi kesalahan

2. Non-functional Requirement :
Secara umum berisi batasan-batasan pada pelayanan atau fungsi yang disediakan oleh sistem. Termasuk di dalamnya adalah batasan waktu, batasan proses pembangunan, standar-standar tertentu.

Cakupan dari Non-Functional requirement

Karena berkaitan dengan kebutuhan sistem secara keseluruhan,maka kegagalan memenuhi kebutuhan jenis ini berakibat pada sistem secara keseluruhan. Contoh kebutuhan jenis ini adalah kecepatan akses, keamanan data, besarnya kapasitas penyimpanan yang diperlukan, privasi masing-masing profil /account, bahasa pemrograman yang digunakan, sistem operasi yang digunakan.

Sesuai dengan gambar di atas, non functional requirement dibagi menjadi 3 tipe yaitu :

1. Product requirement berkaitan dengan kehandalan, kecepatan, kemudahan digunakan, kapasitas memori yang dibutuhkan dan efisiensi sistem

2. Organisational requirement berkaitan dengan standar, bahasa pemrograman dan metode rancangan yang digunakan.

3. External requirement berkaitan dengan masalah etika penggunaan, interoperabilitas dengan sistem lain, legalitas, dan privasi.

3. Domain requirement :
Berasal dari domain aplikasi sistem. Misalnya karena masalah hak cipta maka beberapa dokumen dalam perpustakaan tidak boleh diakses oleh orang lain yang tidak berhak.

### Dari aplikasi web (sistem) yang saya buat, maka saya dapat mendefinisikan requirement yang ada pada sistem tersebut.

1. Functional Requirement

- Melakukan pencarian peta yang diinginkan oleh user.

- Menampilkan peta yang dicari, baik dengan mode map, satellite, ataupun hybrid.

- Melakukan navigasi / pergeseran lokasi pada peta yang ditampilkan.

- Melakukan zoom in/out pada peta yang ditampilkan.

2. Non – Functional Requirement

- Melakukan perbaikan desain ataupun konten pada web. (Usability)

- Melakukan perbaikan pada bugs yang ditemukan, ataupun celah keamanan yang bisa digunakan oleh cracker. (Reliability, Security)

3. Domain Requirement

- Karena masalah keamanan dan kerahasiaan, Google Maps API yang dipasang pada web tidak bisa (dilarang) untuk menampilkan peta lokasi dari daerah / wilayah pangkalan militer yang dimiliki suatu negara.

=======================================================
Pengujian Sistem / Perangkat Lunak

Adalah elemen kritis dari jaminan kualitas perangkat lunak dan merepresentasikan kajian pokok dari spesifikasi, desain, dan pengkodean.

Sejumlah aturan yang berfungsi sebagai sasaran pengujian pada perangkat lunak adalah:

1. Pengujian adalah proses eksekusi suatu program dengan maksud menemukan kesalahan
2. Test case yang baik adalah test case yang memiliki probabilitas tinggi untuk menemukan kesalahan yang belum pernah ditemukan sebelumnya
3. Pengujian yang sukses adalah pengujian yang mengungkap semua kesalahan yang belum pernah ditemukan sebelumnya

Sasaran utama desain test case adalah untuk mendapatkan serangkaian pengujian yang memiliki kemungkinan tertinggi di dalam pengungkapan kesalahan pada perangkat lunak. Untuk mencapai sasaran tersebut, digunakan 4 kategori yang berbeda dari tehnik desain test case: Pengujian white-box, pengujian black-box, Integrasi Bottom-Up dan Integrasi Top-Down.

Pengujian white-box berfokus pada struktur control program. Test case dilakukan untuk memastikan bahwa semua statemen pada program telah dieksekusi paling tidak satu kali selama pengujian dan bahwa semua kondisi logis telah diuji. Pengujian basic path, tehnik pengujian white-box, menggunakan grafik (matriks grafiks) untuk melakukan serangkaian pengujian yang independent secara linear yang akan memastikan cakupan.

Pengujian aliran data dan kondisi lebih lanjut menggunakan logika program dan pengujian loop menyempurnakan tehnik white-box yang lain dengan memberikan sebuah prosedur untuk menguji loop dari tingkat kompleksitas yang bervariasi. Pengujian black-box didesain untuk mengungkap kesalahan pada persyaratan fungsional tanpa mengabaikan kerja internal dari suatu program.

Teknik pengujian black-box berfokus pada domain informasi dari perangkat lunak, dengan melakukan test case dengan menpartisi domain input dari suatu program dengan cara yang memberikan cakupan pengujian yang mendalam.

Metode pengujian graph-based mengeksplorasi hubungan antara dan tingkah laku objek-objek program. Partisi ekivalensi membagi domain input ke dalam kelas data yang mungkin untuk melakukan fungsi perangkat lunak tertentu. Analisis nilai batas memeriksaa kemampuan program untuk menangani data pada batas yang dapat diterima.

Metode pengujian yang terspesialisasi meliputi sejumlah luas kemampuan perangkat lunak dan area aplikasi. GUI, arsitektur client/ server, dokumentasi dan fasilitas help dan sistem real time masing-masing membutuhkan pedoman dan tehnik khusus untuk pengujian perangkat lunak.

Integrasi Top-Down adalah pendekatan incremental dengan menggerakkan ke bawah melalui hirarki control, dimulai dengan control utama. Strategi intergrasi top-down memeriksa control mayor atau keputusan pada saat awal di dalam proses pengujian. Pada struktur program yang difaktorkan dengan baik, penarikan keputusan terjadi pada tingkat hirarki yang lebih tinggi sehingga terjadi lebih dulu.

Strategi top-down kelihatannya tidak sangat rumit, tetapi di dalam praktenya banyak menimbulkan masalah logistic. Biasanya masalah ini terjadi jika dibutuhkan pemrosesan di dalam hirarki pada tingkat rendah untuk menguji secara memadai tingkat yang lebih tinggi.

Pengujian Integrasi Bottom-up memulai konstruksi dan pengujian dengan modul atomic (modul pada tingkat paling rendah pada struktur program). Karena modul diintegrasikan dari bawah ke atas, maka pemrosesan yang diperlukan untuk modul subordinate ke suatu tuingkat yang diberikan akan selalu tersedia dan kebutuhan akan stub dapat dieliminasi.

### Untuk pengujian pada aplikasi web saya, saya lebih cenderung menggunakan pengujian white-box, dimana hanya memperhatikan struktur control program internal, tanpa bisa melakukan pengujian terhadap output ataupun proses yang dilakukan oleh Google Maps API.

Selain itu juga, saya akan melibatkan beberapa user untuk mencoba memasukkan input secara random, dan melihat apakah hasil / output yang dihasilkan sesuai dengan yang diinginkan. Dan jika terjadi error pada internal web saya, maka saya bisa melakukan debugging, tetapi jika error terjadi di pihak Google Maps Server, maka saya tidak bisa melakukan apa – apa selain menunggu adanya perbaikan dari pihak Google sendiri.

Dan untuk pengujian stability, avaibility, dan speed rate dalam pengaksesan web dapat dilakukan terhadap web server milik ugm.ac.id ataupun terhadap Google Maps Server, dan hal itu sudah diluar batas kendali saya sebagai developer web. Dan untuk pengujian ini, kita bisa melibatkan beberapa responder / user yang sering berinterakasi dengan web saya, dengan cara melakukan interview ataupun menggunakan lembaran quiztioner.