Contoh Analisis Materi Rekayasa Perangkat Lunak Lanjut

1.     Tahapan-tahapan analisis permasalahan pada kasus hotel Narita :

·         Mempelajari dan memahami persoalan

Pada tahap ini, kita mempelajari masalah yang ada pada kasus hotel Narita, sehingga dapat ditentukan :

a)      Siapa pemakai yang menggunakan sistem. Dalam kasus hotel Narita, pemakai yang menggunakan adalah staff admin.

b)      Dimana sistem akan digunakan .  Dalam kasus ini,  sistem digunakan untuk hotel Narita.

c)      Pekerjaan apa saja dari pemakai yang akan dibantu oleh sistem.  Untuk kasus hotel Narita, pekerjaan sistem sebagai berikut :

-          Memberikan informasi ketersediaan kamar secara online

-          Menjamin keamanan pelanggan dalam melakukan transaksi secara online

-          Ketika membooking secara online, pelanggan minimal memberikan booking fee atau membayar secara lunas. Proses pembayaran dapat dilakukan secara online baik melalui kartu credit maupun paypal

-          Sistem memberikan time limit terhadap pembayaran booking dan jika pembayaran melebihi time limit maka proses booking akan dibatalkan

-          Pihak hotel mampu melakukan pengelolaan terhadap kamar-kamar dan meeting room secara online.

-          Pihak hotel mampu mengetahui pelanggan yang memesan dan juga mengetahui pembayaran pelanggan.

-          Sistem memiliki kemampuan untuk memberikan informasi mengenai ketersediaan kamar dan meeting room apakah sudah penuh atau tidak

d)     Apa saja cakupan dari pekerjaan tersebut, dan bagaimana mekanisme pelaksanaannya.

e)      Apa yang menjadi kendala dilihat dari sisi teknologi yang digunakan atau dari sisi hukum dan standar.

Cara yang digunakan oleh kita dalam memahami masalah sistem biasanya dilakukan:

a)      Wawancara dengan pemilik hotel

b)      Observasi atau pengamatan lapangan

c)      Kuesioner

d)     Mempelajari referensi atau dokumen-dokumen yang digunakan, seperti dokumen hasil analisa dan perancangan sistem hotel tersebut.

Hasil dari pemahaman masalah tersebut dapat digambarkan dengan model-model tertentu sesuai dengan jenis permasalahannya.

·         Mengidentifikasi kebutuhan pemakai

Pada tahap identifikasi kebutuhan pemakai (user requirement) ini pada prakteknya menjadi satu pelaksanaannya dengan pemahaman masalah. Hanya saja substansi yang ditanyakan ada sedikit perbedaan, yaitu :

a)      Fungsi apa yang diinginkan pada sistem pemesanan kamar hotel dan meeting room.

b)      Data atau informasi apa saja yang akan diproses.

c)      Kelakuan sistem apa yang diharapkan.

d)     Antarmuka apa yang tersedia (software interfaces, hardware interfaces, user interfaces, dan communication interfaces)

Untuk menangkap kebutuhan dari pemakai dengan baik,terutama kesamaan persepsi. kita membutuhkan :

a)      Komunikasi dan brainstorming yang intensif dengan pemilik hotel.

b)      Pembuatan prototype sistem atau screenshoot.

c)      Data atau dokumen yang lengkap.

·         Mendefinisikan kebutuhan sistem

Saat melakukan pengidentifikasian kebutuhan pemakai, informasi yang diperoleh masih belum terstruktur. Biasanya pemakai akan mengungkapkan apa yang diinginkan dengan bahasa sehari-hari yang biasa mereka gunakan.

Kemudian pada tahap ini, kebutuhan pemakai yang belum terstruktur tersebut akan akan dianalisis, diklasifikasikan, dan diterjemahkan menjadi kebutuhan fungsional, antarmuka dan unjuk kerja sistem. Sebagai contoh, kebutuhan “data yang dimasukkan oleh bagian staff admin bisa langsung dijurnal” setelah dianalisis, diklasifikasikan dan diterjemahkan, mungkin akan menghasilkan pendefinisian kebutuhan sebagai berikut :

a)      Kebutuhan fungsional

o   Entri dan rekam data transaksi pembayaran atau booking.

o   Retrieve data transaksi pembayaran untuk periode tertentu (periode sesuai dengan inputan periode yang diinputkan pada keyboard).

o   Rekam data akumulasi transaksi pembayaran periode tertentu ke jurnal umum berikut account pasangannya (kas).

b)      Kebutuhan antarmuka

o   Antarmuka pemakai untuk mengetahui ketersediaan kamar yang dapat dipesan kamar secara online.

o   Antarmuka pemakai untuk menyajikan dan menjurnal informasi transaksi pembayaran pada periode tertentu.

o   Antarmuka pemakai untuk menginformasikan time limit terhadap pembayaran booking.

c)      Kebutuhan unjuk kerja

o   proses jurnal hanya bisa dilakukan sekali setelah data transaksi pembayaran atau booking direkam.

o   Adanya otoritas pemakaian sistem dan akses data sesuai dengan bagian pekerjaan masing-masing.

Kemudian kebutuhan tersebut akan dimodelkan atau digambarkan dengan teknik analisis dan alat bantu tertentu. Sebagai contoh kebutuhan fungsional dapat dimodelkan dengan menggunakan

-          Data flow diagram,kamus data,dan spesifikasi proses jika menggunakan anlisis tertsruktur

-          Use case diagram dan skenario sistem jika menggunkan analisis berorientasi objek.

·         Membuat dokumen spesifikasi kebutuhan sistem (SKPL)

Semua kebutuhan yang telah didefinisikan selanjutnya dibuat dokumentasinya yaitu Spesifikasi Kebutuhan Sistem (SKPL) atau Software Requirement Specification (SRS). Dokumen ini dibuat untuk menyatakan secara lengkap apa yang dapat dilakukan oleh perangkat lunal, termasuk deskripsi lengkap semua antarmuka yang akan digunakan.

·         Mengkaji ulang (review) kebutuhan

Proses untuk mengkaji ulang (validasi) kebutuhan apakah SKPL sudah konsisten, lengkap, dan sesuai dengan yang diinginkan oleh pemakai. Proses ini bisa dilakukan lebih dari satu kali. Dan sering kali akan muncul kebuthan-kebutuhan baru dari pemakai. Oleh karena itu, diperlukannya negosiasi antara pengembang dengan pelanggan sesuai dengan prinsip “win win solution” sampai kebutuhan tersebut disetujui oleh kedua belah pihak.

v  Sedangkan menurut Pressman [PRE01], analisis kebutuhan sistem dapat dibagi menjadi lima area pekerjaan, yaitu:

a)      Pengenalan masalah

b)      Evaluasi dan sistesis

c)      Pemodelan

d)     Spesifikasi

e)      Tinjau ulang (review)

Pustaka :

ü  Roger Pressman, “Software Engineering A Practitioner‟s Approach”, 5th Edition, Mc GrawHill

ü  Rekayasa Sistem.pdf Telkom politeknik Bandung

2.     Aktor yang sesuai dengan kasus hotel Narita ada 2, yaitu :

·         Pelanggan : orang yang memesan, membayar atau membooking kamar atau meeting room. Pelanggan dapat melakukan transaksi secara online.

·         Staff admin : orang yang melayani pelanggan. Melakukan pengelolaan terhadap kamar-kamar dan meeting room secara online.

3.      Kebutuhan sistem pada kasus hotel Narita :

Secara kategoris, ada tiga buah jenis kebutuhan sistem [IEE93] :

1)      Kebutuhan fungsional (functional requirement)

Disebut juga kebutuhan operasional, yaitu kebutuhan yang berkaitan dengan fungsi atau proses transformasi yang harus mampu dikerjakan oleh sistem.

a)      Sistem harus dapat menyimpan semua rincian data pesanan pelanggan.

b)      Sistem harus dapat membuat laporan pembayaran sesuai dengan periode waktu tertentu.

c)      Sistem menjamin keamanan pelanggan dalam melakukan transaksi secara online.

d)     Sistem memberikan time limit terhadap pembayaran booking dan jika pembayaran melebihi time limit maka proses booking akan dibatalkan

e)      Sistem memiliki kemampuan untuk memberikan informasi mengenai ketersediaan kamar dan meeting room apakah sudah penuh atau tidak

2)      Kebutuhan antarmuka (interface requirement)

Kebutuhan antarmuka yang menghubungkan sistem dengan elemen perangkat keras, sistem, atau basis data.

a)      Perangkat untuk memasukkan data dapat berupa keyboard, mouse atau scanner.

b)      Akses ke basisdata menggunakan ODBC (Open Database Connectivity).

3)      Kebutuhan unjuk kerja (performance requirement)

Kebutuhan yang menetapkan karakteristik unjuk kerja yang harus dimiliki oleh sistem, misalnya: kecepatan, ketepatan, frekuensi.

a)      Sistem harus bisa mengolah data sampai 1 juta record untuk tiap transaksi.

b)      Sistem harus dapat digunakan oleh multiuser sesuai dengan otoritas yang diberikan pada user.

c)      Waktu tanggap penyajian informasi maksimal selama satu menit.

4.     Use Case

·         Use Case Description:

Use Case Name : memesan kamar/meeting room

Primary Actor : pelanggan, staff admin

Stakeholders and interest : Pelanggan – melakukan pemesanan kamar/meeting room secara online Staff admin – merekam dan mencatat setiap kamar/meeting room yang sudah dipesan

Brief Description : use case ini menggambarkan bagaimana pelanggan melakukan pemesanan dan staff admin mencatat setiap kamar yang sudah dipesan

Relationships : Association : pelanggan, staff admin Include : Extend : melihat ketersediaan kamar Generalization :

Use Case Name : melihat ketersediaan kamar

Primary Actor : pelanggan, staff admin

Stakeholders and interest : Pelanggan – melihat ketersediaan kamar/meeting room secara online Staff admin – memeberikan informasi mengenai kamar, apakar masih ada atau sudah penuh

Brief Description : use case ini menggambarkan bagaimana pelanggan meliaht ketersediaan kamar dan staff admin memberikan informasi mengenai ketersediaan kamar

Relationships : Association : pelanggan, staff admin Include : Extend : Generalization :

Use Case Name : mengelola kamar/meeting room

Primary Actor : staff admin

Stakeholders and interest : Pelanggan – memerlukan kamar yang available Staff admin – mengelola kamar-kamar yang sudah dipesan untuk kemuidan diinformasikan kepada pelanggan yang ingin memesan kamar

Brief Description : use case ini menggambarkan bagaimana staff admin melakukan pengelolaan kamar-kamar yang sudah dipesan dan yang masih kosong

Relationships : Association : staff admin Include : Extend : Generalization :

Use Case Name : melakukan transaksi

Primary Actor : pelanggan, staff admin

Stakeholders and interest : Pelanggan – melakukan transaksi setelah menentukan kamar pilihan Staff admin – melayani transaksi denga pembayaran cash atau credit

Brief Description : use case ini menggambarkan bagaimana pelanggan melakukan pembayaran dan staff admin melayani dan memberikan opsi pembayaran

Relationships : Association : pelanggan, staff admin Include : Extend : pemberian booking fee, pemberian time limit, pembayaran lunas Generalization :

Use Case Name : pemberian booking fee

Primary Actor : pelanggan, staff admin

Stakeholders and interest : Pelanggan – melakukan pembayaran booking fee untuk kamar/meeting room  yang dipesan secara online Staff admin – melayani proses booking fee dan mencatat setiap kamar/meeting room yang sudah dipesan

Brief Description : use case ini menggambarkan bagaimana pelanggan melakukan pembayaran booking fee dan staff admin melayani dan mencatat setiap kamar yang sudah dipesan

Relationships : Association : pelanggan, staff admin Include : Extend : Generalization :

Use Case Name : pemberian tine limit

Primary Actor : pelanggan, staff admin

Stakeholders and interest : Pelanggan – diberikan batas waktu pelunasan booking fee Staff admin – membatalkan proses booking bila pelanggan belum melunasi setelah melebihi batas waktu

Brief Description : use case ini menggambarkan bagaimana pelanggan dibatasi waktunya untuk melunasi booking fee yang sudah dibayarkan dan staff admin akan membatalkan proses booking fee jika pelanggan tidak segera melunasi hingga batas waktu habis

Relationships : Association : pelanggan, staff admin Include : Extend : Generalization :

Use Case Name : pembayaran lunas

Primary Actor : pelanggan, staff admin

Stakeholders and interest : Pelanggan – melakukan pembayaran lunas untuk kamar/meeting room  yang dipesan secara online Staff admin – melayani proses pembayaran lunas dan mencatat setiap kamar/meeting room yang sudah dipesan

Brief Description : use case ini menggambarkan bagaimana pelanggan melakukan pembayaran secara cash dan staff admin melayani dan mencatat setiap kamar yang sudah dipesan

Relationships : Association : pelanggan, staff admin Include : Extend : Generalization :

·         Use Case Diagram :