Tutorial Rational Rose: Deployment Diagram

Komponen deployment diagram:
Processor
Device
Connection

Deployment diagram menampilkan processors, devices, and connections. Setiap model berisi deployment diagram tunggal yang menunjukkan hubungan antara processor and device dan penempatan dari processe to processor.

Processor merupakan komponen perangkat keras yang mampu mengeksekusi program.

Device merupakan perangkat keras yang tidak memiliki kemampuan untuk memproses. Setiap device memiliki nama yang dapat bersifat umum seperti: modem, terminal, dll.

Sebuah connection menunjukkan sebuah bagian komunikasi antara  dua prosesor, dua device, atau sebuah prosesor dan sebauh device. Sebuah connection biasanya menyatakan penggandengan hardware secara langsung, seperti kabel RS232, dan dapat juga menyatakan penggandengan yang tidak langsung.

Membuat deployment diagram :
1. Membuat deployment diagram: click dobel pada deployment view dalam browser model.
2. Untuk membuat node: Click icon processor    pada toolbar Click di deployment diagram untuk menempatkan node beri nama pada node yang baru dibuat.
3. Untuk membuat koneksi : Click icon connection    pada toolbarClick Node  yang merupakan ‘client’ drag (connectin line) ke node yang merupakan ‘supplier’Click dobeltuliskan nama koneksitekan OK.


Mengatur sifat dan hubungan dari prosesor dalam model:
1. Pilih icon processor pada deployment diagram atau pada browser Click dobel
Dengan langkah seperti diatas dapat dibuat 5 buah node yaitu : Registration, Database, Main Building, Dorm, Library.
Kelima node ini terkoneksi sebagai berikut :
Node Connected to Node
Registration Database
Registration Main Building
Registration Dorm
Registration Library

Hasilnya seperti pada gambar berikut :

Seri Tutorial Rational Rose: Statechart Diagram

Statechart diagram merupakan model perilaku yang dinamis dari class secara individual maupun beberapa bentuk dari obyek. Semua itu menunjukkan deretan dari state yang dilakukan obyek melalui event yang menyebabkan sebuah transisi dari satu ke aktifitas yang lain, dan beberapa aksi yang menghasilkan dari satu state atau aktifitas yang berubah. Statechart diagram fokus pada state dan secara bentuk digunakan untuk memodelkan tahapan yang nampak terpotong-potong dari sebuah aktivitas yang kontinyu dari obyek. Diagram ini memiliki hubungaan yang tetrtutup dengan activity diagram. Activity diagram fokus pada aktifitas dan pada pemodelan deretan aktivitas dari proses.

Komponen statechart dapat terdiri dari beberapa komonen seperti:

State  

Decision  

Transition  

State Start  

State End  

Setiap state menyatakan sebuah keadaan yang diberi nama ketika sebuah obyek  merasa mantap dengan beberapa  keadaan atau mengunggu beberapa kejadian.

 Sebuah statechart diagram biasanya terdiri dari satu start state dan banyak end state.

Transition menghubungkan beberapa state dalam diagram

Decision menyatakan sebuah lokasi khusus pada statechart diagram dimana sederetan aktivitas dapat bercabang bertujuan untuk pada pengamanan keadaan. Cabang keluaran dari Condision dapat lebih dari dua, tetapi biasanya sebagian besar hanya berisi dua keluaran yang menyatakan bilangan biner.

Sebuah Activity menyatakan bentuk dari sebuah tugas atau perwakilan kerja dari sederetan aktivitas. Activiy dapat juga menyatakan pelaksanaa dari sebah statement dalam sebuah procedure. Nama activity harus unik dengan aktivitas khusus yang dilakukan, jika ada nama yang sama maka itu dianggap merupakan activity yang sama.

Membuat Statechart Diagram
1. Click kanan pada elemen model yang diperlukan untuk atribut, association, atau elemen model yang tampil di browser componen view.
2. Pilih New  statechart Diagram.

Gambar Membuat Statechart Diagram dari Class

Penambahan State
1. Pilih State    dari toolbox pada toolbar.
2. Click pada statechart diagram dimana state harus berada.
Atau
1. Pilih Tools  Create  State.
2. Click pada statechart diagram dimana  state harus berada.

Penambahan detail State
Actions on states can occur at one of four times: on entry, on exit, do, or on event.
State memiliki informasi tentang aksi yang harus dilakukan. Ada dua tipe aksi yang dilakukan yaitu:
● Action (on entry, on exit, do, atau on event)
● Send Event

Menambah sebuah aksi
1. Pilih State yang ingin dimodifikasi
2. Buka window Specification dari state terpilih: Click kanan Open Specification
3. Pilih Action
4. Click kanan pada kotak Action
5. Pilih Insert dari menu pop up
6. Click dobel new action yang terbentuk atau click kanan  specification
7. Masukkan aksi dalam field Action (Action atau Send event)
8. Masukkan waktu pelaksanaan action:
● On Entry : untuk Entry action
● On Exit : untuk Exit action
● On Event : untuk Event

Gambar Membuka window State Specification

Gambar Menambah Action pada Specification.

Gambar Menambah Action pada Specification.

Penambahan Transisi
Transition merupakan pergerakan dari satu state ke yang lain. Menset transitionspada diagram menggambarkan bagaimana obyek bergerak dari stau state ke state yang lain. Transition juga dapat terjadi membalik ke diri sendiri.

Membuat transition:
1. Pilih icon Transition   dari toolbar.
2. Click pada state sebagia awal transition.
3. Drag garis transition ke state dimana transition harus berakhir.

Membuat reflexive transition:
1. Pilih icon  Transition to Self    dari toolbar.
2. Click pada state dimana reflexive transition yang harus terjadi.
atau
1. Pilih Tools  Create  Loop.
3. Click pada state dimana reflexive transition yang harus terjadi.
atau
1. Pilih icon Transition dari toolbar.
2. Click pada state yang terjadi reflexive transition .
3. Drag garis transition keluar dari state  Click sekali Drag ke state awal garis transition.

Menambahkan dokumentasi transition:
1. Click dobel  pada transition yang diinginkan untuk membuka window specification.
2. Pilih General.
3. Ketikkan dokumentasi pada field Documentation.

Menambahkan Special State
Ada dua tipe special state yang dapaat ditambahkan ke diagram yaitu: Start stae dan Stop state.
Start state
1. Pilih icon  Start State    dari toolbar.
2. Click pada the statechart diagram dimana Start State harus dinyatakan.
Stop state
1. Pilih icon End State    dari toolbar.
2. Click pada statechart diagram dimana End State harus diletakkan.

Menggunakan Nested States
1. Pilih State dari toolbar.
2. Click pada state dimana  untuk membuat new state dalam state tersebut.

Penambahan decision
1. Pilih icon decison    dari toolbar.
2. Click pada statechart diagram dimana Decison harus diletakkan.

Penambahan Synchronization
1. Pilih icon horizontal Synchronization     dari toolbar.
2. Click pada statechart diagram dimana horizontal Synchronization  harus diletakkan.

Catatan:
Jika icon pada toolbar yang diinginkan belum ada dapat dilakukan penambahan dengan cara sebagai berikut:
Cick kanan pada toolbarCustomizepilih icon yangh diinginkan dari sebelah kiriAdd  close

Seri Tutorial Rational Rose: Collaboration Diagram

Collaboration diagram digunakan untuk menunjukkan aliran melalui skenario khusus dari sebuah use case.  Fokus yang dikerjakan adalah relasi antar obyek.

Membuat Collaboration Diagram
Gambar dibawah  menggambarkan bagaimana untuk membuat sebuah Collaboration Diagram baru. Berikut urutan yang digunakan untuk membuat Collaboration Diagram baru:
1. Click kanan pada use case dalam browser
2. Dari menu shortcut, pilih New  Collaboration Diagram
3. Ketikkan  nama Collaboration Diagram yang baru
4. Click dobel  Collaboration Diagram baru dalam browser untuk membukanya.

Menghapus Collaboration Diagram
Ketika membuat model, mungkin akan ditemui beberapa collaboration diagram yang dibuat tidak akurat atau dapat digunakan. Untuk memmbersihkan model dapat dihapus beberapa collaboration Diagram dengan menggunakan browser. Berikut langkah untuk menghapus collaboration diagram:
1. Click kanan collaboration diagram dalam browser
2. Pilih Delete dari menu shortcut.

 Gambar Membuat collaboration diagram.

Menambahkan bebrapa file dan URL ke Collaboration Diagram
Dalam Rational Rose, dapat dilakukan penmabahan sebuah file atau URL ke bagian dari collaboration Diagram. Sebagai contoh, ada sebuah dokumen yang menerangkan skenario tentang interkasi  model-model diagram. Dengan menambahkan file yang berisi beberapa code yang mengimplementasikan logika dalam diagram. Atau mungkin menambahkan sebuah file kebutuhan yang berisi tentang beberapa kebutuhan tentang ciri-ciri dari diagram. Berikut langkah untuk mengaitkan file ke collaboration diagram:
1. Click kanan collaboration diagram dalam browser
2. Pilih New file
3. Gunakan dialog box Open  pilih file yang ingin dikaitkan.
4. Pilih Open untuk mengaitkan file.

Mengkaitkan URL ke collaboration diagram:
1. Click kanan collaboration diagram dalam browser
2. Pilih New  URL
3. Ketik nama URL yang ingin dikaitkan

Membuka file yang dikaitkan:
Click dobel file dalam browser. Rational Rose akan membuka aplikasi yang diperlukan dan memanggil file.
Atau
1. Click kanan pada file dalam browser  open.

Membuka URL yang terkait:
1. Click dobel pada nama URL di browser. Rational Rose akan otomatis membuka web browser dan membuka alamat URL.
Atau
1. Click kanan pada URL dalam browser Open
Rational Rose akan otomatis membuka web browser dan membuka alamat URL.

Menghapus URL yang terkait:
1. Click kanan file atau URL dalam browser
2. Pilih Delete dari menu.

Menambah Actor ke Collaboration Diagram
Obyek Actor merupakan stimulus luar yang menyatakan sistem menjalankan beberapa fungsi. Obyek Actor untuk Collaboration Diagram akan termasuk actor-actor yang berhubungan dengan use case pada Use Case diagram. Untuk membuat actor obyek pada collaboration diagram:
1. Buka collaboration diagram
2. Pilih actor dalam browser
3. Drag actor dari brower untuk membuak diagram

Menghapus Actor Obyek dari Collaboration diagram:
1. Pilih Actor pada collaboration diagram
2. Pilih Edit  Hapus dari Model atau tekan Ctrl+D

Perlu diingat, menghapus sebuah obyek dari hubungan antar diagram tidak menghapus hubungan class dari model.

Menambah obyek ke Collaboration Diagram
Jika obyek Actor telah ditambahkan ke diagram, maka tahap berikutnya adalah menambakan ke obyek lainnya. Untuk menambahkan obyek ke collaboration diagram:
1. Pilih icon obyek   pada toolbar.
2. Click dilokasi mana dalam diagram untuk meletakkan obyek. Dalam collaboration diagram, obyek dapat diletakkan dimana saja.
3. Tuliskan nama dari obyek tersebut.

Menghapus obyek dari collaboration diagram
Ketika menghapus obyek dari collaboration diagram, Rational Rose akan secara otomatis menghapus beberapa pesan (message) yang memulai atau mengakhiri dari obyek tersebut. Disamping itu, juga akan secara otomatis dilakukan penomoran ulang semua message yang tersisa. Ketika sebuah obyek dihapus dari collaboration diagram, rational rose akan menghapusnya dari sequence diagram. Langkah untuk menghapus sebagai berikut:
1. Pilih ibyek daladm sequence atau collaboration diagram.
2. Pilih  Edit  Delete dari Model atau  press Ctrl+D.

Sama dengan penghapusan Actor dari diagram, bahwa penghapusan obyek dari diagram tidak menghapus hubungan class dari model.

Menampilkan icon stereotype dalam Collaboration Diagram
Menampakkan icon stereotype dari sebuah obyek dalam collaboration diagram:
1. Tentukan stereotype dari class yang akan diatur.
2. Cick kanan pada Class dalam Class diagram yang akan dikerjakan.
3. Pilih Options Stereotype Display Icon. Secara otomatis akan diubah tampilan dari class untuk icon hubungan  dari stereotype yang dipilih. Pilih Obyek yang diinginkan dan click kanan dalam collaboration diagram
4. Dari menu shortcut, pilih Open Specification. Hasilnya dapat dilihat pada gambar dibawah:

Gambar Window Open Specification  untuk object.

5. Tentukan class dimana obyek pilih dalam window Open Specification dan click OK. Jika class yang dipilih telah diset untuk menampilkan icon stereotype, maka tampilan di collaboration diagram akan berubah seperti gambar dibawah:

Gambar Menampilkan icon stereotype dalam collaboration diagram.

Menambah Message ke Collaboration Diagram
Sebelum menambahkan message ke collaboration diagram, harus dipastikan terlebih dahulu bagian persambungan dari komunikasi antar dua obyek. Persambungan disebut Link, dan dibuat menggunakan Object Link pada toolbar. Jika link telah ditambahkan, maka message dapat dtambahkan diantara dua obyek tadi. Berikut urutan menambahkan message:
1. Pilih icon Object Link   pada toolbar.
2. Drag dari satu obyek ke obyek lain untuk membuat Link.
3. Pilih icon Link Message   atau Reverse Link Message  pada toolbar.
4. Click Link antara dua object.  Hasilnya akan ditampilkan arah message, seperti pada gambar dibawah.
5. Dengan pesan yang dipilih, ketikkan tipe teks dari message.

Gambar Penambahan  message kecollaboration diagram.

Menambahkan reflexive message ke collaboration diagram:
1. Pilih icon Link to Self   pada toolbar
2. Click obyek pengirim dan penerima pesan. Hasilnya akan digambarkan reflexive link pada obyek berupa garis setengah lingkar.
3. Pilih icon Link Message
4. Click Link Message pada obyek, maka akan ditambahkan arah message. Lihat gambar dibawah.
5. Dengan pesan baru yang masihg terpilih, maka tuliskan teks pesan.

Gambar Menambahkan reflexive message ke collaboration diagram.

Jika menambahkan lebih dari satu reflexive message dari obyek dalam  collaboration diagram, maka lewati saja langkah 1 dan 2 untuk setiap penambahan pesan.

Menghapus pesan (message) dari Collaboration Diagram
1. Pilih message yang akan dihapus.
2. Pilih Edit Delete From Model. Atau tekan  Ctrl+D.
Jika menghapus message dari collaboration diagram, maka secara otomatis akan dilakukan penomoran ulang dari pesan yang tersisa.

Penomoran pesan (message) dalam collaboration Diagram
Penomoran pesan (message) bagi collaboration diagram sangat penting untuk dilakukan, hal ini terjadi setelah tidak dilakukannya pembacaan dari atas ke bawah. Sehingga jika penomoran pesan dihapus, maka collaboration diagram kehilangan urutan informasi.

Pengaktifan dan penonaktifan penomoran pesan sesungguhnya tidak direkomendasikan secara tertulis dalam rational rose, namun dapat dilakukan dengan urutan sebagai berikut:
1. Pilih tools Options.
2. Pilih Diagram
3. Lakukan menset dalam Collaboration Numbering pada check box untuk on atau off.

Menambahkan aliran data (Data Flow) pada Collaboration Diagram
Aliran data (Data flow)digunakan untuk menunjukkan informasi yang di pakai ketika sebuah obyek mengirim pesan ke obyek yang lain. Seperti aturan pada umumnya, tidak perlu memakan waktu banyak untuk kebingungan tentang aliran data saat ini sebelum memetakan setiap pesan ke sebuah operasi dari Class. Tambahkan aliran data ke diagram jika dipertimbangkan sangat signifikan dapat menolong bagi perancang. Jika tidak membantu maka tinggalkan saja. Langkah menambahkan aliran dataa dalam collaboration diagram sebagi berikut:
1. Pilih icon Data Flow    atau icon Reverse Data Flow  .
2. Click pada message yang akan ditambah data. Hasilnya secara otomatis akan ditambah panah data flow  ke  diagram, lihat gambar dibawah.
3. Dengan data flow baru yang masih dipilih, ketikkan data yang akan dimasukkan.

Gambar Penambahan data flow ke collaboration diagram.

Seri Tutorial Rational Rose: Sequence Diagram

Bagian 1
Sequence diagram merupakan diagram Interaksi yang dinyatakan dengan waktu, atau dapat dikatakan dengan diagram dari atas (top) ke bawah (bottom). Setiap Sequence diagram menyatakan salah satu dari beberapa aliran yang melalui sebuah use case.

Membuat window sequence diagram

1. Click kanan pada use case dalam model browserNewSequence diagram.
2. Selanjutnya beri nama untuk sequence diagram tersebut.
3. Click ganda pada sequence diagram untuk memulai pembuatan sequence diagram.

Menambahkan aktor dan obyek

Selanjutnya adalah membuat sequence diagramnya, sequence diagram berisi actors dan objects:

1. Click pada Actor yang akan dibuatkan sequence diagramnya
2. Click pada tempat paling kiri dari window sequence diagram
3. Click icon object   dari toolbar
4. Click di window sequence diagram  beri nama
5. Lakukan penambahan obyek sesuai yang diinginkan

Penambahan Messages ke Sequence Diagram

Penambahan  pesan (message) ke sequence diagram:

1. Pilih icon  Object Message dari toolbar.
2. Drag dengan mouse dari object atau actor yang mengirim pesan ke object atau actor yang menerima pesan.
3. Ketik teks pesan (message).

Bagian 2

Membuat Sequence Diagram dari  Collaboration Diagram

Dengan Rational Rose, hal ini sangat mudah untuk membuat sequence diagram dari collaboration diagram, atau sebaliknya. Sekali sudah memiliki keduanya yaitu sebuah sequence dan sebuah collaboration diagram untuk sebuah rancangan, maka hal ini akan mudah untuk melakukan pertukaran antara keduanya.

Langkah membuat sequence diagram dari collaboration diagram:

1. Buka collaboration diagram.

2. Pilih Browse  Create Sequence diagram, atau tekan F5.

3. Hasilnya akan dibuatkan sequence diagram  nama yang sama seperti membuka collaboration diagram.

Perpindahan antara sequence dan collaboration diagram:

1. Buka sequence atau collaboration diagram.

2. Pilih Browse  pilih (Sequence atau Collaboration) Diagram, atau tekan F5.

3. Hasilnya akan kelihatan seperti sequence atau collaboration diagram dengan nama yang sama seperti yang sedang diagram yang dibuka.

 Gambar: Penambahan message ke sequence diagram.

Menambah reflexive message ke sequence diagram

1. pilih icon Self dari toolbar.

2. Click pada garis object yang mengikirm dan yang menerima pesan (message), lihat gambar dibawah.

3. Dengan pesan (message) baru yang masih terpilih, ketik teks pesan (message).

 Gambar. Penambahan reflexive message ke sequence diagram.

Memperbaiki Messages dalam Sequence Diagram

1. Pilih message untuk digeser.

2. Drag pesan (message) aarah naik atau turun dalam diagram. Hasilnya akan dilakukan penomoran ulang secara otomatis.

Pemetaan Pesan (Message) ke sebuah Operasi (Operation)

Sebelum membentuk code, setiap pesan (message) dalam sequence dan colaboration diagram harus dipertakan ke operasi dari kelas:

Memetakan pesan ke sebuah operasi yang sudah ada:

1. Yakinkan bahwa obyek yang menerima telah dipetakan ke sebauh class.

2. Click kanan pesan (message) dalam sequence atau collaboration diagram.

3. Sebuah daftar dari penyumbang operasi akan diperlihatkan.

4. Pilih operasi dari daftar. Lihat gambar dibawah.

Menghapus sebuah pesan dari operasi pemetaan:

1. Click dobel dari pesan dalam sequence atau collaboration diagram.

2. Dalam field Name, hapus nama operasi dan masukkan nams pesan baru.

Membuat  operasi baru dari pesan:

1. Yakinkan bahwa obyek yang menerima telah dipetakan ke sebuah Class.

2. Click kanan pesan (message) dalam sequence atau collaboration diagram.

3. Pilih <new operation>

4. Masukkan nama operasi baru dan detailnya

5. Click OK untuk menutup operasi windows specification dan tambahkan operasi baru.

6. Click kanan pada message

7. Pilih operasi baru dari daftar yang tampak.

Mencek setiap pesan telah dipetakan ke sebauh operasi:

1. Pilih Report Show Unresolved Messages

Hasilnya akan ditampilkan sebauh daftar dari semua pesan yang belum dipetakan ke operasi.

 Gambar. Pemetaan pesan ke operasi yang sudah ada..

Seri Tutorial Rational Rose: Use Case Diagram

Bagaimana membuat Use Case Diagram pada Rational Rose

Komponen utama dari sebuah Model  Use-case

Jadi, pada Rational Rose, terdapat 3 komponen utama dari Use Case, yakni: Actor, Use Case dan Relationship

Langkah-langkah:
1. Pertama-tama perhatian arahkan ke Browser

Gambar. Browser Use Case

2. Menyiapkan use case diagram window:
- Klick kanan Use case view  new  uses case diagram memberi nama dobel klick

Gambar. Memilih menu untuk window Use case diagram

3. Membuat Actor:
● Klick kanan Use case view  new  Actor  memberi nama
● Mengisi dokumentasi aktor: Pindahkan kursor di  Window Document. Ketikkan keterangan secukupnya, misalnya: “mahasiswa yang terdaftar dalam semester”.
● Menempatkan aktor ke dalam use case diagram: Drag dan Drop Icon Aktor ke dalam use case window.
● Lakukan beberapa kali sesuai jumlah Actor yang diinginkan

Gambar. Memilih menu memunculkan Actor

Gambar. Menuliskan nama aktor dan use case

4. Membuat Use case:
● Klick kanan Use case view  new  Use case  memberi nama
● Mengisi dokumentasi use case: Pindahkan kursor di  Window Document. Ketikkan keterangan secukupnya, misalnya: “Use ini dimulai dari Mahasiswa. Digunakan untuk membuat dan atau melihat  jadwal mahasiswa yang terdaftar dalam semester”.
● Menempatkan Use case ke dalam use case diagram: Drag dan Drop Icon use case ke dalam use case window.

Gambar. Daftar actor, use case, dan use case diagram dalam Browser

5. Membuat komunikasi Association (Communicates Associations)
● Click icon  Unidirectional Association    dari diagram toolbar.
● Click pada pada Actor (yang berbperan sebagai pemula  komunikasi), dan drag garis association ke use yang dituju.

6. Membuat Include Relationships
● Tambahkan satu use case dan beri nama (misal: Validasi ueser)
● Click icon  Unidirectional Association    dari diagram toolbar.
● Click pada uses case utama dan drag Unidirectional Association icon ke include use case ( misal: dari Form pendaftaran kuliah ke valiase user)
● Click dobel pada garis panah Unidirectional Association untuk menampilkan Specification.
● Click pada  Stereotype untuk membuat menu drop-down tampil dan pilih include.
● Click tombol OK untuk menutup Specification.
● Click kanan pada garis panah Unidirectional Association untuk membuat menu shortcut muncul.
● Jika dekat garis panah tidak muncul <<include>>, maka dapat dimunculkan tulisan tersebut dengan Click kanan  check Stereotype Label.

7. Membuat Extended Relationships
● Tambahkan satu use case dan beri nama (misal: Semester tidak ada)
● Click icon  Unidirectional Association    dari diagram toolbar.
● Click pada uses case utama dan drag icon Unidirectional Association  ke include use case ( misal: dari Form pendaftaran kuliah ke valiase user)
● Click dobel pada garis panah ()Unidirectional Association untuk menampilkan Specification.
● Click Stereotype untuk membuat menu drop-down tampil dan pilih exclude.
● Click tombol OK untuk menutup Specification.
● Click kanan pada garis panah Unidirectional Association untuk membuat menu shortcut muncul.
● Jika dekat garis panah tidak muncul <<exclude>>, maka dapat dimunculkan tulisan tersebut dengan : Click kanan pada garis panah Unidirectional Association Click kanan  check Stereotype Label.

Gambar. Contoh hasil akhir pembuatan Use Case Diagram.

Seri Tutorial Rational Rose

1. Pendahuluan
Rational Rose merupakan sebuah perangkat pemodelan secara visual  yang memiliki banyak kemampuan (powerful) untuk pembentukan sistem berorientasi obyek yang menggunakan Unified Modeling Language (UML). UML merupakan bahasa pemodelan yang dapat digunakan secara luas dalam pemodelan bisnis, pemodelan perangkat lunak dari semua fase pembentukan dan semua tipe sistem, dan pemodelan secara umum dari berbagai pembentukan / konstruksi yang memiliki dua perilaku yaitu baik statis maupun dinamis.
Tutorial ini akan membahas cara pemakaian Rasional Rose dengan mengambil sebuah kasus untuk mempermudah pemahaman. Namun demikian tutorial ini bersifat sangat sederhana karena pemakaian perangkat lunak ini sangat ditentukan pada system yang akan dibangun dan variasinya. Tutorial ini dapat dianalogkan dengan kursus privat mengendarai mobil. Mobil merupakan sebuah sarana transportasi yang dapat digunakan untuk berbagai keperluan, dalam kursus privat hanya diajarkan bagaimana cara mengoperasikan, perpindahan gigi, gas, rem, light sign, klakson, dsb. Kemahiran mengendarai ditentukan banyak jam pakai dengan berbagai kasus di jalan dan hal itu tidak diberikan dalam kursus privat tersebut.
Untuk mempermudah dalam memahami penggunaan rasional rose dalam tutorial ini disusun dengan urutan sebagai berikut:
1. Pendahuluan
2. Penjelasan istilah yang akan digunakan
3. Penjelasan bagian-bagian dari rasional rose
4. Penjelasan cara menggunakan
5. Studi Kasus

2. Istilah-istilah yang digunakan
Dalam UML, bagian-bagian yang digunakan yaitu: views, diagram, dan elemen model.
a. View. View menunjukkan perbedaan dari berbagai aspek-aspek suatu sistem yang dimodelkan. View bukan sebuah graph, tetapi sebuah abstraksi yang terdiri dari beberapa diagram. Hanya dengan mendefinisikan sejumlah view, dimana setiap view menunjukkan aspek yang berbeda dan saling terpisah dari sistem, maka gambaran sebuah sistem secara komplit dapat dibentuk. Rational rose memiliki empat view yaitu: Use case View, Logical View, Component View, dan Deployment View.
b. Diagram. Diagram merupakan graph yang menjelaskan tentang isi dari sebuah view. UML memiliki beberapa tipe diagram yang berbeda yang dapat digunakan untuk mengkombinasi  dalam menyusun semua dari sebuah sistem. Rational Rose 2000, memiliki delapan diagram yaitu: Use case diagram, Sequence diagram, Collaboration diagram, Activity Diagram, Class Diagram, Statechart Diagram, Component Diagram dan Deployment Diagram.
c. Elemen Model. Konsep-konsep yang digunakan dalam diagram merupakan elemen-elemen model yang menyatakan konsep-konsep berorientasi obyek secara umum , seperti class, object, dan message, serta hubungan antar konsep-konsep tersebut termasuk association, dependency, dan generelization. Sebuah elemen model digunakan dalam beberapa diagram yang berbeda tetapi selalu memiliki simbol dan arti yang sama.

3. Komponen GUI Rational Rose 2000©
Komponen utama GUI dari Rational Rose® diperlihatkan pada gambar dibawah :
1. Standard toolbar 6. Spesification
2. Browser 7. Elemen Model (icon)
3. Diagram window
4. Diagram toolbar
5. Documentation windows

Menggambar UML Class Diagram

UML Class Diagram

Class Diagram memiliki tiga area pokok :
1. Nama (dan stereotype)
2. Atribut
3. Operasi/metode

Gambar Class Diagram

Apabila atribut dan operasi digabungkan maka ini disebut function. Atribut dan operasi dapat memiliki salah satu sifat berikut :
• Private, tidak dapat dipanggil dari luar class yang bersangkutan. Notasi: “-“
• Protected, hanya dapat dipanggil oleh class yang bersangkutan dan anak-anak yang mewarisinya. Notasi: “#”
• Public, dapat dipanggil oleh siapa saja. Notasi: “+”

Class dapat merupakan implementasi dari sebuah interface, yaitu class abstrak yang hanya memiliki metoda. Interface tidak dapat langsung diinstansiasikan, tetapi harus diimplementasikan dahulu menjadi sebuah class. Dengan demikian interface mendukung resolusi metoda pada saat run-time.

Gambar berikut ini merupakan contoh class diagram dari sebuah interface “Person”

Gambar <<Interface>> Class Diagram

   

Class dapat dikelompokkan menjadi package seperti gambar di bawah ini:

Gambar Package Class Diagram

Hubungan Antar Class
1. Asosiasi, yaitu hubungan statis antar class. Sebuah association adalah hubungan antar benda struktural yang terhubung diantara obyek. Kesatuan obyek yang terhubung merupakan hubungan khusus, yang menggambarkan sebuah hubungan struktural diantara seluruh atau sebagian. Umumnya assosiation digambarkan dengan sebuah garis yang dilengkapi dengan sebuah label, nama, dan status hubungannya
2. Agregasi, yaitu hubungan yang menyatakan bagian (“terdiri atas..”).
3. Pewarisan, yaitu hubungan hirarkis antar class. Class dapat diturunkan dari class lain dan mewarisi semua atribut dan metoda class asalnya dan menambahkan fungsionalitas baru, sehingga ia disebut anak dari class yang diwarisinya. Kebalikan dari pewarisan adalah generalisasi. Sebuah generalization adalah menggambarkan hubungan khusus dalam obyek anak/child yang menggantikan obyek parent / induk . Dalam hal ini, obyek anak memberikan pengaruhnya dalam hal struktur dan tingkah lakunya kepada obyek induk.
4. Hubungan dinamis, yaitu rangkaian pesan (message) yang di-passing dari satu class kepada class lain. Hubungan dinamis dapat digambarkan dengan menggunakan sequence diagram yang akan dijelaskan kemudian.

Cara menggambarkan class diagram
1. Gunakan use case table yang sudah dibuat sebelumnya dengan memberikan highlight semua kata benda yang dapat menjadi potensial obyek.
2. Bedakan tipe-tipe obyek tersebut karena mereka dapat berupa interface, package, dan lainnya. Apabila obyek tersebut berupa nama atribut dari sebuah class, maka obyek ini harus ditolak.
3. Setelah mendapatkan daftar class, maka gambarkan high level class diagram beserta dengan kardinalitas serta deskripsi relasinya.
4. Kemudian gambarkan detailed class diagram di mana hubungan antar class sudah ditambahkan. Jangan lupa untuk menuliskan semua atribut dan operasi beserta dengan sifat mereka. Pada umumnya sifat atribut pada sebuah tabel adalah private (tidak dapat dipanggil dari luar class yang bersangkutan). Sedangkan sifat dari operasi yaitu public (dapat dipanggil oleh siapa saja).
5. Jangan lupa untuk melakukan normalisasi terhadap class jika belum dibuat sebelumnya.

Berikut ini ditunjukkan notasi dari Kelas Diagram

Gambar Notasi Class Diagram

Berikut ini contoh class diagram beserta dengan hubungan antar kelas.

Gambar Contoh Hubungan Antar Kelas

Berikut ini adalah contoh menggambar Diagram Kelas melalui Video Youtube:
http://www.youtube.com/watch?v=w2m-7YcHVck

Video Pengantar ini juga dapat dilihat sebagai awal untuk memahami UML Class Diagram:
http://www.youtube.com/watch?v=5d2blHVH3h8

Model Sistem Aplikasi Web-based Dormitory Management (II)

Tulisan ini adalah lanjutan dari bagian pertama disini:
http://stanlysk.blogspot.com/2012/10/analisa-perancangan-aplikasi-web-based.html
kemudian dilanjutkan dengan bagian kedua disini:
http://stanlysk.blogspot.com/2012/10/model-sistem-aplikasi-web-based.html

Pada bagian kedua, sistem aplikasi dimodelkan menurut model scenario-based, sedangkan pada bagian ketiga ini, sistem aplikasi akan dimodelkan menurut model kelas dan model perilaku. Berikut adalah gambar model sistem aplikasi.

3. Model Kelas

Menggambar model kelas, mengikuti teknik CRC Card dan UML Class Diagram, sebagai berikut:

4. Model Perilaku (atau behaviour model)

Untuk model perilaku dari sistem aplikasi, akan menggunakan UML Sequence Diagram dan UML State Diagram. Pada penulisan ini, dicontohkan diagram sequence untuk Use Case Room Booking, dan Occupant.

Sedangkan UML State Diagram yang ditampilkan adalah State Booking Management dan Asset Management. Berikut adalah tampilannya ...

Model Sistem Aplikasi Web-based Dormitory Management

Tulisan ini merupakan lanjutan dari tulisan saya sebelumnya, yang bisa dibaca selengkapnya pada URL dibawah ini:
http://stanlysk.blogspot.com/2012/10/analisa-perancangan-aplikasi-web-based.html

Setelah melakukan proses pendefinisian kebutuhan secara lengkap, maka Tim Pengembang selanjutnya dapat melakukan analisis model sistem perangkat lunak yang akan dikembangkan. Berikut ini adalah contoh tahapan dari langkah tersebut:


2. FUNCTIONAL MODELING
2.1 Activity Diagram
Kegiatan-kegiatan yang terjadi baik dalam proses As-is System maupun To-Be Sytem untuk Sistem Pengelolaan Rumah Kos Berbasis Web ini dapat diberikan dalam beberapa Activity Diagram dibawah ini:

• As-Is System (Viewing + Booking + Payment)

Gambar As-Is System (Viewing + Booking + Payment)

• As-Is System (Report)
Laporan pembayaran uang sewa kamar oleh Penghuni Rumah Kos

Laporan pemeliharaan aset rumah kos oleh Manager Rumah Kos

 Gambar As-Is System (Report)

• To Be System (Viewing + Booking + Payment)

Gambar To Be System (Viewing + Booking + Payment)

• To Be System (Report)

Gambar To Be System (Report)

Setelah dipaparkan mengenai To Be System, maka langkah selanjutnya adalah menggambar model fungsional sistem aplikasi yang akan dibangun. Untuk keperluan ini, digunakan UML Use Case Diagram.

Use Case Diagram

Use Case Diagram yang pertama,a dalah Use Case Diagram Room Booking

Use Case Diagram yang kedua adalah Use Case DOrmitory Management.

Kemudian diikuti dengan Use Case Description dari salah satu use case yang ada diatas ...

Demikianlah Model Fungsional sistem aplikasi yang akan dikembangkan. Model gambar diatas mengikuti teori model scenario-based, dengan menggunakan Diagram Aktivitas dan Diagram Use Case untuk memodelkan sistem aplikasi perangkat lunak.

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.