METODOLOGI PENGEMBANGAN

SISTEM INFORMASI
Metodologi pengembangan sistem
 adalah metode-metode, prosedur-prosedur, konsep-
konsep pekerjaan, aturan-aturan yang akan digunakan
sebagai pedoman bagaimana dan apa yang harus
dikerjakan selama pengembangan ini.

 metode adalah suatu cara/teknik sistematis untuk

mengerjakan sesuatu. Urut-urutan prosedur untuk
penyelesaian masalah ini dikenal dengan istilah algoritma.

 Metodologi pengembangan sistem yang akan digunakan

dalam hal ini adalah pendekatan terstruktur.
Metodologi pengembangan sistem

 Pendekatan terstruktur mengenalkan penggunaan

alat-alat dan teknik-teknik untuk mengembangkan
sistem yang terstruktur.

 Tujuan pendekatan terstruktur adalah agar pada akhir

pengembangan perangkat lunak dapat memenuhi
kebutuhan user, dilakukan tepat waktu, tidak
melampaui anggaran biaya, mudah dipergunakan,
mudah dipahami dan mudah dirawat.
 Model-Model Life Cyle

 SDLC Memiliki Beberapa Model dalam Penerapan

Tahapan Proses :
1. Waterfall
2. Prototype
3. RAD
4. Iteratif
5. Spiral
6. Dll
 Model pengembangan SI
(Siklus Hidup SI)

 Model sekuensial linier (clasic life cycle/waterfall model),

terdiri dari tahapan perencanaan sistem (rekayasa sistem),
analisa kebutuhan, desain, penulisan program, pengujian
dan perawatan sistem.

 Model prototipe (prototyping model), dimulai dengan

pengumpulan kebutuhan dan perbaikan, desain cepat,
pembentukan prototipe, evaluasi pelanggan terhadap
prototipe, perbaikan prototipe dan produk akhir.

 Rapid Application Development (RAD) model, dengan

kegiatan dimulai pemodelan bisnis, pemodelan data,
pemodelan proses, pembangkitan aplikasi dan pengujian
 Model pengembangan SI
(Siklus Hidup SI)

 Model evolusioner yang dapat berupa model incremental

atau model spiral Model incremental merupakan gabungan
model sekuensial linier dengan prototyping (mis
perangkat lunak pengolah kata dengan berbagai versi).
Sedangkan model spiral menekan adanya analisa resiko.
Jika analisa resiko menunjukkan ada ketidakpastian
terhadap kebutuhan, maka pengembangan sistem dapat
dihentikan.

 Teknik generasi ke-empat (4GT), dimulai dengan

pengumpulan kebutuhan, strategi perancangan,
implementasi menggunakan 4GL dan pengujia
 Model Air Terjun

 Model air terjun (waterfall) kadang dinamakan siklus

hidup klasik, dimana menyiratkan pendekatan yang
sistematis dan berurutan pada pengembangan perangkat
lunak, tahapanya adalah :
1. Perencanaan
2. Pemodelan
3. Konstruksi
4. Penyerahan sistem ke pelanggan

7
Komunikasi
.
Permulaan
proyek teknik
Perencanaan
pemodelan
Membuat
untuk Analisis
perkiraan- Konstruksi
mendapatkan perkiraan perancangan
Penulisan
spesifikasi penjadwalan kode-kode
kebutuhan pelacakan program Penyerahan
pengguna pengujian sistem
Pengiriman
dokumen
terhadap
pengguna
Umpan balik

8
Teknik untuk
mendapatkan Pengujian oleh
spesifikasi para
kebutuhan pelanggan/penggu
pengguna na

Perancangan Pengujian secara

arsitektur sistem keseluruhan

Perancangan Pengujian setelah

komponen unit-unit
diintegrasikan

Penulisan kode-
kode program Pengujian unit

Perangkat lunak
yang dapat
digunakan oleh9
pelnggan/pengguna
 Model Air Terjun

Beberapa permasalahan model air terjun :

1. Proyek perangkat lunak jarang menggunakan aliran ini.
Meski model linier dapat mengakomodasi perulangan
(iterasi), sesungguhnya tidak langsung.
2. Seringkali pelanggan sulit menetapkan semua
spesifikasi kebutuhan secara ekplisit. Model ini sulit
mengakomodasikan ketidakpastian pada awal proyek
3. Pelanggan harus memiliki kesabaran.
Tahapan siklus ini cenderung “terkunci” banyak anggota
tim harus menunggu tahap sebelumnya.

10
 Model air terjun

Menurut Sommerville, tahapan kegiatan ini meliputi :

1. Analisis dan definisi persyaratan
2. Perancangan sistem dan perangkat lunak
3. Implementasi dan pengujian unit
4. Integrasi dan pengujian
5. Operasi dan pemeliharaan

11
 Definisi
Model air terjun (Sommerville)
persyaratan

Perancangan
sistem dan
perangkat
lunak
Implementasi
dan pengujian
unit

Integrasi dan
pengujian
sistem

Operasi dan
pemeliharaan

12
 Prinsipnya hasil dari setiap fase merupakan satu atau lebih
dokumen yang disetujui (“ditanda tangani”)
 Fase berikutnya tidak boleh dimulai sebelum fase
sebelumnya selesai.
 Pada prakteknya tahap-tahap ini tumpang tindih.
 Pada waktu perancangan, masalah persyaratan didentifikasi,
pada saat pengkodean, ditemukan masalah perancanagn
dan seterusnya

13
 Model air terjun

1. Analisis dan definisi persyaratan,

 Pelayanan, batasan, dan tujuan sistem
ditentukan melalui konsultasi dengan user
sistem
 Persyaratan ini kemudian didefinisikan secara
rinci dan berfungsi sebagai spesifikasi sistem

14
 Model air terjun

2. Perancangan sistem dan perangkat lunak

 Proses membagi menjadi perangkat keras dan
perangkat lunak
 Menentukan arsitektur sistem secara keseluruhan
 Perancangan meliputi identifikasi dan deskripsi
sistem dan hubungannya.

15
 Model air terjun

3. Implementasi dan pengujian unit, realisasi

perancangan dengan program atau unit program,
pengujian dan verifikasi setiap unit yang telah sesuai
spesifikasinya.
4. Integrasi dan pengujian, program diintegrasikan dan
diuji sebagai sistem yang lengkap. Setelah diuji
kemudian diserahkan ke pelanggan

16
 Model air terjun

5. Operasi dan pemeliharaan

 Biasanya merupakan fase paling lama.
 Sistem diinstall dan dipakai
 Pemeliharaan mencakup koreksi dari error,
perbaikan atas implementasi unit dan
pengembangan sistem, dan persyaratan baru
ditambahkan.

17
 Kelebihan
 Proses-prosesnya mudah dipahami dan jelas
 Mudah dalam pengelolaan proyek
 Dokumen dihasilkan setiap akhir fase
 Sebuah fase dijalankan setelah fase sebelumnya
selesai
 Struktur sistem jelas
 Kondisi tepat SDLC waterfall
Kebutuhan user telah sangat dipahami
Kemungkinan terjadi perubahan kebutuhan
user kecil

18
 Kelemahan waterfall

 Proyek dunia nyata jarang mengikuti alur proses

 Kesulitan jika terjadi perubahan kebutuhan
 Waktu pengerjaan bertambah
 Ada anggota tim yang harus menunggu pekerjaan
pekerja lain
 Kesabaran customer/klien

19
 Prototipe
 Prosesnya membuat prototipe secepat mungkin, lalu
memperoleh umpan balik dari pengguna untuk diperbaiki
dengan sangat cepat.
 Sering pelanggan mendefinisikan sasaran PL secara
umum, tetapi tidak mengidentifikasi kebutuhan secara
rinci dan fitur yang akan dikembangkan
 Pembuatan prototipe merupakan pendekatan yang
paling baik

20
Menurut Pressman
metode prototipe Prototipe
Perencanaan
secara cepat

Pemodelan
Perancangan
Komunikasi
secara cepat

Penyerahan
sistem / PL ke
pelanggan dan Pembentukan
umpan balik prototipe

21
 Menurut O’Brien Prototipe
metode prototipe
• Investigasi/Analisis. Pengguna akhir mengidentifikasi
Mengidentifikasi
kebutuhan bisnis mereka dan menilai kelayakan
kebutuhan bisnis
dari beberapa alternatif solusi sistem informasi
pengguna akhir

• Desain/Analisis. Pengguna akhir dan/atau spesialis SI

Mengembangkan menggunakan alat pengembangan aplikasi ke desain dan
prototipe sistem pengujian prototipe komponen sistem informasi secara
bisnis interaktif yang memenuhi kebutuhan bisnis pengguna akhir
Daur
Prototipe

Merevisi prototipe agar • Desain/Implementasi. Prototipe sistem bisnis diuji,

lebih baik dalam dievaluasi, dan diubah berulang kali sampai pengguna
memenuhi kebutuhan akhir menemukan kesesuaian mereka
pengguna akhir
Daur
Pemeliharaan • Implementasi/Pemeliharaan. Sistem bisnis yang sesuai
Menggunakan dan dapat dimodifikasi dengan mudah sejak sebagian besar
memelihara sistem dokumentasi sistem disimpan dalam disk
bisnis yang sesuai
22
 Jenis-jenis prototipe

Menurut McLeod, Terdapat dua jenis prototipe :

1. Prototipe evolusioner (evolutionary prototype),
terus-menurus disempurnakan sampai memiliki
seluruh fungsionalitas yang dibutuhkan pengguna
sistem yang baru.

2. Prototipe persyaratan (requirements prototype),

dikembangkan sebagai satu cara untuk
mendefinisikan persyaratan fungsional dari
pengguna ketika tidak mampu mengungkapkan
apa yang diinginkan.
23
 Prototipe evolusioner

Ada empat langkah pembuatan prototipe evolusioner :

1. Mengidentifikasi kebutuhan pengguna.
2. Membuat satu prototipe
3. Menentukan apakah prototipe dapat diterima
4. Menggunakan prototipe

24
 Prototipe persyaratan
Langkahnya adalah :
1. Mengidentifikasi kebutuhan pengguna.
2. Membuat satu prototipe
3. Menentukan apakah prototipe dapat diterima
4. Membuat kode sistem baru
5. Menguji sistem baru
6. Menentukan apakah sistem yang baru dapat
diterima
7. Membuat sistem baru menjadi sistem produksi

25
 Daya tarik prototipe
Pengguna maupun pengembang menyukai prototipe
karena alasan :
 Membaiknya komunikasi antara pengembang dan
pengguna
 Pengembang dapat melakukan pekerjaan yang lebih
baik dalam menentukan kebutuhan pengguna
 Pengguna memainkan peranan yang lebih aktif dalam
pengembangan sistem
 Pengembang dan pengguna menghabiskan waktu dan
usaha yang lebih sedikit dalam mengembangkan sistem
 Implementasi menjadi jauh lebih mudah karena
pengguna tau apa yang diharapkannya.

26
 Potensi kesulitan dari prototipe
Kesulitan prototipe adalah :
 Terburu-buru dalam menyerahkan prototipe dapat
menyebabkan diambilnya jalan pintas dalam definisi
masalah, evolusi alternatif, dan dokumentasi
 Pengguna dapat terlalu gembira dengan prototipe
yang diberikan
 Prototipe evolusioner bisa jadi tidak terlalu efisien
 Antarmuka komputer-manusia yang diberikan oleh
beberapa alat prototipe tidak mencerminkan teknik
desain yang baik

27
Model RAD
 Tahapan Model RAD

 Pemodelan Bisnis
memodelkan fungsi bisnis  mengetahui Informasi  proses
Bisnis “alur Informasi”
 Pemodelan Data
Mendefinisikan Atribut2 beserta relasi dgn data lain
 Pemodelan Proses
Mengimplementasikan fungsi bisnis yang didefinisikan terkait
dengan data
 Pembuatan Aplikasi
Mengimplementasikan Pemodelan Proses dan data  Program
 Pengujian dan pergantian
menguji komponen yang dibuat
 Keuntungan & kelemahan
Model RAD
Beberapa keuntungan dalam menggunakan metode RAD adalah
sebagai berikut:
 Proses pengiriman menjadi lebih mudah, hal ini dikarenakan proses
pembuatan lebih banyak menggunakan potongan-potongan script.
 Mudah untuk diamati karena menggunakan model prototype,
sehingga user lebih mengerti akan sistem yang dikembangkan.
 Lebih fleksibel karena pengembang dapat melakukan proses desain
ulang pada saat yang bersamaan.
 Bisa mengurangi penulisan kode yang kompleks karena
menggunakan wizard.
 Keterlibatan user semakin meningkat karena merupakan bagian dari
tim secara keseluruhan.
 Mampu meminimalkan kesalahan-kesalahan dengan menggunakan
alat-alat bantuan (CASE tools).
 Mempercepat waktu pengembangan sistem secara keseluruhan
karena cenderung mengabaikan kualitas.
 Tampilan yang lebih standar dan nyaman dengan bantuan software-
 Keuntungan & kelemahan Model
RAD (2)

Beberapa kerugian dalam menggunakan metode RAD adalah sebagai berikut :

 Membutuhkan biaya tersendiri untuk membeli peralatan-peralatan penunjang
seperti misalnya software dan hardware.
 Kesulitan melakukan pengukuran mengenai kemajuan proses.
 Kurang efisien karena apabila melakukan pengkodean dengan menggunakan tangan
bisa lebih efisien.
 Ketelitian menjadi berkurang karena tidak menggunakan metode yang formal dalam
melakukan pengkodean.
 Lebih banyak terjadi kesalahan apabila hanya mengutamakan kecepatan
dibandingkan dengan biaya dan kualitas.
 Fasilitas-fasilitas banyak yang dikurangi karena terbatasnya waktu yang tersedia.
 Sistem sulit diaplikasikan di tempat yang lain.
 Fasilitas yang tidak perlu terkadang harus disertakan, karena menggunakan
komponen yang sudah jadi, sehingga hal ini membuat biaya semakin meningkat.
 Konsep Dasar Model RAD

Konsep Model RAD  Modifikasi Model RAD Sebagai Berikut

:
 Agile Software  interaksi anggota Tim Dgn Pelanggan 
mempercepat proses pengembangan  sesuai kebutuhan
 Contoh : Pengembangan Scrum & pemograman Ekstrim
o Pengembangan Scrum ( semua Tim),  mempercepat
pemgembangan dan Flesibelitas
o Pemograman ekstrim,  komunikasi langsung dengan
User, semasa Programer  utk mendapat Feedback 
sesuai kebutuhan
Selesai