Pemodelan Analisis (Part 1)

Analisis Sistem
 Tahap analisis merupakan tahap yang paling
kritis dan sangat penting
 Kesalahan di tahapan ini akan menyebabkan
kesalahan di tahap selanjutnya
 Hasil dari analisis sistem adalah:
laporan yang dapat menggambarkan sistem
yang telah dipelajari dan diketahui bentuk
permasalahannya serta rancangan sistem baru
yang akan dibuat atau dikembangakan.
Definisi Pemodelan Analisis
• Proses menemukan permasalahan dan
menghasilkan alternatif pemecahan yang
relevan.
• Tujuan tahap analisis adalah untuk
mengetahui kebutuhan customer berkaitan
dengan sistem perangkat lunak yang
diinginkan.
 ILUSTRASI : Bangun
Rumah

Analisis
Sasaran Utama Analisis
1. Menggambarkan apa yang dibutuhkan
untuk pelanggan
2. Membangun dasar bagi perancangan
perangkat lunak
3. Membatasi serangkaian persyaratan yang
dapat divalidasi begitu perangkat lunak
dibangun
Keterlibatan
Pada tahap ini yang terlibat adalah tim
spesifikasi/analisis dan customer (meliputi
end-user, manager dan staf lain yang
terlibat)
Ruang Lingkup Analisis
• Mengindentifikasi customer
• Mendefinisikan dan menspesifikasikan
kebutuhan
• Membangun model analisis
• Mendefinisikan spesifikasi secara rinci
untuk dijadikan panduan dalam melakukan
perancangan
Ruang Lingkup Analisis
• Mendokumentasikan hasil analisis kedalam
dokumen SRS (Software Requirement
Specification)
• Melakukan pengkajian ulang secara formal
Langkah-langkah Analisis

Mengidentifikasi masalah
Mengidentifikasi penyebab masalah

Analisis sistem
Mengidentifikasi solusi dari masalah

Analisis Kebutuhan
Mengidentifikasi data apa dan proses Menentukan kebutuhan fungsional dan
apa yang dibutuhkan pada sistem baru. non-fungsional dari sistem baru.
 Kebutuhan Fungsional
Menunjukkan apa yang bisa dilakukan sistem.
Menunjukkan fasilitas apa yang dibutuhkan serta
aktivitas apa saja yang terjadi dalam sistem baru.
Kebutuhan fungsional mencakup:
◦ Fungsi deskripsi kebutuhan
◦ Laporan baik hardcopy maupun softcopy
◦ Updating dan query online
◦ Penyimpanan data, pencarian kembali dan transfer
data
Kebutuhan Non Fungsional
Kebutuhan Non Fungsional mencakup:
◦ Waktu respon
◦ Rata-rata waktu untuk kegagalan
◦ Kebutuhan keamanan
◦ Akses untuk pengguna yang tidak punya hak.
Caranya?

 Mempelajari Dokumentasi Sistem yang

Berjalan
 Wawancara
 Quesioner
 Observasi
 Hambatan
 Deskripsi yang tidak Jelas dan berubah-ubah/
tidak pasti
 Ketidaklengkapan spesifikasi kebutuhan
 Fitur yang tidak dibutuhkan
 Contoh Kasus
(Sistem Informasi Rawat Jalan Poliklinik ABC)
◦ Identifikasi Masalah
◦ Permasalahan yang terjadi di Poliklinik ABC adalah sebagai berikut:
1. Data-data yang disimpan di poliklinik masih berjalan manual
sehingga sering terjadi ksalahan dalam pencatatan dan lama
dalam pencarian data, padahal Kebutuhan akan data-data
pasien rawat jalan, rekam medis pasien serta dokter yang
menangani tiap pasien meningkat
2. Sistem yang dijalankan belum sepenuhnya membantu
pekerjaan, karena kebutuhan akan data yang efektif dan
efisien serta ada saat dibutuhkan (availability) belum bisa
terpenuhi
3. Penyediaan data yang banyak menyebabkan overload data dan
informasi kurang
Analisis Sistem
 Penyimpanan data dalam bentuk kertas atau
manual menimbulkan resiko yang cukup besar,
seperti kebakaran, rusak atau bencana alam yang
bisa mengakibatkan data-data penting itu hilang,
sehingga diperlukan sistem yang bisa menyimpan
data lebih aman
 Kebutuhan akan data yang efektif dan efisien serta
ada saat dibutuhkan (availability) menjadi alasan
utama untuk penyediaan informasi yang akurat
Analisis Sistem
 Data yang kurang lengkap menyebabkan informasi
pelayanan kesehatan juga kurang, karena data
tidak tersusun rapi dan susahnya pencarian data
yang mengurangi kurangnya informasi dari data
tersebut
Dari berbagai alasan yang telah diungkapkan di
atas, maka pengembangan Sistem Informasi Rawat
Jalan Poliklinik ABC ini dibuat untuk membantu
menyelesaikan permasalahan-permasalahan yang
muncul.
Analisis Kebutuhan
Data yang dibutuhkan
Data yang dibutuhkan dalam pengembangan
Sistem Informasi ini adalah :
◦ Data Pasien : nama pasien, alamat, jenis kelamin,
tanggal lahir, agama, golongan darah.
◦ Data Dokter : nama dokter, alamat, jenis kelamin,
tanggal lahir.
◦ Data Obat : nama obat, jenis obat, aturan pakai,
harga
Analisis Kebutuhan
◦ Data Admin/Petugas : nama petugas, alamat,
jenis kelamin, tanggal lahir.
◦ Data Pemeriksaan : data pasien, data dokter,
keluhan, diagnosa, perlakuan/pemeriksaan, data
obat
◦ Data Biaya : data pasien, pemeriksaan, total
harga obat
Kebutuhan Fungsional
Fungsi dari sistem ini adalah :
o Proses pengelolaan data pasien, meliputi input,
update dan delete
o Proses pengelolaan data dokter, meliputi input,
update dan delete
o Proses pengelolaan data petugas, meliputi input,
update dan delete
o Proses pendaftaran pasien, baik daftar baru
maupun pendaftaran untuk periksa dilakukan oleh
user petugas
Kebutuhan Fungsional
o Proses searching/pencarian data (data pasien,
data dokter, data petugas, data pemeriksaan,
data obat)
o Proses pemeriksaan, dilakukan oleh user dokter
o Proses pemberian obat, dilakukan oleh petugas
untuk diberikan kepada pasien
 Pendekatan Analisis Sistem
metode perkembangan
Pe n d e kata n sistem dengan menyediakan
sistem tambahan yang
Te rstru kt u r berupa alat–alat dan teknik–
teknik
suatu teknik pendekatan baru
Pe n d ekata n dalam melihat permasalahan
An a li s is dan sistem (system perangkat
S i ste m lunak, sistem informasi, atau
system lainnya). Pendekatan ini
Pe n d e kata n memandang sistem yang akan
B e ro rie nta s i dikembangkan sebagai suatu
o b je k kumpulan objek-objek dunia
nyata.
 Perbedaan SSAD & OOAD
Pendekatan Terstruktur
Dikenal dengan (Structured
Analisys and Design / SSAD)
Pendekatan Fungsional
Dekomposisi permasalahan
dilakukan berdasarkan fungsi atau
proses secara hirarki, mulai dan
konteks sampai proses-proses
yang paling kecil
SSAD lebih sulit digunakan dalam
pembangunan sistem.
Pada SSAD tidak fokus pada coding Pada OOAD lebih fokus pada
Pada SSAD menekankan pada
kinerja team
Pendekatan Objek
Dikenal dengan (Object-oriented
Analysis and Design / OOAD)
Pendekatan Objek
Dekomposisi permasalahan
dilakukan berdasarkan objek-objek
yang ada dalam sistem
OOAD lebih mudah digunakan
dalam pembangunan sistem.
coding
Pada OOAD tidak menekankan
pada kinerja team
SRS
Secara sederhana, Software Requirement
Specifications (SRS) adalah dokumen yang
menjelaskan tentang berbagai kebutuhan
yang harus dipenuhi oleh suatu software.
Dokumen ini dibuat oleh developer
(pembuat software) setelah menggali
informasi dari calon pemakai software.
Manfaat S R S
• Sebagai bentuk perjanjian antara customer
dan supplier tentang software apa yang
akan dibuat
• Mengurangi beban dalam proses
pengembangan software
• Sebagai bahan perkiraan biaya dan rencana
penjadwalan
Manfaat S R S
• Sebagai dasar validasi dan verifikasi
software di ujung penyelesaian proyek
nantinya
• Mendasari perbaikan produk software di
kemudian hari. Jadi, kadang SRS boleh
diperbaiki dengan alasan dan mekanisme
tertentu serta atas kesepakatan antara
customer dan developer.
Manfaat S R S
• Memfasilitasi transfer, semisal software
tersebut ingin ditransfer ke pengguna atau
mesin-mesin yang lain. Customer pun
merasa mudah jika ingin mentransfer
software ke bagian-bagian lain dalam
organisasinya. Bahkan, jika terjadi
pergantian personil developer, proyek
dapat mudah ditransfer ke personil baru
dengan memahami SRS ini.
S R S yang Baik
• Correct (benar)
• Unambiguous (tidak ambigu, tapi jelas)
• Complete (lengkap)
• Consistent (konsisten)
• Verifiable (dapat diverifikasi)
• Modifiable (bisa dimodifikasi)
• Traceable (bisa dilacak)