Analisa Perancangan Aplikasi Web-based Dormitory Management

Berikut ini saya berikan contoh proses analisa dan perancangan aplikasi berbasis-web. Tahapannya mengikuti pendekatan metodologi Unified Process.

PLANNING

Setelah melakukan penelitian serta interview pada beberapa tempat kos, kami dari Tim Pembang perlu melakukan beberapa tahapan untuk memecahkan masalah yang ada, berikut  ini adalah beberapa tahap yang akan kami jalankan:

1.1 Identifying Business Value

System Request - Sistem Informasi Pengelolaan Rumah Kos Berbasis Web

1.1.1 Project Sponsor 

Sponsor proyek yang akan dilakukan bersumber dari: 

_________________, Wakil Direktur CV. Karya Anugerah Bersama

1.1.2 Business Need 

Sistem informasi pengelolaan rumah kos berbasis web ini bertujuan untuk :

• Meningkatkan kontrol pengelolaan rumah kos, seperti pengelolaan aset.

• Memudahkan pembuatan laporan oleh manager.

• Meningkatkan market share.

• Memberikan kemudahan akses informasi rumah kos.

1.1.3 Business Requirement 

Dengan menggunakan aplikasi berbasis web, calon penghuni rumah kos dapat mencari informasi lengkap mengenai rumah kos yang akan mereka tempati dan memesan (booking) tempat kos tersebut secara langsung jika mereka berminat. Persyaratan bisnis penggunaan project berbasis web ini dapat digambarkan sebagai berikut :   

• Sistem harus online.

• Sistem harus memiliki fitur pemesanan.

• Sistem dapat memberikan informasi lengkap mengenai berbagai fasilitas dan ketersediaan kamar kosong seperti foto dan lokasi rumah kos.

• Sistem dapat menghasilkan invoice. 

• Sistem dapat menghasillkan laporan pendapatan dan pengeluaran bulanan.

1.1.4 Business Value 

Sistem informasi pengelolaan rumah kos ini dapat memberikan keuntungan bagi pemilik, pengelola dan penghuni rumah kos. Keuntungan yang bisa diperoleh antara lain sebagai berikut : 

I. Tangible

• Mengurangi biaya telepon sebesar 70% untuk komunikasi.

• Meningkatkan penyewaan sebesar 30%.

• Mengurangi biaya pemasangan iklan sebesar 60%.

II. Intangible

• Memberikan kepastian mengenai pendapatan tiap bulannya.

• Memberikan kemudahan kontrol.

• Mengoptimalkan kinerja manager.

• Memberikan kenyamanan dan kemudahan user (calon penghuni) dalam mencari informasi dan memesan tempat kos.

• Meningkatkan brand image rumah kos.

1.1.5    Special Issues or Constraints 

Sistem ini harus berjalan sebelum dimulainya tahun ajaran baru (Juli 2008) dimana pada saat itu banyak calon penghuni yang akan mencari kamar kos.

ANALYSIS
Tahap analisis, diawali dengan melakukan Pendefinisian Requirement.

2.1 REQUIREMENT DETERMINATION
2.1.1 Ketentuan Fungsional
Beberapa ketentuan fungsional yang harus dipenuhi oleh sistem antara lain sebagai berikut :
1. Viewing
1.1 Sistem dapat menampilkan informasi lengkap mengenai tempat kos (foto kamar, lokasi, fasilitas, dan daftar harga sewa kamar).
2. Booking
2.1 Sistem dapat menangani pemesanan kamar secara online (booking online).
2.2 Sistem dapat membatalkan pemesanan kamar yang telah di booking oleh calon penghuni.
3. Payment
3.1 Sistem dapat menangani pembayaran uang sebagai tanda jadi memesan kamar ( down payment sebesar 10%) secara online via bank.
3.2 Sistem dapat menangani pembayaran uang sewa dan mengkonfirmasinya ke penghuni rumah kos.
4. Room Management
4.1 Sistem harus dapat mengatur management rumah kos seperti memonitor kondisi bisnis rumah kos, pengelolaan data penghuni, kamar yang dihuni, dan layanan yang dipesan.
5. Report
5.1 Sistem dapat menyimpan dan men-generate laporan keuangan bulanan dan tahunan.
5.2 Sistem dapat mencatat pengeluaran harian.
5.3 Sistem dapat men-generate aset report.

2.1.2 Ketentuan Non-Fungsional
Beberapa ketentuan non- fungsional yang harus dipenuhi oleh sistem antara lain sebagai berikut :
1. Ketentuan Operasional (lingkungan fisik dan teknis sistem yang diaplikasikan)
1.1 Sistem dapat dioperasikan pada PC Dekstop dan Notebook serta terlihat dalam resolusi display 1024x768 dan 800x600.
1.2 Sistem harus dapat bekerja pada web browser yang sudah umum dipergunakan seperti internet explorer dan mozila firefox.
1.3 Sistem harus dapat dijalankan pada server hosting yang sudah tersedia.
1.4 Sistem harus dapat diakses pada sistem operasi Windows dan Linux.
1.5 Sistem harus dapat diakses pada komputer dengan spesifikasi hardware minimal, yakni Hard Disk 1 GB, Memori RAM 128 MB, dan Processor Pentium standar.
2. Ketentuan Performansi (kecepatan, kapasitas, dan keandalan)
2.1 Setiap interaksi sistem dengan user tidak boleh lebih lama dari 3 detik.
  2.2 Sistem harus dapat digunakan atau dioperasikan dalam 24 jam dalam   sehari, 7 hari dalam seminggu dan 356 hari dalam setahun.
  2.3   Sistem harus dapat men-generate historical data laporan keuangan selama 10 tahun.
  2.4 Sistem mudah digunakan oleh berbagai kelompok user (user friendly).
  2.5 Sistem harus mampu menyajikan data yang akurat dan up to date.
  2.6 Sistem harus mudah dipelihara dan dikembangkan.
  2.7   Sistem memiliki automatic backup recovery.
3. Ketentuan Keamanan ( akses otorisasi)
3.1 Sistem harus memiliki sistem otorisasi bertingkat, dalam hal ini dibedakan menjadi otorisasi owner, manager, dan otorisasi penghuni atau calon penghuni.
3.2 Sistem harus mengatur otorisasi untuk penghuni dan calon penghuni; tidak dapat mengakses dan mengubah serta meng-update report income harian, bulanan, dan  tahunan.
3.3 Sistem harus mengatur otorisasi untuk manager ; dapat meng-update  laporan bulan berjalan dan atau tahun berjalan, namun tidak dapat mengubah laporan bulan yang telah lewat dan atau tahun yang telah lewat.
3.4 Sistem harus mengatur otorisasi untuk owner ; dapat memeriksa dan mengubah laporan bulanan atau tahunan yang berjalan maupun yang telah lewat.

4. Ketentuan Politik dan Budaya
4.1 Sistem harus memiliki fitur pengoperasian dalam bahasa Indonesia.


2.2 REQUIREMENTS ANALYSIS TECHNIQUES
Setelah dilakukan Requirement Determination, maka dilakukan Proses Menganalisis Kebutuhan. AKtivitas ini diawali dengan (1) Menganalisis Proses Berjalan (AS-IS System) kemudian dilanjutkan dengan  (2) Analisa Kebutuhan System (TO BE System), dan (3) Rekapitulasi Permasalahan Yang Dihadapi, kemudian dilanjutkan dengan (4) Usulan Penyelesaian Masalah.

Berikut adalah laporannya ...
CV Karya Anugerah Bersama sebagai perusahaan multiusaha memerlukan suatu sistem yang handal, mudah dan efisien dalam mendukung proses bisnisnya. Salah satu bisnis yang semakin berkembang dari waktu ke waktu adalah pengelolaan rumah kos. Proses bisnis rumah kos pada CV Karya Anugerah Bersama yang dijelaskan pada bagian ini.

2.2.1 Proses Berjalan (AS-IS SYSTEM)
Sekarang ini, pengelola unit usaha belum memiliki sebuah sistem pengelolaan automation yang dapat mencatat secara akurat dan tepat seluruh aktifitas yang terjadi dalam unit usaha ini. Proses bisnis yang sekarang berjalan hanya secara manual dan paper-based sehingga sangat tidak efisien dan optimal. Terutama pada masalah keakuratan data untuk penyebaran informasi kamar kosong (viewing), proses booking (pemesanan), pembuatan report, proses payment, rekapitulasi revenue dan belanja (termasuk kontrol cost-benefits) serta pendataan aset.

2.2.1.1 Viewing
Saat ini calon penghuni rumah kos harus mendapatkan informasi mengenai kondisi rumah kos melalui iklan (berupa pamflet, brosur, atau iklan cetak) yang disebarkan melalui beberapa media cetak dan ditempelkan di beberapa tempat umum seperti papan pengumuman di beberapa universitas, rumah sakit, restoran ataupun site-site strategis seperti perempatan jalan.

Informasi yang disebarkan dengan cara tersebut diatas bersifat singkat dan tidak komprehensif, karena space-nya yang kecil. Akibatnya informasi rumah kos yang dimuat tidak lengkap. Seiring berjalannya waktu, brosur dan pamflet (yang dibuat dari kertas warna) juga sering rusak karena hujan ataupun karena dirusak oleh oknum-oknum tertentu, atau bahkan ditempeli dengan iklan yang lain, sehingga tidak lagi bisa terlihat.
Akibatnya, dalam waktu beberapa minggu saja, harus dibuat lagi brosur dan pamflet yang baru. Kemudian ditempelkan lagi pada space yang ada. Kegiatan menghabiskan sumber daya yang cukup besar. Pemasangan iklan di media cetak, biasanya pada  space yang kecil dan tidak menyolok, sehingga kadangkala sering tidak terbaca dengan baik oleh calon penghuni yang mencari informasi rumah kos.

Setelah mendapatkan informasi rumah kos tersebut, calon penghuni harus menghubungi melalui telepon atau harus datang sendiri ke rumah kos untuk bertemu dengan manager. Setelah menghubungi atau mendatangi sendiri rumah kos, calon penghuni harus berhubungan (bertemu langsung) dengan manager untuk mendapatkan penjelasan yang lebih lengkap mengenai kondisi rumah kos, tipe kamar kos yang bisa disewa, harga dan fasilitas yang ada.

Manager juga memaparkan tata cara pembayaran termasuk melakukan negosiasi harga. Proses ini seringkali membutuhkan waktu yang lama, karena seringnya manager tidak berada di tempat saat calon penghuni menelpon ataupun mendatangi rumah kos. Akibatnya, calon penghuni harus menghubungi berkali-kali bahkan sering mendatangi rumah kos berkali-kali hanya untuk bertemu dengan manager rumah kos. Pada akhirnya, calon penghuni membatalkan keinginannya untuk menyewa kamar, hanya karena tidak bertemu dengan manager pada waktu yang diinginkan.

2.2.1.2 Booking
Setelah mendapatkan informasi yang lengkap mengenai rumah kos, calon penghuni yang ingin menyewa kamar melakukan booking. Proses pemesanan (booking) kamar kos dilakukan oleh calon penghuni dengan cara mendatangi secara langsung rumah kos. Jika mereka berminat menempati salah satu kamar kos yang masih dalam kondisi tidak terisi maka calon penghuni harus berhubungan langsung dengan manager.

Manager kemudian akan menjelaskan tata cara booking, dalam hal ini, calon penghuni diberikan pilihan. Pilihan pertama, calon penghuni bisa mem-booking dengan cara menyetor down payment, yaitu sebesar 10% dari harga kamar yang akan disewa. Pilihan kedua calon penghuni bisa membayar cash harga sewa kamar yang diinginkan. Jika calon penghuni memilih membayar down payment saja, maka calon penghuni harus melunasi harga sewa secara penuh saat akan menempati kamar yang diinginkan. Saat melakukan pembayaran down payment, maka manager akan memberikan tanda bukti panjar kemudian mendaftarkan calon penghuni dalam daftar calon penghuni dan memberikan tanda bahwa kamar sudah di booking.

Dalam hal ini, calon penghuni belum diberikan kunci kamar oleh manager. Dan kamar belum bisa dianggap sebagai milik sepenuhnya dari calon penghuni yang menyetor hanya down payment saja. Pilihan kedua, calon penghuni bisa langsung membayar cash dari harga sewa kamar. Bila calon penghuni membayar secara cash, maka manager akan langsung memberikan tanda bukti lunas dan mencatat calon penghuni menjadi penghuni tetap. Selanjutnya manager akan memberikan kunci kamar kepada penghuni yang baru. Untuk selanjutnya, tanggung jawab kamar diserahkan sepenuhnya kepada penghuni baru.

Setelah itu,  penghuni baru, diharuskan untuk memberikan keterangan lengkap mengenai asal-usul, maksud tinggal, dan keterangan diri lainnya, untuk dicatat oleh manager dan selanjutnya manager akan melaporkan kepada pihak kelurahan yang terkait. Keterangan diri penghuni baru juga harus melampirkan tanda pengenal (seperti KTP, SIM dan kartu Pelajar/Mahasiswa yang masih berlaku ataupun surat keterangan lainnya yang sah).

Prosedur registrasi diri juga harus dilakukan oleh calon penghuni yang membayar down payment, setelah calon penghuni tersebut membayar lunas harga sewa kamar. Setelah itu,  penghuni baru harus menyetorkan uang deposit. Uang deposit sebesar 50% dari harga sewa kamar dan harus disetorkan lunas pada saat akan menempati kamar.

Pembayaran uang deposit tersebut sebagai jaminan penghuni selama menggunakan kamar. Uang deposit akan dikembalikan sebesar 100% kepada penghuni saat penghuni ingin pindah dari rumah kos, dengan ketentuan tidak terjadi kerusakan pada kamar. Apabila terjadi kerusakan di kamar yang ditempati, maka biaya perbaikan kamar, akan dikenakan pada uang deposit, sisanya baru dikembalikan kepada penghuni.

2.2.1.3 Payment
Proses pembayaran yang dilakukan oleh penghuni masih dilakukan dengan cara bertemu langsung dengan manager pengelola rumah kos.  Perhitungan jatuh tempo payment, berdasarkan sistem bulan berjalan. Setiap penghuni dikenakan tanggal jatuh tempo pembayaran menurut tanggal si penghuni menempati kamar pertama kali. Setelah itu dihitung maju per 30 hari.

Pada saat penghuni melakukan pembayaran bulanan, manager juga akan memberikan nota tagihan jasa/service kepada penghuni, sesuai dengan pelayanan jasa/service yang telah diterima penghuni selama bulan berjalan. Rekapitulasi tagihan jasa/service dikumpulkan manager dari penyedia jasa/service tersebut.

Setelah melakukan payment, Selanjutnya manager akan membuat kuitansi tanda pelunasan pembayaran (dua rangkap) pada bulan berjalan. Kuitansi asli akan diberikan kepada penghuni sebagai tanda bukti pelunasan, dan copiannya disimpan oleh manager, yang nantinya akan dicantumkan dalam report.
Permasalahan yang sering terjadi adalah karena tidak memiliki form pencatatan yang baku dan storing file yang baik membuat manager menjadi sulit untuk menentukan tanggal jatuh tempo yang tetap bagi penghuni di setiap bulannya.

2.2.1.4 Room Management
Manager sebagai pengelola operasional rumah kos, memegang peran strategis yaitu melakukan Room Management. Manager harus memonitor kondisi bisnis, mengawasi keadaan rumah, dan membuat report secara berkala (yakni setiap bulan berjalan dan setiap tahun). Manager bertanggung jawab untuk proses booking dan registrasi penghuni baru (pengelolaan data nama penghuni kamar agar bisa mengetahui identitas penghuni sebenarnya, fasilitas yang akan disediakan dan dipergunakan oleh tiap penghuni kamar). Manager juga bertanggung jawab pada belanja rutin pemeliharaan rumah kos, dan berhak melakukan buying aset rumah kos, untuk peningkatan service kepada penghuni.

2.2.1.5 Report
Dalam as-is sistem, manager melakukan tugasnya yang kompleks tersebut dengan mengandalkan paper-based saja. Sistem yang sekarang juga, belum memiliki form yang baku dalam penulisan report dan pencatatan belanja. Karena belum memiliki form baku dalam registrasi penghuni baru dan pencatatan report, maka manager tidak memiliki standar laporan bulanan dan tahunan yang rapi. Pembuatan laporan yang dilakukan sekarang ini ditulis dengan menggunakan word processing dan dikategorikan menurut tanggal-bulan-tahun penulisan, bukan berdasarkan jenis ataupun karakteristik laporan.

Jadi, dalam laporan ditulis berbagai kegiatan yang terjadi, mulai dari registrasi penghuni baru, neraca cost-benefits, laporan belanja operasional dan keterangan lainnya. Ketidakaturan penulisan laporan seperti ini, membuat pemilik mengalami kesulitan dalam mengevaluasi kemajuan usaha dan membuat forecasting investasi. Laporan yang berdasarkan paper-based juga sering hilang dan tidak lengkap, karena tidak memiliki filing yang baik. Bukti-bukti pembayaran uang sewa kamar dan pembelian barang disimpan tidak teratur sehingga sukar untuk melakukan penelusuran apabila ada complaint dari penghuni mengenai konfirmasi pembayaran. Manager juga mengalami kesulitan untuk memonitor arus kas belanja, karena pencatatan bukti-bukti pembayaran cenderung tidak teratur, dan tidak disimpan dengan baik. Manager sebagai individu yang memegang peranan penting dalam mengelola operasionalisasi bisnis rumah kos ini secara langsung dihadapkan pada masalah serius dalam masalah rekapitulasi laporan.

2.2.2 Analisa Kebutuhan Sistem (TO BE SYSTEM)
Agar bisnis rumah kos ini dapat berkembang dengan cepat di masa depan maka dibutuhkan suatu sistem pengelolaan yang handal, mudah dan efisien. Sistem yang akan diterapkan nantinya adalah sistem pengelolaan rumah kos yang berbasis web. Dengan sistem ini maka dapat memberikan kemudahan bagi pemilik usaha, manager dan penghuni sebagai individu yang terlibat langsung dalam sistem ini.

Bagi pemilik usaha (CV Karya Anugerah Bersama) sistem pengelolaan berbasis web ini dapat memudahkannya dalam mengontrol report income setiap bulannya. Manajer sebagai pelaku utama yang berada di setiap unit usaha rumah kos mendapatkan kemudahan dalam segi operasional. Dan penghuni rumah kos sendiri akan diberikan kemudahan dalam memesan kamar, pembayaran uang kos, menggunakan fasilitas yang pada akhirnya akan meningkatkan kenyamanan penghuni.

2.2.2.1 Viewing
Dengan diterapkannya sistem pengelolaan rumah kos berbasis web ini, maka nantinya calon penghuni rumah kos dapat berselancar di dunia maya (internet) untuk mendapatkan informasi lengkap tentang rumah kos. Dari sekedar melihat-lihat ataupun secara langsung memesan (booking) salah satu kamar yang mereka minat, dan langsung melakukan payment apabila sudah menemukan room yang disukai. Informasi yang diberikan berupa daftar harga tiap kamar berdasarkan tipenya, fasilitas yang diberikan, foto kamar serta kondisi lokasi disekitar rumah kos. Disamping itu juga akan didapatkan informasi mengenai data penghuni, kamar yang tersedia serta layanan atau service yang tersedia.

2.2.2.2 Booking
Proses pemesanan kamar dapat dilakukan dengan cara memilih kamar kosong yang diminati. Setelah itu, calon penghuni dapat menentukan layanan/service tambahan yang dia inginkan. Sistem akan menampilkan total amount yang harus dibayarkan setiap bulannya oleh calon penghuni. Apabila calon penghuni sudah mem-booking kamar, sistem memberikan kesempatan selama 7 hari untuk melakukan transaksi pembayaran. Setelah lewat tujuh hari, dan calon penghuni belum melakukan payment, maka sistem akan menghapus data booking calon penghuni. Sistem akan menganggap, calon penghuni batal memesan kamar. Dan calon penghuni harus melakukan proses booking kembali.

2.2.2.3 Payment.
Apabila calon penghuni sudah bersedia melakukan payment, maka calon penghuni bisa memilih untuk melakukan pembayaran uang muka (down payment) sebagai tanda jadi secara online via bank sebesar 10% dari harga sewa kamar tiap bulannya. Pembayaran dapat dilakukan dengan mentransfer uang tersebut ke rekening yang ditentukan di dalam web tersebut.

Ketika calon penghuni datang ke lokasi rumah kos dan akan menempati kamar yang mereka pesan, maka mereka diwajibkan melunasi sisa pembayaran sewa kamar ditambah uang deposit sebesar 50% dari harga sewa. Pembayaran juga bisa dilakukan secara cash. Pembayaan uang deposit tersebut sebagai jaminan penghuni selama memakai kamar di lokasi tersebut dan akan dikembalikan 100% ketika mereka tidak lagi menjadi penghuni kamar tersebut. Proses pembayaran tersebut masih dilakukan secara transfer via bank.



2.2.2.4 Room Management
Room management dalam bisnis usaha rumah kos yang ditangani oleh manager akan diberikan kemudahan dalam berbagai hal jika nantinya diterapkan sistem pengelolaan rumah kos berbasis web ini. Kemudahan itu antara lain pengelolaan data nama penghuni kamar yang lebih jelas agar bisa mengetahui identitas penghuni sebenarnya. Fasilitas yang disediakan dan dipergunakan oleh tiap penghuni kamar yang berbeda-beda antara penghuni dapat dikontrol sehingga mempermudah membuat invoice pembayaran uang sewa.

2.2.2.5  Report
Bagi pemilik usaha rumah kos dan manager, sistem pengelolaan rumah kos berbasis web ini akan memberikan kemudahan dalam menyimpan dan me-generate laporan keuangan bulanan & tahunan, mencatat pengeluaran harian serta men-generate aset report. Manager akan memiliki form yang standar untuk rekapitulasi transaksi tagihan dan payment yang terjadi di setiap waktu. Filing report juga akan lebih terjamin, karena tersimpan secara digital dan memiliki copy. Pemilik akan mudah memantau laporan yang dibuat oleh manager, dan dapat memeriksa report dimana saja pemilik berada (tanpa harus datang langsung ke lokasi rumah kos).

2.2.3 Permasalahan Yang Dihadapi
Dari pemaparan proses bisnis, baik as-is maupun to-be sistem, dapat dikemukakan beberapa permasalahan mendasar yang dihadapi menjalankan bisnis rumah kos dengan sistem yang sudah ada antara lain:
• Kondisi kamar kosong (tidak dihuni) kerap terjadi dan membutuhkan waktu yang lama jika ingin terisi kembali. Hal ini karena strategi penyebaran informasi kamar tidak genjar, tidak kontinyu dan tidak update.
• Karena pemesanan kamar saat ini masih dilakukan oleh calon penghuni dengan mendatangi secara langsung lokasi kamar kos, sering terjadi calon penghuni tidak bisa bertemu dengan manager secara langsung karena manager tidak berada di tempat.
• Pemesanan kamar atau booking yang dilakukan, masih sangat bergantung pada manager, sehingga seringkali terjadi negosiasi harga (baik harga sewa kamar, maupun harga jasa/service lainnya) antara manager dan calon penghuni diluar sepengetahuan pemilik.
• Penyimpangan-penyimpangan, baik yang disengaja maupun yang tidak disengaja sering terjadi dalam hal pembuatan laporan bulanan.
• Payment dilakukan dengan cara harus bertemu langsung dengan manager, sehingga seringkali membuat penghuni tidak bisa membayar tagihan menurut jatuh tempo karena tidak bertemu dengan manager.
• Konfirmasi pembayaran masih dilakukan secara manual dan hal tersebut dirasakan tidak efektif.
• Selain itu sistem yang ada sekarang ini sangat rentan terhadap faktor kesalahan manusia (human error) dalam proses bisnisnya. Semua kondisi tersebut diatas menjadi lebih kompleks, dengan seringnya owner bepergian keluar kota secara kontinyu, menciptakan hambatan serius dalam hal kontrol pengawasan terutama mengenai report income setiap bulan berjalan.

2.2.4 Usulan Penyelesaian Masalah
Sistem didesain agar dapat mendukung keseluruhan proses bisnis pengelolaan rumah kos, yang pada akhirnya akan meningkatkan efektivitas, efisiensi dan management. Solusi dilakukan dengan menggunakan sistem pengelolaan yang berbasis web. Dimana sistem berbasis web ini akan bertindak sebagai alat bantu proses penyebaran informasi rumah kos, pemesanan kamar, pembuatan laporan dan konfirmasi pembayaran uang sewa. Sehingga menjamin kelangsungan proses bisnis secara kontinyu (24/7 support), menjamin keandalan pencatatan data (baik registrasi, payment dan report), mengurangi terjadinya human error dan pada akhirnya akan memberikan revenue yang langsung maupun tak langsung bagi pengembangan bisnis secara holistik. Aplikasi sistem pengelolaan rumah kos berbasis web ini dibuat dengan interface yang user friendly dan mudah digunakan oleh penggunanya.

Model Analisis Aplikasi Inventory (bag 2)

Bagian ini merupakan lanjutan dari tulisan saya pada bagian Pertama, yang dapat diakses disini:

http://stanlysk.blogspot.com/2012/10/model-analisis-aplikasi-inventory.html

Setelah melakukan analisis proses bisnis yang mendalam, dan kemudian mengidentifikasi kebutuhan, termasuk berbagai permasalahan yang akan diselesaikan, maka langkah selanjutnya adalah membuat model diagram dari sistem aplikasi yang akan dikembangkan.

Kita ketahui bersama bahwa pendekatan Model Driven Architecture (MDA) biasanya akan membuat beberapa jenis model perangkat lunak. Menurut Pressman, maka terdapat 5 jenis model yang bisa dikembangkan.

1. Model Scenario-based

Untuk Model berbasis-skenario, maka akan digunakan Diagram Aktivitas, Diagram Use Case dan Tabel Use Case. Berikut adalah tampilan gambar model tersebut.

Ketiga gambar diatas merupakan sebuah gambar model berbasis skenario, dimana pada bagian Tabel Use Case hanya ditampilkan sebuah deskripsi use case Menerima Item.

2. Model Kelas

Untuk pemodelan kelas, akan digunakan pendekatan model CRC dan Kelas Diagram. Berikut adalah contoh tampilannya.

Selain menggunakan CRC Cards, identifikasi kelas pada sistem aplikasi juga dapat menggunakan teknik yang lebih sederhana, misalnya Teknik Indentifikasi Kata. Untuk teknik ini akan diterangkan pada bagian yang lain.

3. Model Perilaku

Model perilaku akan digambarkan dengan diagram sequence. Dalam hal ini, pemaparan model perilaku digambarkan dengan tiga keadaan berbeda, yakni:

Untuk skenario masuknya item yang telah terdaftar dalam inventori, dalam use case Memasukkan Item:

Untuk skenario keluarnya item yang memiliki kadaluarsa, dalam use case Mengeluarkan Item:

 

Untuk skenario diperlukannya peramalan berdasarkan histori pengeluaran, dalam use case Mengadakan Item:

Kemudian, state diagram digunakan untuk memodelkan keadaan object dari sistem aplikasi yang akan dikembangkan, yakni:

Class Transaksi Keluar dinilai cukup kompleks sehingga di sini diberikan penjelasan lebih lanjut dengan menggunakan behavioral state machine: 

Demikianlah sebuah contoh pemodelan sistem aplikasi inventory.

Model Analisis Aplikasi Inventory

Berikut ini saya berikan sebuah contoh Model Analisis Aplikasi Inventory.

I. Pengumpulan Informasi

Pada bagian pengumpulan informasi, maka tim pengembang mengelompokkan kebutuhan-kebutuhan (fungsional dan non fungsional) yang akan dikembangkan dalam aplikasi.

I.1 Ketentuan Fungsional

Beberapa syarat fungsional yang harus dipenuhi sistem yang dibuat antara lain:

1. Penerimaan Item

• 1.1. Sistem Inventori akan menerima item dari pemasok dan dimasukkan kedalam sistem baik secara manual ataupun menggunakan barcode sistem.
• 1.2. Setiap item masuk akan dicek apakah item tersebut baru ataupun lama yang akan dicek juga kadaluarsanya untuk memudahkan penyusunan Item digudang
• 1.3. Item yang memiliki kadaluarsa harus disusun secara FIFO, yaitu kadaluarsa yang paling dulu harus dikeluarkan paling duluan.
• 1.4. Semua aktifitas penerimaan dilakukan oleh staff inventori.

2. Pengeluaran Item

• 2.1. Setiap item yang keluar merupakan permintaan dari staff lain di perusahaan dan harus tercatat dalam inventori.
• 2.2. Setiap item yang keluar harus diperiksa apakah memiliki kadaluarsa atau tidak, apabila memiliki maka harus dikeluarkan berdasarkan FIFO kadaluarsa,yaitu masa kaduarsa paling dulu harus keluar duluan.

3.  Pengadaan Item

• 3.1. Staf Pengadaan akan bertanggung jawab terhadap semua penyediaan item dalam inventori.
• 3.2   Dalam melakukan pengadaan item, staff pengadaan dapat melihat histori data item yang pernah dikeluarkan dan dibuat dalam bentuk peramalan
• 3.3  Sistem peramalan yang dibuat dapat berbentuk peramalan tahunan, triwulan, dan mingguan.

4. Pembuatan laporan

• 4.1. Semua aktifitas dalam sistem inventori harus tercatat dalam laporan yang dapat digenerate dalam beberapa satuan waktu.
• 4.2.  Laporan mencatat aktifitas transaksi masuk, transaksi kirim, transaksi keluar, transaksi pesan, dan daftar konsinyasi

I.2 Ketentuan Non-Fungsional

Ketentuan non fungsional dibedakan menjadi ketentuan operasional, ketentuan performansi dan ketentuan keamanan, yakni sebagai berikut:

1. Ketentuan Operasional 

1.1. Sistem Inventori akan melakukan pencatatan semua aktifitas inventori dan akan ada aktifitas create,read, update, delete pada maindatabase.

1.2. Sistem akan mencatat detail dari masing-masing item seperti (nama item, jenis item, tanggal kadaluarsa, id item, jumlah item, dan harga)

2. Ketentuan Performansi 

2.1. Sistem harus bisa menangani jumlah kuantitas item yang besar dan otomatisasi menggunakan barcode

3. Ketentuan Keamanan

3.1. Sistem harus membagi hak akses masing-masing staff sesuai otorisasinya.

4. Ketentuan Politik dan budaya 

4.1. Tidak ada ketentuan politik dan budaya

II. Analisis Proses Inventori Dalam Perusahaan

Proses bisnis yang sedang berjalan pada perusahaan X dijelaskan pada bagian ini sebagai proses yang berkaitan erat dengan pemesanan item sebagai penyediaan item. X merupakan suatu perusahaan yang masih baru dan berkembang, sehingga untuk dapat mencapai suatu keputusan melalui birokrasi yang rumit. Dimulai dari Definisi Kebutuhan,  Perusahaan (Pengadaan), Perencanaan pemesanan, Pemesanan, Penerimaan item, Penyimpanan (dalam Gudang), sampai dengan penyaluran ke Warnet/user.

Proses inventori yang sekarang ada didalam X masih manual dan komputer digunakan hanya untuk pengetikan, sehingga memperlambat proses kerja yang ada. 

Proses  inventori dimulai dari adanya permintaan gudang, lalu bagian pengadaan membuat SPK ( Surat Perintah Kerja ). Setelah itu bagian pengadaan akan mengirimkan kepada Pemasok. Sesuai dengan SPK yang diterima Pemasok mengirimkan item, dan panitia penerimaan item bersama staff inventori akan menerima item tersebut. Pencatatan item masuk dilakukan secara manual dan diketikkan kedalam komputer. Sesudahnya item tersebut diserahkan pada penangungjawab item.

II.1. Proses Berjalan

Proses bisnis yang sedang berjalan pada X dijelaskan pada bagian ini sebagai proses yang berkaitan erat dengan pemesanan item sebagai penyediaan item. X merupakan suatu perusahaan yang beru berkembang, sehingga untuk dapat mencapai suatu keputusan melalui birokrasi yang rumit. Dimulai dari Definisi Kebutuhan,  Perusahaan (Pengadaan), Perencanaan pemesanan, Pemesanan, Penerimaan item, Penyimpanan (dalam Gudang), sampai dengan penyaluran ke Warnet.

II.1.1 Definisi Kebutuhan Perusahaan (Pengadaan)

Bagian pengadaan adalah bagian yang menyiapkan pemesanan item yang berhubungan dengan Pemasok. Bagian pengadaan mengadakan pesanan selama tiga bulan sekali. Dalam hal ini bagian pengadaan berhak menentukan Pemasok yang mana yang harus dipilih untuk menerima pesanan yaitu dalam bentuk tender. Pengadaan akan menentukan Pemasok dengan harga murah dan item cukup berkualitas.

II.1.2. Pemesanan

X melakukan perencanaan keuangan dalam waktu setahun sekali. Dalam hal pengadaan item maka X melakukan prediksi yang kurang akurat, karena data-data masih dicatat secara manual, dan terkadang terjadi kelangkaan item atau kadaluarsa. Item yang diperlukan perusahaan pertama kali didaftar kebutuhan setiap warnet, yang kemudian akan disetujui oleh staff inventori dan dibuat arsip. Daftar tersebut akan diserahkan kepada sekretariat untuk dicatat dalam buku serah terima, lalu dilaporkan kepada direktur keuangan untuk disetujui, kemudian diserahkan ke bagian keuangan untuk dimasukkan kedalam anggaran penggunaan. Setelah itu dikeluarkan SPK untuk bagian pengadaan serahkan kepada Pemasok. Bagian pengadaan akan mengadakan kualifikasi untuk menentukan pemasok yang akan dipilih, tetapi sebelumnya para pemasok akan membuat proposal penawaran kepada direktur utama. Setelah dipilih pemasok yang harganya sesuai, maka pengadaan akan ke bagian sekretariat untuk mencatat serah terima dan pemenang lelang. Selanjutnya sekretariat akan mengirimkan kartu kerja (KK),  dan lembar disposisi. Sekretariat akan memisahkan item yang dipesan antara item kadaluarsa dan yang bukan, lalu  bagian Pengadaan  membuat SPK yang disetujui direktur utama. Selanjutnya SPK itu diserahkan kepada sekretariat. SPK kemudian dikirimkan kepada pemasok terpilih, lalu pemasok akan memenuhi pesanan sesuai SPK dan kemudian unit kerjanya mengirimkan item  dan memberikan surat penagihan

II.1.3 Penerimaan Item

Pada proses penerimaan item akan dimulai dari Pemasok. Pemasok akan mengirimkan item bersama dengan SPK yang sesuai dan surat tagihan. Panitia penerimaan item akan memeriksa apakah jumlah dan jenis item yang dikirim oleh pemasok sesuai dengan SPK, jika tidak akan dikembalikan kepada pemasok, jika sesuai lalu panitia penerimaan item akan membuat BAPB (Berita Acara Penerimaan Item) yang selanjutnya Staff inventori akan memeriksa kembali Jenis dan jumlah item, bila sesuai maka akan dibuat arsip dan diserahkan kepada penanggungjawab kelompok item. Setelah item disimpan, bagian keuangan akan memeriksa BPAB dan tagihan. Setelah semua sesuai, maka bagian keuangan akan membuat surat pembayaran untuk ditandatangani oleh direktur keuangan. Selanjutnya bagian keuangan akan membayar jumlah tagihan kepada pemasok.

II.1.4. Penyaluran ke Warnet

Warnet merupakan perpanjangan tangan dari gudang, yang ada di banyak daerah. Warnet langsung berhubungan dengan customer atau pembeli. Warnet akan memesan item ke gudang dengan surat permintaan, lalu staff inventori akan memeriksa pesanan dan diserahkan kepada penanggungjawab gudang apakah item tersebut ada atau tidak. Bila pesanan ada, maka staff inventori akan membuat surat persetujuan dan item akan dikirim ke warnet, bila tidak ada, maka tidak dikirimkan. Staff inventori akan mencatat semuanya kedalam pembukuan dan menyimpan datanya juga dikomputer.

III. Analisa Kebutuhan Sistem
Pada saat ini perusahaan sangat membutuhkan sistem inventori yang dapat mengatur dan menyimpan aliran data pengelolaan item yang memiliki kadaluarsa (voucher). Sistem inventori akan sangat membantu karyawan dalam menangani proses penyimpanan item terutama untuk bagian gudang. Sistem inventori ini juga akan terintegrasi dengan bagian keuangan dan manajemen, sehingga sistem ini akan sangat membantu kebutuhan  perusahaan dalam menangani aliran data item-item yang keluar dan masuk

III.1. Kebutuhan Basis Data
Perancangan basis data untuk sistem inventori pada perusahaan X diperlukan guna menampung kebutuhan data-data yang akan diproses bagi laporan dan perencanaan ke depan. Basis data terdiri dari tabel-tabel yang berisi master item, transaksi masuk, warnet, perjalanan item, fifo dan user. Basis data yang diperlukan cukup besar, karena banyak item yang harus disimpan dan pada akhirnya di back up.

III.2. Sistem Terkomputerisasi
Sistem inventori lama yang digunakan masih manual, oleh sebab itu pada perancangan sistem inventori yang baru ini digunakan sistem inventori yang terkomputerisasi dan berbasis web. Sistem inventori yang baru ini pada akhirnya akan sangat membantu segala aktivitas perencanaan, pemesanan, dan pengelolaan inventorinya. Dengan adanya sistem yang terkomputerisasi ini diharapkan dapat mengurangi human error dan tidak diperlukan pencatatan untuk menyimpan data.

IV.1 Permasalahan
Beberapa permasalahan yang terjadi pada proses bisnis diantaranya adalah:
• alur penyediaan item panjang dan cukup rumit, sehingga membutuhkan waktu yang relatif lama untuk penyediaan suatu item.
• Pengaturan keluar masuk item di gudang, menggunakan sistem manual sehingga menyebabkan :
- Pengadaan item jadi lambat
- Pengeluaran detail susah dilacak
- Penggunaan item oleh tiap divisi susah dikontrol, mengakibatkan perancanaan penyediaan  item menjadi sulit.
- Kemungkinan terjadinya human error tergolong tinggi
- Laporan kepada bagian manajemen  kurang akurat, sehingga pengambilan keputusannya pun tidak akurat.
• Karena perencanaan yang kurang baik, ada kemungkinan item menumpuk (overstock) sehingga item ada yang kadaluarsa, atau terjadinya kelangkaan item yang sedang dibutuhkan.
• Kurangnya sumber daya manusia yang memadai untuk mendukung Aplikasi yang akan dibuat.

IV.2. Usulan Penyelesaian Masalah
Sistem didesain agar rantai aliran item dapat berjalan dengan baik dan efektif (waktu) melalui perencanaan, pembuatan model, penganalisaan, pengembangan dan pengontrolan.
Untuk masalah yang berkaitan dengan perusahaan X ditawarkan solusi berupa Aplikasi inventori berbasis web, yang bertindak sebagai alat bantu, dalam menangani pengadaan item  untuk memudahkan  dalam hal perencanaan, pemesanan, dan pengelolaan inventorinya, sehingga dapat mempercepat aliran item, pengontrolan penggunaan item lebih baik, dapat membuat laporan yang lebih akurat, dan meminimalkan terjadinya human error.
Aplikasi pengadaan item ini, akan dikembangkan dengan mempelajari histori pengadaan dari waktu-waktu sebelumnya yang dapat memperkirakan waktu pemesanan dan jumlahnya, sehingga dapat menghindari kekurangan ataupun overstock item.
Aplikasi dibuat dengan interface yang user friendly dan mudah digunakan oleh pengguna Aplikasi.

SRS Aplikasi Pembayaran (bagian 2)

Tulisan ini adalah lanjutan dari bagian ini:

http://stanlysk.blogspot.com/2012/10/srs-aplikasi-pembayaran.html

III.4 Behavioral Models : Sequence Diagram

Sequence Diagram digunakan untuk menggambarkan kebiasaan/behavior suatu aplikasi. Selain itu, secara spesifik suatu Sequence Diagram menggambarkan sebuah skenario yang spesifik. Diagram ini menampilkan sejumlah objek dan pesan yang dilewatkan di dalam seuah Use-Case.

Tujuan pembuatan Sequence Diagram, yaitu :

1. menggambarkan interaksi antar objek di dalam dan di sekitar sistem (termasuk pengguna, display, dan sebagainya) berupa message yang digambarkan terhadap waktu.

2. Menggambarkan skenario atau reangkaian langkah-langkah yang dilakukan sebagai respon dari sebuah event untuk menghasilkan output tertentu.

III.5 Flow Models : Data Flow Diagram

Data Flow Diagram (DFD) merupakan suatu alat yang membantu seorang analis untuk menggambarkan interaksi antara proses dan data. Selain itu, DFD juga menggambarkan dimana data akan digunakan (diambil dari data storeage) dan data akan disimpan.

Sebuah DFD merupakan representasi grafis yang menggambarkan aliran informasi dan perubahan yang terjadi sehingga data berubah dari masukan menjadi keluaran. Data Flow Diagram digunakan untuk menggambarkan sebuah sistem atau perangkat lunak pada berbagai tingkatan abstraksi.

III.6 Activity Diagram

Activity diagram membantu seorang analis untuk memodelkan interaksi antara User dan Customer. Sehingga memudahkan Pengembang untuk menentukan proses yang terjadi di dalam suatu proses.

III.7 Entity Relationship Diagram

Entity Relationship Diagram (ERD) awalnya ditujukan sebagai model database relasional. Namun, penggunaan saat ini telah berkembang lebih dari itu.Di dalam ERD terdapat beberapa komponen utama, yaitu : obyek data, atribut, relasi, dan beberapa penentu tipe. Tujuan Utama ERD adalah untuk merepresentasikan obyek data dan relasi-relasinya.

Pemodelan data logika dikembangkan dalam empat tahapan, sebagai berikut :

1. Model Data Konteks

Model data ini digunakan untuk menentukan lingkup proyek yang tidak terlalu detail dalam membahas entitas dan aturan bisnis.

2. Model Data Key-Based

Model data untuk mengidentifikasikan setiap entitas dengan menambahkan entitas asiosiatif dan menyertakan primary key

3. Model Data Fully-Attributed

Model Data yang menyertakan semua atribut deskriptif secara menyeluruh

4. Model Data Ternormalisasi

Model data yang telah melalui proses normalisasi.

Normalisasi adalah sebuah teknik pengorganisasian data ke dalam tabel-tabel untuk memenuhi kebutuhan pengguna. Tujuannya untuk menhilangkan kerangkapan data, mengurangi kompleksitas data dan mempermudah modifikasi data.

SRS Aplikasi Pembayaran

Berikut ini saya berikan contoh tentang Pembuatan Dokumen SRS. Dokumen ini awalnya dikerjakan oleh Kelompok 5 Mata Kuliah RPL, angkatan 2009 Prodi Teknik Elektro Unsrat.

Bab Analisa Kebutuhan.

Analisa Kebutuhan merupakan sebuah tugas atau pekerjaan di dalam ilmu Rekayasa Perangkat Lunak yang menjembatani antara system-level requirement engineering dan software design.

Suatu proses Rekayasa Kebutuhan (Requirement Engineering) akan menghasilkan spesifikasi Perangkat Lunak (mulai dari fungsi/function, data, dan kebiasaan/behavior), mengidentifikasikan antarmuka antara Aplikasi dan elemen sistem lainnya, dan menentukan standarisasi yang harus dipenuhi oleh Perangkat Lunak.

Requirement Analysis mengijinkan Software Engineer/Analyst untuk memperbaiki spesifikasi software dan membuat model dari spesifikasi tersebut. Proses ini memberikan suatu hasil kepada Software Designer, berupa representasi informasi, fungsi, dan kelakuan yang bisa di terjemahkan menjadi data, arsitektur, antarmuka, dan rancangan component.

Dan akhirnya, spesifikasi kebutuhan akan memberikan pengertian kepada pengembang dan pengguna untuk membuat suatu aplikasi yang berkualitas.

II.1 Kebutuhan fungsional dan non fungsional

Kebutuhan fungsional menggambarkan kemampuan utama suatu aplikasi. Seorang Software Engineer akan menentukan fungsi-fungsi utama yang harus ada di dalam aplikasi, dimana fungsi-fungsi tersebut didapatkan dari proses Requirement Gathering yang dilakukan seorang Software Engineer terhadap User/Stakeholders.

Dari fungsi-fungsi utama tersebut, akan diperluas lagi menjadi  fungsi-fungsi yang lebih spesifik melakukan suatu pekerjaan. Pada akhirnya, fungsi-fungsi ini akan menjadi fitur ari aplikasi tersebut.

Kebutuhan Non-Fungsional adalah kebutuhan yang harus dipenuhi agar suatu Perangkat Lunak bisa dijalankan. Kebutuhan ini bukan merupakan fungsi utama, namun akan menentukan kualitas dari suatu Perangkat Lunak.

Kebutuhan Non-Fungsional Aplikasi Pembayaran ( Kasir )

1. Requirement Operasional

1.1 System bisaberjalan di semua platform yang menggunakan JVM

1.2 System bisamembuat Document HTML dan Word

2. Security Requirements

System menggunakan user Authentification untuk mencegah orang-orang yang tidakberhak

Kebutuhan Fungsional Aplikasi Pembayaran ( Kasir )

1. User melakukan LOGIN kedalam System

1.1 User bisa login sebagai admin

1.2 User bisa login sebagai user biasa

2. System bisamenghitungpembayaran

2.1 System bisamencari data berdasarkan ID barang

2.2 System bisamenghitung total pembayaranpelanggan

2.3 System bisamenghitungpembayarandankembalianpelanggan

3. bisamencetakstrukpembayaranpelanggan

4. bisamembuatlaporan (Admin only)

4.1 System bisamembuatlaporanharian

4.2 System bisamembuatlaporanmingguan

4.3 System bisamembuatlaporanbulanan

5. bisa me-manage inventory barang (Admin only)

5.1 System bisamenambah data baru

5.2 System bisamengedit data lama

5.3 System bisamenghapus data

System bisa menambah dan mengurangi jumlah barang

Bab Pemodelan Kebutuhan
Setelah melakukan Analisa kebutuhan dan mendapatkan kebutuhan-kebutuhan Perangkat Lunak baik dalam hal Data, Fungsi, dan Kebiasaan. Maka, kebutuhan-kebutuhan itu perlu dimodelkan, agar mudah dipahami oleh Pengembang dan Pengguna Aplikasi.

Apa itu Pemodelan Kebutuhan?

"Tulisan merupakan sebuah alat yang hebat untuk berkomunikasi, tetapi bukan cara yang tepat untuk merepresentasikan kebutuhan suatu Perangkat Lunak komputer.Pemodelan Analisis menggunakan kombinasi antara teks dan bentuk-bentuk diagram untuk menggambarkan suatu kebutuhan data, fungsi, dan kebiasaan dengan cara yang relatif mudah dimengerti, dan yang lebih penting, berusaha untuk memastikan kebenaran, kesempurnaan, dan konsistensi.”

Cara-cara membuat Pemodelan Analisis :
Data, fungsi, dan kebiasaan digambarkan dalam beberapa diagram yang berbeda. Model Data mendefinisikan object, atribut, dan hubungan. Model Fungsional mengindikasikan bagaimana data berubah di dalam sistem. Model kebiasaan menggambarkan akibat dari suatu kejadian

Pada dasarnya terdapat 4 model utama untuk menggambarkan suatu kebutuhan Aplikasi, yaitu :
• Model berbasis Skenario (contohnya Use-Case dan User Stories)
• Modela Kelas (contohnya Class Diagram dan Collaboration Diagram)
• Model Data (contohnya Data Flow Diagram dan Entity Relationship Diagram)
• Model Perilaku (contohnya State Diagram dan Sequence Diagram)

III.1 Functional Decomposition Diagram

Sebelum memulai Pemodelan Analisis, diawali dulu dengan menentukan fitur-fitur Aplikasi yang akan dibangun. Functional Decompotition Diagram (FDD) adalah sebuah tool yang bisa membantu analis untuk mendefinisikan proses bisnis dimulai dari kegiatan utama dan dilanjutkan dengan kegiatan yang lebih detail atau spesifik.
Pada prinsipnya, dengan membuat FDD, stakeholders dan analis bisa menemukan dambaran umum dari setiap fungsi-fungsi kerja (dari sudut pandang organisasi) dan dapat menempatkan dengan tepat, pada bagian apa dari fungsi-fungsi kerja yang ada, perangkat lunak akan dibangun. Ini disebut model konteks perangkat lunak.
Di dalam FDD, digambarkan semua kemampuan sistem secara umum dan secara spesifik.

III.2 Scenarion Based Models : Use-Case Diagram

Use-Case dibuat untuk menentukan elemen apa yang terdapat di luar sistem dan yang akan berinteraksi dengan sistem, dalam bentuk kegiatan atau aktivitas tertentu.

III.3 Class Models : Class Diagram

Class Diagram bukan hanya merupakan diagram yang paling banyak digunakan, tetapi juga merupakan diagram yang mempunyai jangkauan terbesar dalam Konsep Pemodelan. Bukan hanya elemen dasar yang dibutuhkan setiap orang, bahkan konsep tingkat lanjut yang jarang digunakan.
Sebuah Class Diagram menggambarkan tipe-tipe ibjek di dalam sistem dan berbagai jenis hubungan yang terdapat dalam sistem itu. Class Diagram juga menampilkan properti dan operasi suatu kelas dan prasyarat yang dibutuhkan sebagai cara agar terhubung denga objek-objek;

Tujuan pembuatan Class Diagram adalah :
1. menggambarkan keadaan(atribut/properti) suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut(fungsi/method).
2. Menggambarkan struktur dan deskripsi class, package dan objek beserta hubungan satu sama lain seperti containment, pewarisan , asosiasi, dan lain-lain.

Membangun Model Spesifikasi Software

Apa yang dimaksud dengan Membangun Model Spesifikasi Software?

Kita tahu bersama, setelah tim pengembang dan stakeholders selesai melakukan elisitasi dan pendefinisian persyaratan perangkat lunak, maka langkah selanjutnya adalah membangun model spesifikasi perangkat lunak. Model spesifikasi perangkat lunak, merupakan "gambaran" awal dari setiap kebutuhan fungsional (dan non fungsional) yang akan dikembangkan, sebagai fungsi (atau fitur) perangkat lunak tersebut.

Proses membangun model spesifikasi perangkat lunak, tidaklah sulit, namun memerlukan fokus perhatian yang extra dari tim pengembang. Aktivitas ini merupakan tugas system analyst, dengan tujuan, membangun model sistem perangkat lunak dgn "bahasa" yang dapat dipahami oleh tim pengembang dan, tentu saja stajeholders. Membahasakan sistem perangkat lunak dalam "bahasa" teknis, namun harus dapat dipahami oleh stakeholders adalah tantangan terbesar yang harus dihadapi oleh system analyst.

Biasanya, setelah daftar kebutuhan perangkat lunak, disepakati oleh stakeholders dan tim pengembang, maka system analyst akan segera membuat apa yang disebut requirements model. Inilah yang disebut representasi teknis dari sistem perangkat lunak yang akan dibangun. Proses pemodelan teknis dari requirements software ini, akan menggunakan teks dan diagram.

Aturan-aturan pemodelan spesifikasi teknis, ditulis oleh DeMarco, hingga kini masih digunakan dalam disiplin rekayasa perangkat lunak modern. Alan Davis mengatakan bahwa: ... Suatu pandangan kebutuhan dari sudut pandang tertentu tidak memadai untuk memahami atau mendeskripsikan perilaku yang dikehendaki dari suatu sistem yang kompleks ..., atas dasar pertimbangan DeMarco dan Alan Davis tersebut, maka disiplin pemodelan spesifikasi sistem perangkat lunak, dibedakan menjadi beberapa sudut pandang, yakni:
1). Model berbasis Skenario (scenario-based); model ini merupakan model perangkat lunak, dari sudut pandang user atau pengguna;
2). Model Data; yakni merupakan model yang menjelaskan bagaimana data ditransformasikan dalam sistem perangkat lunak yang akan dikembangkan;
3). Model Kelas (class-oriented); yakni merupakan model yang mendefinisikan objects, attributes serta relasi antar kelas yang ada;
4). Model berorientasi aliran (flow-oriented); adalah model yang menjelaskan bagaimana hubungan antara elemen fungsional dan data berinteraksi; bagaimana data dikelola, saat melintasi sistem perangkat lunak;
5). Model Perilaku (behavioral); yakni menggambarkan bagaiman sistem perangkat lunak "berperilaku" terhadap event-event yang datang dari luar sistem.

Jadi, banyak "model" bukan untuk membingungkan tim pengembang terlebih stakeholders. Justru dengan memandang sistem perangkat lunak dari "berbagai" perspektif, maka tim pengembang dan stakeholders akan semakin "memahami" perangkat lunak yang akan dikembangkan. Singkatnya, model membantu "proses pendefinisian" perangkat lunak.

Menurut Pressman, terdapat 3 tujuan dari tahap ini, yaitu:
1). untuk menjelaskan apa yang diinginkan oleh stakeholders;
2). untuk meletakkan dasar2 bagi tahap sottware design berikutnya;
3). untuk menajamkan sekumpulan requirements perangkat lunak, yang dapat divalidasi, saat akan membangun sistem perangkat lunak tersebut.

Requirements Software (again)

Sekali lagi, saya ingin menulis tentang Requirements Perangkat Lunak. Mengapa sekali lagi, karena sebenarnya sudah banyak tulisan saya tentang langkah-krusial ini. Silahkan melihat link URL dibawah ini untuk acuan tulisan-tulisan saya sebelumnya ....
1. Tentang memahami software requirements bisa dilihat di:
http://stanlysk.blogspot.com/2012/09/memahami-requirements-perangkat-lunak.html

dan disini:

http://stanlysk.blogspot.com/2012/07/requirements-engineering.html

2. Tentang Teknik QFD dalam pendefinisian Requirements Perangkat Lunak, dapat dilihat disini: 

http://stanlysk.blogspot.com/2012/10/qfd-dan-elisitasi-software-requirements.html

Semua tulisan diatas, sudah menjelaskan banyak mengenai pengertian, metode dan dokumentasi Persyaratan Perangkat Lunak.

Berikut ini, saya ingin memberikan sebuah kumpulan tautan lainnya, terkait metode pendefinisian perangkat lunak.

1. Tentang Pengertian Requirements Perangkat Lunak:

http://www.barbarabea.com/?page_id=134

2. Tentang menggunakan Excel dalam Melengkapi Pendefinisian Perangkat Lunak, bisa dilihat disini.: http://www.barbarabea.com/?page_id=11

Tulisan diatas, merupakan sebuah teknik yang sedikit berbeda, karena tidak menggunakan pendekatan buku teks, melainkan berfokus pada pendekatan praktisi. Namun demikian, pendekatan tersebut layak untuk dicoba, mengingat adanya kelemahan dalam bahasa notasi UML.

Sebuah slide prsentasi mengenati teknik pendefinisian perangkat lunak juga dapat ditemukan disini: http://www.barbarabea.com/wp-content/uploads/2011/07/Requirements%20Patterns%20Presentation%202011%20Public%20Domain.ppt

Demikian, kiranya dapat bermanfaat menambah khasanah pengetahuan dan kompetensi kita dalam mendefinisikan perangkat lunak!

Membuat Use Case dan Use Case Description 2

Berikut ini adalah sebuah teknik pembuatan Use Case Diagram pada studi kasus aplikasi berbasis Web 2.0. Langkah-langkah penentuan requirements, mengikuti pendekatan agile, yakni dimulai dengan pendefinisian masalah, kemudian dilanjutkan dengan pemodelan permasalahan. Persyaratan perangkat lunak, dikelompokkan dengan teknik QFD, dan menghasilkan persyaratan fungsional dan non fungsional.

1.1 Background

The using of internet by the government instituion and society rapidly grow. Internet user grows in number and services. North Sulawesi Local Government, especially the office of Investment Expert Staff seeing this phenomena as opportunity to promote exotic tourism. Using Web 2.0 technology to create competitive advantage as strategic and crusial considerations to foster investment climate for North Sulawesi tourism. Utilization of Web based 2.0 technology is expected to improve service, market share and shaping public opinion by providing targeted and comprehensive information on North Sulawesi exotic tourism, which is easily obtained by anyone, anywhere, anytime using any device.

1.2 Problems

Exotic tourism places owned by North Sulawesi Province is threatened by the onslaught of tourism promotions of some new netrants such as Wakatobi and Raja Amplat. While the number of foriegn tourist realtively declined over the 5 years before, the tourism potential of Bunaken National Park is not fully optimized by stakeholders. Lack of comprehensive information about Bunaken National Park is one of the resons for the decline of foreign tourist visiting. Structuring a comprehensive information related to the potential of tourism placesm tourism activities is one of a strategic solution that must be done to fix the pre-eminent tourism promotion. In addtion, the information must be displayed in such as interative user interface, constantly available for 24/7 and able to be found easily. Web Portal Amazing North Sulawesi is expected to be effective solution.

1.3 Functional Requirements

List of functional requirements are:
1). Viewing Info
1.1 The system can display information about the ads, profile, headline news, main headline news, North Sulawesi Profile and general articles.
1.2  The system can display links.
1.3  The system can displat visitor counter for each pages.
1.4 The system can display currency value and weather report.
2). Managing Info
2.1 Input ads, profile, news, headline, main headline and articles.
2.2 Edit ads, profile, news, headline, main headline and articles.
2.3 Delete ads, profile, news, headline, main headline and articles
2.4 Save ads, profile, news, headline, main headline and articles.
3). Collaborating
3.1 The system must provide facilities for  posting and reply comments for news, headline, main headline and articles.
3.2 The system must provide sharing and collaborating tools for social media, i.e: facebook, twitter dan G+.
3.3  The system musti provide polling feature.

1.4. Non-Functional Requirements
For non-functional requirements are distinguished in terms of operational, performance and security. Some non-functional terms to be met by the system are as follows:
Operational Requirements (the physical and technical systems that apply):
1) The system must be displayed in Indonesian and English
2) The system can be operated on a smartphone, desktop and notebook on the optimal display resolution.
3) The system must be able to work on all web browsers.
4) The System must running through the operating system Windows and Linux.
Performance Requirements (speed, capacity and reliability):
1) The system must be used or operated within 24 hours a day, 7 days a week and 356 days a year.
2) Each user interaction with the system should not be longer than 3 seconds.
Security Requirements
1) The system must provide privilege access for groups of admins and users.
2) The system must provide verification procedure for posting comments.

Gambar Use Case dan Use Case Description adalah sebagai berikut:

Membuat Use Case dan Use Case Description

Membangun use case model, merupakan salah satu kompetensi yang HARUS dikuasai oleh seorang software engineers. Apalagi saat menggunakan pendekatan model driven engineering dan membangun aplikasi berorientasi object, maka kemampuan membuat use case model survey, menjadi sangat krusial. Tentu saja, dengan melatih diri berulang-ulang, maka kompetensi membuat use case model survey akan makin baik.

Berikut saya berikan sebuah contoh, membuat use case model pada aplikasi tes online. Langkah penyelesaiannya adalah 1.1 Membuat deskripsi masalah yang akan diselesaikan; 1.2 Membuat model penyelesaian masalah. Kemudian melakukan 1.3 Requirements Capturing. Berikut adalah penjelesan detailnya:

1.1 Problem description

This case study comprises an electronic examining system. A teacher makes use of the system to give an examination to her/his students. We assume that creating an examination is a separate task performed out of the scope of the examining system. This system should be made available on the web, so that both the teacher and the students have remote access to it. 

A teacher creates a test and stores this test into a test repository. Afterwards the teacher can assign this test to a group of students. There can be different types of tests but all of them must have a deadline defined by the teacher. So, for example the teacher may propose an examination in which the students are requested to write an essay about a certain subject or to solve some questions. The former activity may take several days to be completed while the latter may take only a limited number of minutes. The teacher also evaluates a student’s test answer by attaching comments and grading it.

When a student access the system, this student can consult his/her personal profile and do a test. A student personal profile contains his/her personal information, the list of tests to be done and the answers, grades and comments of completed tests. A student does a test by submitting the answers for this test. Once an answer is submitted it can not be resubmitted. All the student personal profiles are stored in a profile repository, however the access of a student is limited to his/her personal profile.

1.2 Problem modelling

This section reports the results of case study modelling activities. Each of the following subsections presents some of the results of these activities, viz., requirements capturing and analysis. The complete UML documentation of this case study can be found in Fig below. The development of this case study was performed making use of Rational Rose as a modelling support tool.

1.3 Requirements capturing

The requirements of the electronic examining system were captured by means of a use case diagram according to the following steps:

1. Identification of the actors;

2. Identification of the use cases;

3. Description of each use case.

1) Process Identification of the Actors

The identification of the actors of the system was straightforward. We simply identified the roles of the potential users of the system. The identified actors are the following:

• Student, who is a person who takes exams and consults some personal and test related information that are stored in his/her profile. The student has limited access rights to the system;

• Teacher, who is a person that assigns tests to groups of students and grade the assigned tests. The teacher has full rights to the system.

2) Process Identification of the use cases

The identification of the use cases was more complex. As a rule of thumb to identify a use case we considered the following criteria: a use case should represent a sequence of related actions that provide some functionality to the actor when successfully executed. Whenever a variation on a normal behaviour or a repetition of a separate use case were identified, the extends and uses relationships between use cases were used. 

The identified use cases are the following:

• Access Student Profile, which is used to access the student profiles. All student profiles are kept in a profile repository ordered according to the student groups that the student belongs. The teacher reads and writes the student profile, while the student reads the student profile. The student can write to his/her profile only the test results. 

• Access Test Repository, which is used to access the test repository. The teacher can read and write to the test repository, while the student can read from the test repository only the tests that are assigned to his/her profile.

• Assign Test, which is used to select a test from the test repository and assign the selected test to a group of students.

• Consult Profile, which is used to consult a student personal profile. The student profile contains the student personal information, the tests to be done, the test answers and the grades received so far. The student profiles are stored in a profile repository. A student has access rights only to his/her personal profile.

• Do Test, which is used to do a test. The student selects one of the tests from his/her profile. The student retrieves this test from the test repository. Then, the student does the test and submits the test answers, which are stored in his/her profile.

• Evaluate Test, which is used to evaluate a performed test. The evaluation of a test consists of making comments concerning the answers provided and grading the test. The teacher first selects a test to be evaluated and then retrieves from the student profiles some or all the answers provided for that test.

• Register Test, which is used to register and store one test in the test repository.

Each use case was described briefly, by means of few sentences that summarises the actions (see previous use case descriptions), and in a step-by-step manner, by means of a detailed description of what the system needs to do when interacting with its actors. 

Detailed Use cases Description

1. Access Student Profile

This use case is used to access the student profiles All student profiles are kept in a profile repository ordered according to the student groups that the student belongs. The teacher reads and writes the student profile, while the student reads the student profile. The student can write to his/her profile only the test results. 

----------------------------------------------

Detailed use case description (I):

1 - Teacher assigns a test to group of students.

Detailed use case description (II):

1 - Teacher retrieves a student test answer

2 - Teacher adds a comment to the test answer.

3 - Teacher grades the test answer.

PS: 2 is optional. 1/2/3 can be executed in any order.

Detailed use case description (III):

1 - Student browses his/her personal information.

2 - Student browses his/her test list.

3 - Student browses his/her grade list.

4 - Student browses his/her test comments.

PS: 1/2/3/4 can be executed in any order.

Detailed use case description (IV):

1 - Student selects a test to do.

2 - Student does a test, storing the test result into his/her personal profile.

2. Access Test Repository

This use case is used to access the test repository. The teacher can read and write to the test repository, while the student can read from the test repository only the tests that are assigned to his/her profile.

----------------------------------------------

Detailed use case description (I):

1 - Teacher stores a test into the test repository.

Detailed use case description (II):

1 - Teacher browses the tests available in the test repository.

Detailed use case description (III):

1 - Teacher retrieves a test from the test repository. 

Detailed use case description (IV):

1 - Student reads a test from the test repository with restrictions.

3. Assign Test 

This use case is used to select a test from the test repository and assign the selected test to a group of students.

---------------------------------------------

Detailed use case description:

1 - Teacher browses test list/repository

2 - Teacher select a test and assign it to a group of students. The selected test is added to the test list of the group of students.

4.Consult Profile

This use case is used to consult a student personal profile. The student profile contains the student personal information, the tests to be done, the test answers and the grades received so far. The student profiles are stored in a profile repository. A student has access rights only to his/her personal profile.

-------------------------------------------

Detailed description:

1 - Student browses his/her personal information.

2 - Student browses his/her assigned test.

3 - Student browses his/her grades.

4 - Student browses his/her test comments.

PS: 1/2/3/4 can be executed in any order.

5. Do Test

This use case is used to do a test. The student selects one of the tests from his/her profile. The student retrieves this test from the test repository. Then, the student does the test and submits the test answers, which are stored in his/her profile.

----------------------------------------------

Detailed use case description:

1 - Student selects a test from the test list.

2 - Selected test is loaded from the test repository.

3 - Student does the test. Test answers are stored stored in the student profile.

6. Evaluate Test

This use case is used to evaluate a performed test. The evaluation of a test consists of making comments concerning the answers provided and grading the test. The teacher first selects a test to be evaluated and then retrieves from the student profiles some or all the answers provided for that test.

----------------------------------------------

Detailed description:

1 - Teacher retrieves the test from the test repository.

2 - Teacher retrieves student test answers from the profile repository.

3 - Teacher adds comment to the student test 

4 - Teacher grades the student test

PS: 3 is optional

7. Register Test

This use case is used to register and store a test into the test repository.

--------------------------------------------

Detailed use case description: 

1 - Teacher registers a test to the test repository. The test is stored into the test repositor.

Gambar Use Case dari Studi Kasus diatas adalah ...