Transcript Pertemuan8_FASE PENGEMBANGAN – 1

FASE PENGEMBANGAN - 1
Pe r te m u a n 8
P roye k S i s te m I n f o r m a s i
V i s k a A r m a l i n a , ST. , M . E n g
Pendahuluan
 Inti dari fase pengembangan :
“membuat produk yang bisa memenuhi apa yang
dikehendaki klien, yang telah disusun dan diorganisir
pada fase sebelumnya.”
 Metode untuk pelaksanaan proyek sistem informasi
yang
sering digunakan adalah metode SDLC
(Software Development Life Cycle) dengan model
pengembangan “The Waterfall Model”.
Tahapan The Waterfall Model
1.
2.
3.
4.
5.
Requirements
Desain Sistem dan Software
Pembangunan Software
Quality Assurance (QA)
Dokumentasi
1. Requirements
 Yang sudah harus ada dalam tahap requirements ini
adalah:
- System Requirements Spesification (dokumen SRS)
- Project Scope Document (PSD)
 Pada fase pengembangan, requirements sudah tidak
ada perubahan yang signifikan (perubahan kecil masih
dapat diterima).
2. Desain Sistem dan Software
 Konsepnya :
Menyusun deskripsi struktur komponen software yang
akan digunakan dalam pengembangan software
tersebut.
 Pada
fase pengembangan, sistem dan software
berkaitan erat karena software menjadi bagian utama
dari suatu sistem informasi.
Tahapan Pada Proses Desain Sistem dan Software
a.
b.
c.
d.
e.
f.
g.
Spesifikasi Fungsional dan Teknis
Resiko dan Mitigasi
Desain Sistem
Pemodelan (Modelling)
Desain Software
Desain Antarmuka Pengguna
Desain Database
a. Spesifikasi Fungsional dan Teknis (1)
 Spesifikasi fungsional dapat dideskripsikan melalui
Functional Spesification Document (FSD) :
- menggambarkan bagaimana nantinya software akan
berfungsi.
- fungsi-fungsi apa yang harus dimiliki oleh software
tersebut agar dapat memenuhi requirements  cara
kerja/interaksi software dengan pengguna.
 FSD harus jelas dan akurat dalam menggambarkan halhal teknis yang diperlukan oleh sistem dan software
yang akan dibangun.
a. Spesifikasi Fungsional dan Teknis (2)
 Contoh deskripsi dalam FSD tentang pengisian faktur
penjualan :
“Isi data pelanggan dengan memilih dari daftar Master
Pelanggan, setelah itu isi data barang dengan memilih
dari daftar Master Barang. Setelah selesai pengisian,
klik tombol Simpan untuk menyimpan data yang telah
diisi.”
a. Spesifikasi Fungsional dan Teknis (3)
 Spesifikasi
teknis dituangkan dalam Software
Technical Spesification (STS).
 STS dapat dilengkapi dengan skema dan diagram
agar lebih memperjelas deksripsi yang diberikan.
 FSD dan STS ditujukan untuk penggunaan internal
tim pengembang software, sehingga format
penyusunannya tidak terlalu formal, yang penting
jelas
dalam
mendeksripsikan
kebutuhan
pelaksanaan proyek dan sebagai dokumentasi.
Perbedaan FSD dengan STS
1. STS lebih mendeskripsikan aspek teknis dari software
yang akan didesain, seperti :
- platform yang digunakan
- bahasa pemrograman
- database
- struktur data
- koneksi software dengan database, dsb.
2. FSD ditujukan untuk desainer sofware, sedangkan
STS ditujukan
pemrogram.
untuk
desainer
sistem
dan
b. Resiko dan Mitigasi (1)
 Potensi resiko ada di setiap fase  perlu identifikasi
resiko.
- misalnya: Sama halnya dengan requirements analysis, pada
proses desain sistem dan software, jika tidak dilakukan dengan
tepat memungkinkan kegagalan proyek semakin tinggi 
kegagalan deliverables.
 Rencana Mitigasi harus dipersiapkan dari awal agar jika
terjadi masalah saat proses desain telah diselesaikan dan
siap ke tahap pengembangan, kegagalan deliverables
bisa dicegah, sehingga menghindari kegagalan proyek
(tertunda).
b. Resiko dan Mitigasi (2)
 Rencana Mitigasi lebih praktis jika dimasukkan ke
fase pengembangan dan menjadi bagian dari tahap
desain, dengan tujuan agar jika pada fase ini terjadi
masalah, mitigasi yang sejalan dengan desain dapat
memperkecil kemungkinan penundaan proyek.
 Mitigasi
dalam
desain
ditujukan
untuk
mempersiapkan solusi dan alterbatif agar kendalakendala dalam tahap pengembangan dapat dihindari.
Penyebab Terjadinya Kendala/Masalah dalam
Proses Desain
a.
b.
c.
d.
e.
f.
Desain terlalu kompleks
Membutuhkan teknologi yang sulit diperoleh/diluar
anggaran
Fungsi yang dibutuhkan tidak didukung oleh bahasa
pemrograman yang digunakan
Pertentangan antara satu fungsi dengan fungsi lain
sehingga menyebabkan konflik sistem
Desainnya ambigu sehingga sistem tidak stabil
Desain tampilan tidak ergonomis/user friendly
sehingga menyulitkan pengguna.
c. Desain Sistem (1)
 Desain
sistem adalah proses mendefinisikan
arsitektur, komponen, modul, antarmuka, dan data
untuk memenuhi requirements.
 Desain sistem dalam manajemen proyek  dasar bagi
konstruksi sistem yang akan dibangun.
 System Flow : aliran informasi dari awal hingga akhir
yang merepresentasikan requirements.
c. Desain Sistem (2)
 Ada 2 jenis desain sistem :
- Desain Logikal
- Desain Fisikal
Desain Logikal
 Desain secara logikal : melakukan representasi abstrak
sistem dengan diagram, gambar, dan bagan, sehingga
aliran data, input dan output sistem dapat dipahami
oleh pemrogram.
 Representasi sistem harus memenuhi 3 pertimbangan:
- Fungsi : apa yg dilakukan oleh sistem
- Waktu : apa yg terjadi dan kapan
- Informasi : informasi apa yang digunakan sistem
Desain Fisikal
 Desain
fisikal : desain yang berkaitan dengan
bagaimana proses input dan output sebenarnya dalam
sistem.
 Pertimbangan dalam desain fisikal :
- bagaimana data diinput dalam sistem
- bagaimana melakukan verifikasi dan otentifikasi data
- bagaimana data diproses
- seperti apa penyajian output yg dihasilkan.
 Penggambaran desain fisikal : desain dasar form
input, urutan verifikasi data, bagan proses, laporan
hasil.
Metode Desain Sistem (1)
a. Yourdon System Method (YSM)
- Metode generasi ketiga
- Dirintis oleh Edward Yourdon, tahun 1970 sampai
1900-an.
- Menggunakan context diagram yang menggambarkan
hasil analisis dalam bentuk sumber data, aliran dan
batasan sistem.
- Desain sistem lebih diperinci dengan teknik-teknik
tradisional  ERD (Entity Relationship Diagram),
normalisasi, DFD (Data Flow Diagram), dsb.
Metode Desain Sistem (2)
b. Metode Analisis dan Desain Sistem Berorientasi Obyek
(Object Oriented System Analysis and Design
Method)
- Alat bantu yang digunakan pada metode ini adalah
Unified Modelling Language (UML).
d. Pemodelan (Modelling) - 1
 Model  representasi abstrak dari sistem yang akan
dibangun.
 Tidak semua sistem memerlukan pemodelan.
 Kriteria sistem sederhana yang tidak perlu memakai
pemodelan :
a.
b.
c.
d.
e.
Lingkup sistem telah dikenal baik
Sistem relatif mudah untuk dibangun
Hanya sedikit/hanya 1 orang yang membangun/menggunakan
sistem.
Sistem hanya butuh perawatan yang minimal.
Kemungkinan pengembangan sistem lebih lanjut sangat kecil.
d. Pemodelan (Modelling) - 2
 Pemodelan diterapkan pada :
- sistem yang lebih kompleks
- memiliki resiko lebih besar
- tidak tersedianya sistem sejenis untuk digunakan
langsung secara praktis. (sistem baru/belum ada
sebelumnya).
Alat Bantu Pemodelan
 Integrated Development Environment (IDE)
Software pengembangan menyediakan lingkungan yang
membantu pemodelan sebelum dilakukan proses
pemrograman.
 Unified Modelling Language (UML)
- standar dalam pemodelan
- bahasa spesifikasi standar untuk medokumentasikan,
menspesifikasikan dan membangun sistem software.
- hasil pengembangan dari bahasa pemodelan berorientasi
objek (Object Oriented Modelling Language).
Mengapa Sistem Informasi Perlu Pemodelan? (1)
 Awal perkembangan SI :
- sederhana, sistem dibangun untuk memecahkan satu
masalah saja
- bentuk awal pemodelan sudah ada (sistem analis
merangkap jadi desainer sistem yang membuat
flowchart berupa gambaran logika sistem untuk
memudahkan programmer memahami apa yang harus
dibangunnya),
- belum banyak alat bantu pemodelan
Mengapa Sistem Informasi Perlu
Pemodelan? (2)
 Perkembangan SI selanjutnya sampai sekarang
- Sistem Informasi menjadi lebih kompleks dan
terintegrasi.
- Interaksi dalam Sistem Informasi tidak hanya dalam
satu organisasi/perusahaan, tapi juga tersebar secara
geografis.
- Pemodelan mutlak diperlukan untuk sistem yang
semakin kompleks agar programmer lebih mudah
memahami apa yang akan dibangunnya.
Manfaat Pemodelan bagi Programmer
 Dapat memahami sistem yang




membutuhkan contoh
perwujudannya lebih dulu yaitu dengan mendefinisikan
proses-prosesnya dalam bentuk model.
Memahami bagaimana suatu proses bekerja + asumsiasumsi yang menjadi dasar proses kerja tersebut.
Memudahkan dalam mendefinisikan sumber input sistem,
baik dari luar maupun dari dalam sistem.
Menentukan representasi dari keterhubungan antara
komponen-komponen sistem  memudahkan memahami
sistem secara keseluruhan.
Menelusuri kembali requirements untuk memastikan
sistem yang dibangun telah sesuai.
Faktor Penghambat dalam Membentuk Model
Sistem (1)
Asumsi  digunakan utk mengurangi dugaan dan
berbagai kemungkinan tentang hal-hal yg belum
diketahui.
2. Simplifikasi  agar tidak terjebak ketika menyusun
model yg terlalu kompleks sehingga memakan
banyak waktu.
3. Batasan  melingkupi sistem agar model menjadi
terfokus dan tidak melebar.
1.
Faktor Penghambat dalam Membentuk Model
Sistem (2)
Hambatan  membantu menentukan kebutuhan
sumberdaya dan dukungan untuk mewujudkan
sistem.
5. Pilihan  menentukan arsitektur yang akan
digunakan seperti data, fungsi, teknologi.
4.
e. Desain Software
 Bentuk detail dari desain sistem  sistem yang telah
dibuat modelnya kemudian diperinci dalam bentuk
yang lebih mudah dipahami programmer.
 Aktivitas yang dilakukan adalah menyusun bentuk
representasi software yg akan digunakan (arsitektural
maupun desain detailnya).
 Biasanya digambarkan menggunakan flowchart.
Konsep Dasar Desain Software
1.
2.
3.
4.
5.
6.
Abstraksi
Coupling
Cohesion
Dekomposisi dan Modularisasi
Encapsulation
Pemisahan antarmuka dan implementasi
Abstraksi
 Proses atau hasil generalisasi suatu permasalahan
- tujuan : agar hanya informasi yang relevan saja yang
digunakan untuk menyusun solusi.
Coupling
 Tingkat relasi (ketergantungan) antara satu modul
dengan modul lain, antar komponen maupun servis.
Cohesion
 Tingkat
independensi
(ketidaktergantungan/kemandirian) antar modul, komponen
maupun servis.
Dekomposisi dan Modularisasi
 Memecahkan entitas/satuan software besar menjadi
beberapa komponen yang independen/mandiri.
- tujuan : agar komponen memiliki tingkat cohesion
tinggi secara fungsional.
Encapsulation
 Menutupi informasi
- menutupi detail internal dari abstraksi sehingga
detail tersebut tidak dapat diakses.
Pemisahan Antarmuka dan Implementasi
 Mendefinisikan komponen publik yang dapat diakses
oleh pengguna dan memisahkan detail bagaimana
komponennya bekerja.