2016

Modul Praktikum Rekayasa

Perangkat Lunak

LABORATORIUM MULTIMEDIA DESIGN

KELOMPOK KEAHLIAN PROGRAMMING &
INTERACTIVE MULTIMEDIA
FAKULTAS ILMU TERAPAN

Hanya dipergunakan di lingkungan Fakultas Ilmu Terapan UNIVERSITAS TELKOM

DAFTAR PENYUSUN
Sulistyoning

Diperbaiki Oleh

-
LEMBAR REVISI

No Keterangan Revisi Tanggal Revisi Terakhir

1 Revisi Bagian Pertama

LEMBAR PERNYATAAN

Saya yang bertanggung jawab di bawah ini:

Nama : Bambang Pudjoatmojo

NIP : 428057003

Jabatan : Kaprodi D4 SM

Kelompok Keahlian : Programming dan Interactive Multimedia

Menerangkan dengan sesungguhnya bahwa modul ini telah diteview dan akan digunakan
untuk pelaksanaan praktikum di - Tahun Ajaran 2016/2017 dan 2017/2016 di Laboratorium Fakultas
Ilmu Terapan Universitas Telkom

Bandung, 10 Agustus 2016

Mengetahui,

Kepala Program Studi D4 Sistem Multimedia

Bambang Pudjoatmojo S.T, M.T

NIP 428057003
 DAFTAR ISI
DAFTAR ISI ............................................................................................................................................... 2
Modul 1 : Pengantar RPL ..................................................................................................................... 5
1.1 Tujuan ..................................................................................................................................... 5
1.2 Dasar Teori .............................................................................................................................. 5
1.2.1 Sejarah RPL...................................................................................................................... 5
1.2.2 Tujuan RPL....................................................................................................................... 6
1.2.3 Bidang Ilmu Terkait ......................................................................................................... 7
1.3 Latihan..................................................................................................................................... 8
Modul 2 : Pengertian RPL .................................................................................................................. 10
2.1 Tujuan ................................................................................................................................... 10
2.2 Dasar Teori ............................................................................................................................ 10
2.2.1 Arti dan Definisi RPL ...................................................................................................... 10
2.2.2 Jenis-jenis Perangkat Lunak .......................................................................................... 11
2.2.3 Ruang Lingkup Perangkat Lunak ................................................................................... 12
2.2.4 Sumber Daya Perangkat Lunak ..................................................................................... 13
2.3 Latihan................................................................................................................................... 15
Modul 3 : Metode dan Proses RPL .................................................................................................... 17
3.1 Tujuan ................................................................................................................................... 17
3.2 Dasar Teori ............................................................................................................................ 17
3.2.1 Tujuan Perancangan Proyek ......................................................................................... 17
3.2.2 SDLC (Software Development Life Cycle)...................................................................... 17
3.2.3 Waterfall ....................................................................................................................... 20
3.2.4 Prototype ...................................................................................................................... 20
3.2.5 RAD (Rapid Application Development) ......................................................................... 22
3.2.6 Agile............................................................................................................................... 26
3.2.7 ADDIE ............................................................................................................................ 44
3.3 Latihan................................................................................................................................... 46
Modul 4 : Perancangan Proyek ......................................................................................................... 48
4.1 Tujuan ................................................................................................................................... 48
4.2 Dasar Teori ............................................................................................................................ 48
4.2.1 Observasi ....................................................................................................................... 48
4.2.2 Tujuan Perancangan Proyek ......................................................................................... 49
4.2.3 Ruang Lingkup dan Batasan Proyek .............................................................................. 49
 4.3 Latihan................................................................................................................................... 51
Modul 5 : Requirement Modelling .................................................................................................... 53
5.1 Tujuan ................................................................................................................................... 53
5.2 Dasar Teori ............................................................................................................................ 53
5.2.1 Prinsip-prinsip Analisis .................................................................................................. 53
5.2.2 Requirement Analysis ................................................................................................... 55
5.2.3 SRS (Software Requirement Specification) ................................................................... 58
5.3 Latihan................................................................................................................................... 60
Modul 6 : System Design ................................................................................................................... 62
6.1 Tujuan ................................................................................................................................... 62
6.2 Dasar Teori ............................................................................................................................ 62
6.2.1 Desain Data ................................................................................................................... 62
6.2.2 Desain Arsitektur........................................................................................................... 62
6.2.3 Desain Antarmuka (Mobile dan Desktop) ..................................................................... 64
6.3 Latihan................................................................................................................................... 65
Modul 7 : Process Modelling ............................................................................................................. 67
7.1 Tujuan ................................................................................................................................... 67
7.2 Dasar Teori ............................................................................................................................ 67
7.2.1 Flowchart ...................................................................................................................... 67
7.2.2 Swimlane ....................................................................................................................... 68
7.2.3 Use Case ........................................................................................................................ 69
7.2.4 DFD (Data Flow Diagram) .............................................................................................. 71
7.2.5 Activity Diagram ............................................................................................................ 72
7.2.6 Sequence Diargam ........................................................................................................ 73
7.3 Latihan................................................................................................................................... 75
Modul 8 : System Building ................................................................................................................. 77
8.1 Tujuan ................................................................................................................................... 77
8.2 Dasar Teori ............................................................................................................................ 77
8.2.1 Bahasa Pemrograman ................................................................................................... 77
8.2.2 Class Diagram ................................................................................................................ 80
8.3 Latihan................................................................................................................................... 82
Modul 9 : System Testing .................................................................................................................. 84
9.1 Tujuan ................................................................................................................................... 84
9.2 Dasar Teori ............................................................................................................................ 84
 9.2.1 Dasar-dasar Pengujian Sistem....................................................................................... 84
9.2.2 Kualitas Perangkat Lunak .............................................................................................. 85
9.2.3 Jaminan Mutu Sistem.................................................................................................... 85
9.2.4 Black Box Testing........................................................................................................... 86
9.2.5 White Box Testing ......................................................................................................... 86
9.2.6 UAT (User Acceptance Test).......................................................................................... 87
9.2.7 Alpha and Beta Testing ................................................................................................. 87
9.3 Latihan................................................................................................................................... 90
Modul 10 : System Maintenance..................................................................................................... 92
10.1 Tujuan ................................................................................................................................... 92
10.2 Dasar Teori ............................................................................................................................ 92
10.2.1 Konsep Pemeliharaan Perangkat Lunak........................................................................ 92
10.2.2 Teknik Pemeliharaan Perangkat Lunak ......................................................................... 93
10.3 Latihan................................................................................................................................... 94
Modul 11 : Validasi RPL ................................................................................................................... 95
11.1 Tujuan ................................................................................................................................... 95
11.2 Dasar Teori ............................................................................................................................ 95
11.2.1 Membangun RPL Sistem Multimedia............................................................................ 95
11.3 Latihan................................................................................................................................... 97
 Modul 1 : Pengantar RPL

1.1 Tujuan
Mahasiswa mampu memahami dasar-dasar pengetahuan mengenai ilmu Rekayasa Perangkat.

1.2 Dasar Teori

1.2.1 Sejarah RPL
Meskipun baru dicetuskan pada tahun 1968, namun RPL telah memiliki sejarah yang cukup panjang.
Perangkat lunak telah semakin berkembang sejak pertama kali diciptakan tahun 1945. Fokus utama
pembuatannya adalah untuk mengembangkan praktik dan teknologi dalam meningkatkan
produktivitas para praktisi pengembang PL dan kualitas aplikasi yg dapat digunakan oleh pemakai.
Evolusi dipicu adanya tuntutan bisnis dan lingkungan kerja yang berkembang sangat dinamis

Gambar dibawah menyajikan intisari perkembangan RPL. Dari sisi disiplin ilmu, RPL masih relatif muda
dan akan terus berkembang. Arah perkembangan yang saat ini sedang dikembangkan antara lain
meliputi :

Berdasarkan Era, perkembangan RPL dapat dikategorikan sebagai berikut:

1. Era I (1945 – 1960):
a. Pengembangan sistem mengarah ke konsep sistem terdistribusi.
b. Penerapan sistem embeded intelligence.
 c. Harga perangkat keras sudah jauh lebih murah sehingga pemakaian meluas.
d. Pemanfaatan jaringan global dan lokal serta sudah diperkenalkan komunikasi digital.

2. Era II (1960 – 1970):

a. Disebut era krisis perangkat lunak (software crisis).
b. Penggunaan perangkat lunak sudah meluas
c. Telah hadir perusahaan yang membangun software (software house)
d. Perangkat lunak sdh mengenal multiprogram, multiuser, real-time, dan penggunaan
database.
e. Banyak project PL yg gagal:
• Over budget/anggaran.
• Meledaknya Roket Ariane àkesalahan perintah dlm PL.
f. Dua konferensi tentang software engineering:
• Disponsori Komite Sains NATO.
• Tahun 1968 dan 1969.
• Profesi resmi bidang software engineering.

3. Era III (1975 – 1985):

a. Pengembangan sistem mengarah ke konsep sistem terdistribusi.
b. Penerapan sistem embeded intelligence.
c. Harga perangkat keras sudah jauh lebih murah sehingga pemakaian meluas.
d. Pemanfaatan jaringan global dan lokal serta sudah diperkenalkan komunikasi digital.

4. Era IV (1985 – 2000):

a. Kemampuan PC sudah setara dengan komputer mainframe.
b. Penerapan teknologi yang berorientasi pada objek.
c. Implementasi sistem pakar.
d. Jaringan saraf tiruan.
e. Komputasi parallel.
f. Jaringan komputer sudah semakin canggih.

5. Era V (2000 – sekarang):

a. Penggunaan media digital.
b. Media web berkembang pesat.
c. Wireless sudah meluas.
d. Teknologi meluas hingga di mobile computing, mobile programming.
e. Perangkat keras sudah semakin kecil namun powerfull.
f. Dilakukan berbagai penelitian yang menghasilkan model proses/paradigma
pengembangan PL untuk mengatasi krisis PL.

1.2.2 Tujuan RPL

Tujuan dasar rekayasa perangkat lunak adalah untuk mengembangkan metode dan prosedur
pengembangan perangkat lunak yang dapat meningkatkan sistem yang besar dan dapat digunakan
secara konsisten untuk menghasilkan perangkat lunak berkualitas tinggi dengan biaya rendah dan
dengan siklus waktu yang kecil.

Secara umum tujuan RPL tidak berbeda dengan bidang rekayasa yang lain. Secara lebih khusus kita
dapat menyatakan tujuan RPL adalah :

a. Memperoleh biaya produksi perangkat lunak yang rendah.

b. Menghasilkan perangkat lunak yang kinerjanya tinggi, andal dan tepat waktu.
c. Menghasilkan perangkat lunak yang dapat bekerja pada berbagai jenis platform.
d. Menghasilkan perangkat lunak yang biaya perawatannya rendah.

1.2.3 Bidang Ilmu Terkait

Cakupan ruang lingkup yang cukup luas, membuat RPL sangat terkait dengan disiplin bidang ilmu lain.
Tidak saja dengan sub-bidang dalam disiplin ilmu komputer namun dengan beberapa disiplin ilmu lain
di luar ilmu komputer. Hubungan keterkaitan RPL dengan ilmu lain dapat dilihat pada Gambar.
 a. Bidang ilmu manajemen meliputi akutansi, finansial, pemasaran, manajemen operasi,
ekonomi, analisis kuantitatif, manajemen sumber daya manusia, kebijakan dan strategi bisnis.
b. Bidang ilmu matematika meliputi aljabar linier, kalkulus, peluang, statistik, analisis numerik
dan matematika diskrit.
c. Bidang ilmu manajemen proyek meliputi semua hal yang berkaitan dengan proyek, seperti
ruang lingkup proyek, anggaran, tenaga kerja, kualitas, manajemen resiko, dan penjadwalan
proyek.
d. Bidang ilmu manajemen kualitas meliputi pengembangan sistem kualitas, manajemen resiko
dan keandalan, perbaikan kualitas, dan metode-metode kuantitatif.
e. Bidang ilmu ergonomika menyangkut hubungan (interaksi) antara manusia dengan
komponen-komponen lain dalam sistem komputer.
f. Bidang ilmu rekayasa sistem meliputi teori sistem, analisis biayakeuntungan, pemodelan,
simulasi, proses dan operasi bisnis.

1.3 Latihan
1. Jelaskan perkembangan Rekayasa Perangkat Lunak berdasarkan tahunnya dan carilah
keunggulan pada setiap tahun perkembangan Rekayasa Perangkat Lunak!
Jawab:
2. Sebutkan lima bidang ilmu lain yang erat kaitannya dengan rekayasa perangkat lunak!
Jawab:

3. Jelaskan tujuan Rekayasa Perangkat Lunak!

Jawab:

DAFTAR PUSTAKA

• Mulyanto, Aunur R. Rekayasa Perangkat Lunak Jilid 1. Direktorat Pembinaan Sekolah

Menengah Kejuruan.2008.

• Rosa A.S- M Shalahuddin, Modul Pembelajaran Rekayasa Perangkat Lunak (Terstruktur dan
Berorientasi Objek), Modula
 Modul 2 : Pengertian RPL
2.1 Tujuan
Mahasiswa mampu memahami dasar-dasar pengetahuan mengenai ilmu Rekayasa Perangkat.

2.2 Dasar Teori

2.2.1 Arti dan Definisi RPL
Nama lain adalah Sofware Engineering.
Software → Perangkat Lunak
→ Kumpulan program komputer dengan fungsi tertentu.
Perangkat Lunak:
1. Instruksi yang bila dieksekusi dapat menjalankan fungsi tertentu.
2. Struktur data yang dapat membuat program memanipulasi informasi.
3. Dokumen yang menjelaskan operasi dan penggunaan program
(Pressman, 1997).
Perangkat lunak adalah seluruh perintah yang digunakan untuk memproses informasi. Perangkat
lunak dapat berupa program atau prosedur.
Program adalah kumpulan perintah yang dimengerti oleh komputer sedangkan prosedur adalah
perintah yang dibutuhkan oleh pengguna dalam memproses informasi.
(O’Brien, 1999).
Engineering → rekayasa.
→ rekayasa/„science‟ untuk menyelesaikan „masalah praktis‟
→ tidak ada/jadul → ada
IEEE-Standar Glossary of Software Engineering Terminology, 1990:
(Institute of Electrical and Electronic Engineering )
1. Computer programs, procedures, and possibly associated documentation and data pertaining
to the operation of a computer system.
2. Terjemahan bebasnya: Perangkat lunak merupakan kumpulan dari berbagai item (program,
prosedur, dan dokumen data yang saling terkait) yang merepresentasikan masalah di dunia
nyata yang dikonfigurasikan dalam satu bentuk aplikasi yang harus dikerjakan komputer.
Rekayasa perangkat lunak dapat didefinisikan sebagai pendekatan sistematis untuk mengembangkan
perangkat lunak dalam waktu dan anggaran yang ditentukan.
Dapat juga diartikan sebagai suatu disiplin ilmu yang membahas semua aspek produksi perangkat
lunak, mulai dari tahap awal yaitu analisa kebutuhan pengguna, menentukan spesifikasi dari
kebutuhan pengguna, desain, pengkodean, pengujian sampai pemeliharaan sistem setelah digunakan.
Rekayasa perangkat lunak adalah disiplin teknologi yang menggabungkan konsep ilmu komputer,
ekonomi, kemampuan komunikasi, dan ilmu manajemen dengan pendekatan pemecahan masalah
dari teknik. Ini juga melibatkan pendekatan terstandar untuk pengembangan program, baik dalam
aspek manajerial maupun teknisnya.
Pengetahuan mendalam tentang ilmu komputer baik teoritis maupun praktis merupakan dasar
rekayasa perangkat lunak. Pengetahuan teoritis memberikan pemahaman tentang masalah mana
yang dapat diatasi, struktur data dan algoritma apa yang sesuai, kapan dan bagaimana
penggunaannya, dan lain sebagainya. Di sisi lain, pengetahuan praktis memberikan pemahaman
tentang bagaimana fungsi perangkat keras, bagaimana memanfaatkan kekuatan bahasa
pemrogramanan dan tools terkait saat mengembangkan perangkat lunak, dan lain-lain.
Rekayasa perangkat lunak adalah pendekatan yang sistematis terhadap pengembangan,
pengoperasian, pemeliharaan dan pengakhiran (retirement) perangkat lunak. Rekayasa Perangkat
Lunak merupakan penerapan sains dan matematika dimana kemampuan peralatan komputer berguna
bagi manusia melalui program komputer, prosedur, dan dokumentasi terkait.
Karakteristik RPL :
1. PL dikembangkan/develop/direkayasa, tidak diproduksi.
2. Tidak pernah aus karena selalu diperbaharui.
3. Invisible (tidak terlihat).
4. Dibangun berdasar kebutuhan/keinginan bukan dari komponen yang sudah ada.
5. Fleksibel, sehingga mudah dimodifikasi.
6. Dihubungkan dengan sistem komputer (+ jaringan).

2.2.2 Jenis-jenis Perangkat Lunak

1. Perangkat Lunak (PL) Sistem

Sekumpulan program yang ditulis untuk melayani program-program lain. Kegunaan PL Sistem lebih
banyak ditujukan untuk operasional komputer. Misal: sistem operasi, driver, kompilator, interpreter,
utility, dll

2. Perangkat Lunak Aplikasi

PL yang kegunaannya lebih banyak ditujukan untuk membantu menyelesaikan masalah-masalah yang
dihadapi oleh pemakai. Perangkat lunak aplikasi dibuat oleh software house yang berguna untuk
menyelesaikan pekerjaan yang sifatnya umum atau standar. Misal : Microsoft Word yang digunakan
untuk membuat suatu dokumen dan Microsoft Excel yang digunakan untuk mengolah data berupa
angka-angka atau grafik.

3. Perangkat Lunak Bahasa Pemrograman

PL yang digunakan dalam pembuatan program. Misal : Visual Basic, Cobolt, Fortran, Visual Fox Pro,
C++, Borland Delphi, ASP (Active Server Pages), PHP, Perk Java, JSP, dan lain-lain.

4. Perangkat Lunak Waktu Nyata (Realtime)

Perangkat lunak yang berfungsi untuk memonitor, menganalisis, mengontrol dan memberikan
laporan tentang kejadian dunia nyata dan meresponnya dalam waktu kurang dari 1 menit. Misal:
pengontrol arus udara, pengontrol keasaman tabung reaksi (pressman punya), pengontrol reaksi
nuklir,dll.

5. Perangkat lunak teknik dan ilmu pengetahuan

(scientific & engineering software)

Perangkat lunak yang menangani bidang teknik dan ilmu pengetahuan secara rinci. Misal: simulasi,
astronomi, vulkanologi, analisis otomatif, dinamika orbit pesawat ruang angkasa, biologi molekuler,
otomasi pabrik, dll
6. Embeded system

Perangkat lunak yg ditempelkan/dilekatkan pada perangkat lainnya (lunak/keras). Misal: pada

kamera digital, GPS, automobil, microwave, kulkas cerdas, dll.

7. Perangkat lunak pengolah data (data processing)

Perangkat lunak yang khusus digunakan untuk mengolah data dan menghasilkan suatu keputusan
tertentu. Misal: billing telepon, pengolah statistic.

8. Perangkat lunak sistem informasi (information system)

Perangkat lunak yang mampu memberi informasi dari suatu sistem secara lebih detail. Misal: web
site, perpustakaan digital, dll

9. Perangkat lunak sensor

Perangkat lunak yang mampu mengukur dan mengatur suatu keadaan khusus, kadang digolongkan
dalam embedded system juga. Misal: pengatur cuaca, pengatur suhu ruangan, dll

10. Perangkat lunak komunikasi (communication software)

Perangkat lunak yang berfungsi untuk menghubungkan atau mengkomunikasikan suatu objek satu
dengan lainnya. Misal: router, handphone, dll

11. Perangkat lunak kantor (offices)

Perangkat lunak yang dirancang untuk membantu tugas-tugas perkantoran. Misal: word processing,
spreedsheet processing, video conferences, dll

12. Perangkat lunak pengolah grafis

Perangkat lunak yang digunakan untuk melakukan perancangan grafis. Misal: pembuatan film,
pembuatan poster

13. Perangkat lunak kecerdasan

Perangkat lunak yang menggunakan algoritma no-numeris untuk memecahkan masalah kompleks
yang tidak sesuai untuk perhitungan atau analisis secara langsung. Misal: sistem pakar, pembuktian
teorema, game strategi, jaringan saraf tiruan, dll.

2.2.3 Ruang Lingkup Perangkat Lunak

Sesuai definisi yang telah disampaikan sebelumnya, maka ruang lingkup RPL dapat digambarkan
sebagai berikut.
1. Software requirements berhubungan dengan spesifikasi kebutuhan dan persyaratan perangkat
lunak.
2. Software design mencakup proses penentuan arsitektur, komponen, antarmuka, dan
karakteristik lain dari perangkat lunak.
3. Software construction berhubungan dengan detil pengembangan perangkat lunak, termasuk
algoritma, pengkodean, pengujian, dan pencarian kesalahan.
4. Software testing meliputi pengujian pada keseluruhan perilaku perangkat lunak.
5. Software maintenance mencakup upaya-upaya perawatan ketika perangkat lunak telah
dioperasikan.
6. Software configuration management berhubungan dengan usaha perubahan konfigurasi
perangkat lunak untuk memenuhi kebutuhan tertentu.
7. Software engineering management berkaitan dengan pengelolaan dan pengukuran RPL,
termasuk perencanaan proyek perangkat lunak.
8. Software engineering tools and methods mencakup kajian teoritis tentang alat bantu dan metode
RPL.
9. Software engineering process berhubungan dengan definisi, implementasi, pengukuran,
pengelolaan, perubahan dan perbaikan proses RPL.
10. Software quality menitikberatkan pada kualitas dan daur hidup perangkat lunak.

2.2.4 Sumber Daya Perangkat Lunak

Dibawah ini merupakan penjelasan lebih spesifik mengenai sumber daya, yaitu:

2.2.4.1 Sumber Daya Manusia

Perencanaan sumber daya manusia memulai dengan mengevaluasi ruang lingkup serta memilih
kecakapan yang dibutuhkan untuk mnyelesaikan pengembangan.Baik posisi organisasi maupun
specialty.Jumlah orang yang diperlukan untuk sebuah proyek perangkat lunak dapat ditentukan
setelah estimasi usaha pengembangan dibuat.
2.2.4.2 Komponen Perangkat lunak (reusable)

Kreasi dan penggunaan kembali blok bangunan perangkat lunak yang seharusnya dikatalog menjadi
referensi yang mudah, distandarisasi untuk aplikasi yang mudah, dan divalidasi untuk integrasi yang
mudah. Ada empat kategori sumber daya perangkat lunak yang harus dipertimbngkan pada saat
perencanaan berlangsung, yaitu :

2.2.4.3 Komponen Off-the self

Perangkat lunak yang ada dapat diperoleh dari bagian ketiga atau telah dikembangkan secara internal
untuk proyek sebelumnya.

2.2.4.4 Komponen Full-Experience

Spesifikasi, kode, desain atau pengujian data yang sudah ada yang dikembangkan pada proyek yang
lalu yang serupa dengan perangkat lunak yang akan dibangun pada proyek saat ini.

2.2.4.5 Komponen Partial-Experience

Aplikasi, kode, desain, atau data pengujiaan yang ada pada proyek yang lalu yang dihubungkan dengan
perangkat lunak yang dibangun untuk proyek saat ini, tetapi akan membutuhkan modifikasi
substansial.

2.2.4.6 Komponen Baru

Komponen perangkat lunak yang harus dibangun oleh tim perangkat lunak khususnya adalah untuk
kebutuhan proyek sekarang .Lebih baik mengkhususkan syarat sumber daya perangkat lunak dari
awal. Dengan cara ini evaluasi teknis dari semua alternatif dapat dilakukan dan akuisisi secara berkala
dapat terjadi.

2.2.4.7 Lingkungan

Lingkungan yang mendukung proyek perangkat lunak, yang disebut juga software engineering
environment (SEE), menggabungkan perangkat lunak dan perangkat keras. Karena sebagian besar
organisasi perangkat lunak memiliki konstituen ganda yang memerlukan akses ke SEE, maka
perencana proyek harus menentukan jendela waktu yang dibutuhkan bagi perangkat keras dan
perangkat lunak serta membuktikan bahwa sember-sumber daya tersebut dapat diperoleh.

Pada saat sebuah sistem berbasis komputer akan direkayasa, tim perangkat lunak mungkin
membutuhkan akses ke elemen perangkat keras yang sedang dikembangkan oleh tim rekayasa yang
lain.
2.3 Latihan
1. Jelaskan pengertian RPL berdasarkan pemahaman sendiri!
Jawab:

2. Jelaskan jenis-jenis perangkat lunak dan sebutkan contohnya!

Jawab:
3. Jelaskan ruang lingkup perangkat lunak dan sebutkan contohnya!
Jawab:

DAFTAR PUSTAKA

• Mulyanto, Aunur R. Rekayasa Perangkat Lunak Jilid 1. Direktorat Pembinaan Sekolah

Menengah Kejuruan.2008.
• “MateriVPerencanaanPerancanganSistemInformasi”.http://learning.upnyk.ac.id/course/vie
w.php?id=551&section=6
 Modul 3 : Metode dan Proses RPL
3.1 Tujuan
Mahasiswa mampu memahami metode-metode yang dapat digunakan dalam perancangan perangkat
lunak.

3.2 Dasar Teori

3.2.1 Tujuan Perancangan Proyek

Tujuan umum dari perencanaan proyek perangkat lunak adalah:

1. Menyediakan sebuah kerangka kerja yang memungkinkan manajer membuat estimasi yang
dapat dipertanggung-jawabkan mengenai sumber daya, biaya dan jadwal. Estimasi dibuat
dengan sebuah kerangka waktu yang terbatas pada awal sebuah proyek perangkat lunak dan
seharusnya diperbaharui secara teratur selagi proyek sedang berjalan.
2. Untuk pengawasan, penelusuran, dan pemantauan sebuah proyek teknik yang kompleks.

3.2.2 SDLC (Software Development Life Cycle)

Software Development Life Cycle (SDLC) adalah proses yang digunakan oleh industri perangkat lunak
untuk merancang, mengembangkan dan menguji perangkat lunak berkualitas tinggi. SDLC bertujuan
untuk menghasilkan perangkat lunak berkualitas tinggi yang memenuhi atau melebihi harapan
pelanggan, mencapai penyelesaian dalam waktu dan perkiraan biaya.

1. SDLC adalah akronim dari Software Development Life Cycle.

2. Ini juga disebut sebagai Proses Pengembangan Perangkat Lunak.

3. SDLC adalah kerangka kerja mendefinisikan tugas yang dilakukan pada setiap langkah dalam
proses pengembangan perangkat lunak.

4. ISO / IEC 12207 adalah standar internasional untuk proses siklus hidup perangkat lunak. Ini
bertujuan untuk menjadi standar yang mendefinisikan semua tugas yang diperlukan untuk
mengembangkan dan memelihara perangkat lunak.

3.2.2.1 Pengertian SDLC

SDLC adalah proses yang diikuti untuk proyek perangkat lunak, dalam organisasi perangkat lunak. Ini
terdiri dari rencana rinci yang menjelaskan cara mengembangkan, memelihara, mengganti dan
mengubah atau meningkatkan perangkat lunak tertentu. Siklus hidup mendefinisikan metodologi
untuk meningkatkan kualitas perangkat lunak dan keseluruhan proses pengembangan.

Gambar berikut adalah representasi grafis dari berbagai tahapan SDLC khas.
Siklus Hidup Pengembangan Perangkat Lunak yang khas terdiri dari tahap-tahap berikut :

1. Perencanaan dan Analisis Kebutuhan

Analisis kebutuhan adalah tahap yang paling penting dan mendasar dalam SDLC. Ini dilakukan oleh
anggota senior tim dengan masukan dari pelanggan, departemen penjualan, survei pasar, dan
pakar domain di industri. Informasi ini kemudian digunakan untuk merencanakan pendekatan
proyek dasar dan untuk melakukan studi kelayakan produk di bidang ekonomi, operasional dan
teknis.

Perencanaan untuk persyaratan jaminan kualitas dan identifikasi risiko yang terkait dengan proyek
juga dilakukan dalam tahap perencanaan. Hasil dari studi kelayakan teknis adalah untuk
menentukan berbagai pendekatan teknis yang dapat diikuti untuk melaksanakan proyek dengan
sukses dengan risiko minimum.

2. Menentukan Persyaratan

Setelah analisis kebutuhan dilakukan, langkah selanjutnya adalah mendefinisikan secara jelas dan
mendokumentasikan persyaratan produk dan membuatnya disetujui oleh pelanggan atau analis
pasar. Ini dilakukan melalui dokumen SRS (Spesifikasi Kebutuhan Perangkat Lunak) yang terdiri
dari semua persyaratan produk yang akan dirancang dan dikembangkan selama siklus hidup
proyek.

3. Merancang Arsitektur Produk

SRS adalah referensi bagi para arsitek produk untuk menghasilkan arsitektur terbaik untuk produk
yang akan dikembangkan. Berdasarkan persyaratan yang ditentukan dalam SRS, biasanya lebih
dari satu pendekatan desain untuk arsitektur produk diusulkan dan didokumentasikan dalam DDS
- Spesifikasi Dokumen Desain.

DDS ini ditinjau oleh semua pemangku kepentingan yang penting dan berdasarkan berbagai
parameter sebagai penilaian risiko, ketahanan produk, desain modularitas, anggaran dan batasan
waktu, pendekatan desain terbaik dipilih untuk produk.
 Pendekatan desain dengan jelas mendefinisikan semua modul arsitektur produk bersama dengan
komunikasi dan representasi aliran data dengan modul eksternal dan pihak ketiga (jika ada).
Desain internal semua modul arsitektur yang diusulkan harus didefinisikan secara jelas dengan
rincian terkecil dalam DDS.

4. Membangun atau Mengembangkan Produk

Dalam tahap ini SDLC dimulai pengembangan yang sebenarnya dan produk dibangun. Kode
pemrograman dihasilkan sesuai DDS selama tahap ini. Jika desain dilakukan secara terinci dan
terorganisir, pembuatan kode dapat diselesaikan tanpa banyak kerumitan.

Pengembang harus mengikuti panduan pengkodean yang ditentukan oleh organisasi mereka dan
alat pemrograman seperti kompiler, interpreter, debugger, dll. Digunakan untuk menghasilkan
kode. Bahasa pemrograman tingkat tinggi yang berbeda seperti C, C ++, Pascal, Java dan PHP
digunakan untuk pengkodean. Bahasa pemrograman dipilih sehubungan dengan jenis perangkat
lunak yang sedang dikembangkan.

5. Menguji Produk

Tahap ini biasanya merupakan bagian dari semua tahapan seperti dalam model SDLC modern,
kegiatan pengujian sebagian besar terlibat dalam semua tahap SDLC. Namun, tahap ini mengacu
pada tahap pengujian hanya dari produk di mana cacat produk dilaporkan, dilacak, diperbaiki dan
diuji ulang, hingga produk mencapai standar kualitas yang ditentukan dalam SRS.

6. Deployment di Pasar dan Pemeliharaan

Setelah produk diuji dan siap untuk digunakan, produk ini dirilis secara resmi di pasar yang sesuai.
Terkadang penyebaran produk terjadi secara bertahap sesuai strategi bisnis organisasi tersebut.
Produk ini mungkin pertama kali dirilis dalam segmen terbatas dan diuji dalam lingkungan bisnis
yang sebenarnya (pengujian penerimaan Pengguna UAT).

Kemudian berdasarkan umpan balik, produk dapat dirilis sebagaimana adanya atau dengan
peningkatan yang disarankan dalam segmen pasar penargetan. Setelah produk dirilis di pasar,
pemeliharaannya dilakukan untuk basis pelanggan yang ada.

3.2.2.2 Model SDLC

Ada berbagai model siklus pengembangan perangkat lunak yang didefinisikan dan dirancang yang
diikuti selama proses pengembangan perangkat lunak. Model-model ini juga disebut sebagai Model
Proses Pengembangan Perangkat Lunak. ”Setiap model proses mengikuti serangkaian langkah-
langkah unik untuk jenisnya untuk memastikan keberhasilan dalam proses pengembangan perangkat
lunak.

Berikut ini adalah model SDLC yang paling penting dan populer yang diikuti dalam industri & miun;

1. Model Air Terjun

2. Model Iteratif
3. Model Spiral
4. V-Model
5. Model Big Bang
Metodologi terkait lainnya adalah Model Agile, Model RAD, Pengembangan Aplikasi Cepat, dan Model
Prototyping.

3.2.3 Waterfall
Model siklus hidup (life cycle model) adalah model utama dan dasar dari banyak model. Salah satu
model yang cukup dikenal dalam dunia rekayasa perangkat lunak adalah The Waterfall Model. Ada 5
tahapan utama dalam The Waterfall Model seperti terlihat pada Gambar 2.3. Disebut waterfall (berarti
air terjun) karena memang diagram tahapan prosesnya mirip dengan air terjun yang bertingkat.
Tahapan-tahapan dalam The Waterfall Model secara ringkas adalah sebagai berikut:
1. Tahap investigasi dilakukan untuk menentukan apakah terjadi suatu masalah atau adakah
peluang suatu sistem informasi dikembangkan. Pada tahapan ini studi kelayakan perlu
dilakukan untuk menentukan apakah sistem informasi yang akan dikembangkan merupakan
solusi yang layak.
2. Tahap analisis bertujuan untuk mencari kebutuhan pengguna dan organisasi serta
menganalisa kondisi yang ada (sebelum diterapkan sistem informasi yang baru).
3. Tahap disain bertujuan menentukan spesifikasi detil dari komponenkomponen sistem
informasi (manusia, hardware, software, network dan data) dan produk-produk informasi
yang sesuai dengan hasil tahap analisis.
4. Tahap implementasi merupakan tahapan untuk mendapatkan atau mengembangkan
hardware dan software (pengkodean program), melakukan pengujian, pelatihan dan
perpindahan ke sistem baru.
5. Tahapan perawatan (maintenance) dilakukan ketika sistem informasi sudah dioperasikan.
Pada tahapan ini dilakukan monitoring proses, evaluasi dan perubahan (perbaikan) bila
diperlukan.

3.2.4 Prototype
Prototyping adalah salah satu pendekatan dalam rekayasa perangkat lunak yang secara langsung
mendemonstrasikan bagaimana sebuah perangkat lunak atau komponen-komponen perangkat lunak
akan bekerja dalam lingkungannya sebelum tahapan konstruksi aktual dilakukan (Howard, 1997).
Prototyping model dapat diklasifikasikan menjadi beberapa tipe seperti terlihat pada gambar.
 1. Reusable prototype : Prototype yang akan ditransformasikan menjadi produk final.
2. Throwaway prototype : Prototype yang akan dibuang begitu selesai menjalankan maksudnya.
3. Input/output prototype : Prototype yang terbatas pada antar muka pengguna (user interface).
4. Processing prototype : Prototype yang meliputi perawatan file dasar dan proses-proses
transaksi.
5. System prototype : Prototype yang berupa model lengkap dari perangkat lunak.

Tahap-tahap dalam prototyping boleh dikata merupakan tahap-tahap yang dipercepat. Strategi utama
dalam prototyping adalah kerjakan yang mudah terlebih dahulu dan sampaikan hasil kepada
pengguna sesegera mungkin. Harris (2003) membagi prototyping dalam enam tahapan seperti terlihat
pada gambar.

Tahapan-tahapan secara ringkas dapat dijelaskan sebagai berikut:

1. Identifikasi kandidat prototyping. Kandidat dalam kasus ini meliputi user interface (menu,
dialog, input dan output), file-file transaksi utama, dan fungsi-fungsi pemrosesan sederhana.
2. Rancang bangun prototype dengan bantuan software seperti word processor, spreadsheet,
database, pengolah grafik, dan software CASE (Computer-Aided System Engineering).
3. Uji prototype untuk memastikan prototype dapat dengan mudah dijalankan untuk tujuan
demonstrasi.
4. Siapkan prototype USD (User’s System Diagram) untuk mengidentifikasi bagian-bagian dari
perangkat lunak yang di-prototype-kan.
5. Evaluasi dengan pengguna untuk mengevaluasi prototype dan melakukan perubahan jika
diperlukan.
6. Transformasikan prototype menjadi perangkat lunak yang beroperasi penuh dengan
melakukan penghilangan kode-kode yang tidak dibutuhkan, penambahan program-program
yang memang dibutuhkan dan perbaikan dan pengujian perangkat lunak secara berulang.
3.2.5 RAD (Rapid Application Development)

Model RAD (Rapid Application Development) didasarkan pada pengembangan prototipe dan iteratif
tanpa perencanaan khusus yang terlibat. Proses penulisan perangkat lunak itu sendiri melibatkan
perencanaan yang diperlukan untuk mengembangkan produk.

Rapid Application Development berfokus pada pengumpulan kebutuhan pelanggan melalui lokakarya
atau grup fokus, pengujian awal prototipe oleh pelanggan menggunakan konsep iteratif, penggunaan
kembali prototipe yang ada (komponen), integrasi berkelanjutan dan pengiriman cepat.

3.2.5.1 Pengertian RAD

Pengembangan aplikasi yang cepat adalah metodologi pengembangan perangkat lunak yang
menggunakan perencanaan minimal demi pembuatan prototipe yang cepat. Prototipe adalah model
kerja yang secara fungsional setara dengan komponen produk.

Dalam model RAD, modul fungsional dikembangkan secara paralel sebagai prototipe dan terintegrasi
untuk membuat produk lengkap untuk pengiriman produk lebih cepat. Karena tidak ada perencanaan
awal yang rinci, ini mempermudah untuk memasukkan perubahan dalam proses pengembangan.

Proyek RAD mengikuti model iteratif dan inkremental dan memiliki tim kecil yang terdiri dari
pengembang, pakar domain, perwakilan pelanggan, dan sumber daya TI lainnya yang bekerja secara
progresif pada komponen atau prototipe mereka.

Aspek yang paling penting untuk model ini agar berhasil adalah untuk memastikan bahwa prototipe
yang dikembangkan dapat digunakan kembali.
3.2.5.2 Desain Model RAD

Model RAD mendistribusikan analisis, desain, membangun dan menguji fase menjadi serangkaian
siklus pengembangan yang singkat dan berulang.

Berikut ini adalah berbagai fase Model RAD :

1. Pemodelan Bisnis
Model bisnis untuk produk yang sedang dikembangkan dirancang berdasarkan arus informasi dan
distribusi informasi di antara berbagai saluran bisnis. Analisis bisnis lengkap dilakukan untuk
menemukan informasi penting untuk bisnis, bagaimana hal itu dapat diperoleh, bagaimana dan
kapan informasi diproses dan apa faktor-faktor yang mendorong arus informasi yang sukses.

2. Pemodelan Data
Informasi yang dikumpulkan dalam fase Pemodelan Bisnis ditinjau dan dianalisis untuk
membentuk set objek data yang penting untuk bisnis. Atribut semua set data diidentifikasi dan
didefinisikan. Hubungan antara objek-objek data ini ditetapkan dan didefinisikan secara rinci
dalam relevansi dengan model bisnis.

3. Pemodelan Proses

Kumpulan objek data yang ditentukan dalam fase Pemodelan Data dikonversi untuk menetapkan
aliran informasi bisnis yang diperlukan untuk mencapai tujuan bisnis tertentu sesuai model bisnis.
Model proses untuk setiap perubahan atau penyempurnaan pada kumpulan objek data
ditentukan dalam fase ini. Deskripsi proses untuk menambahkan, menghapus, mengambil atau
memodifikasi objek data diberikan.

4. Generasi Aplikasi

Sistem yang sebenarnya dibangun dan pengkodean dilakukan dengan menggunakan alat
otomatisasi untuk mengubah proses dan model data menjadi prototipe yang sebenarnya.

5. Pengujian dan Perputaran

Waktu pengujian keseluruhan dikurangi dalam model RAD sebagai prototipe diuji secara
independen selama setiap iterasi. Namun, aliran data dan antarmuka antara semua komponen
harus diuji secara menyeluruh dengan cakupan uji yang lengkap. Karena sebagian besar
komponen pemrograman telah diuji, itu mengurangi risiko masalah besar.

Ilustrasi berikut menjelaskan Model RAD secara detail.

3.2.5.3 Model RAD Vs SDLC Tradisional

SDLC tradisional mengikuti model proses yang kaku dengan penekanan tinggi pada analisis kebutuhan
dan pengumpulan sebelum pengkodean dimulai. Ini memberi tekanan pada pelanggan untuk
menandatangani persyaratan sebelum proyek dimulai dan pelanggan tidak merasakan produk karena
tidak ada bangunan kerja yang tersedia untuk waktu yang lama.

Pelanggan mungkin memerlukan beberapa perubahan setelah dia melihat perangkat lunak. Namun,
proses perubahan cukup kaku dan mungkin tidak layak untuk memasukkan perubahan besar dalam
produk dalam SDLC tradisional.

Model RAD berfokus pada pengiriman model kerja secara iteratif dan inkremental kepada pelanggan.
Hal ini menghasilkan pengiriman cepat ke pelanggan dan keterlibatan pelanggan selama siklus
pengembangan produk lengkap yang mengurangi risiko ketidaksesuaian dengan persyaratan
pengguna yang sebenarnya.
Model RAD - Aplikasi

Model RAD dapat diterapkan dengan sukses ke proyek-proyek di mana modularisasi jelas
dimungkinkan. Jika proyek tidak dapat dipecah menjadi modul, RAD bisa gagal.

Pointer berikut menggambarkan skenario khas di mana RAD dapat digunakan :

1. RAD harus digunakan hanya ketika suatu sistem dapat dimodulasikan untuk disampaikan
secara bertahap.
2. Itu harus digunakan jika ada ketersediaan tinggi desainer untuk pemodelan.
3. Ini harus digunakan hanya jika anggaran memungkinkan penggunaan alat pembuat kode
otomatis.
4. Model RAD SDLC harus dipilih hanya jika pakar domain tersedia dengan pengetahuan bisnis
yang relevan.
5. Harus digunakan bila persyaratan berubah selama proyek dan prototipe yang berfungsi harus
disajikan kepada pelanggan dalam iterasi kecil selama 2-3 bulan.
3.2.5.4 Model RAD - Pro dan Kontra

Model RAD memungkinkan pengiriman cepat karena mengurangi waktu pengembangan secara
keseluruhan karena usabilitas komponen dan pengembangan paralel. RAD bekerja dengan baik hanya
jika insinyur terampil yang tinggi tersedia dan pelanggan juga berkomitmen untuk mencapai prototipe
yang ditargetkan dalam kerangka waktu yang diberikan. Jika ada komitmen yang kurang di kedua sisi,
model mungkin gagal.

Keuntungan dari Model RAD adalah sebagai berikut :

1. Mengubah persyaratan dapat ditampung.

2. Kemajuan dapat diukur.

3. Iterasi waktu dapat menjadi pendek dengan menggunakan alat RAD yang kuat.

4. Produktivitas dengan lebih sedikit orang dalam waktu singkat.

5. Waktu pengembangan berkurang.

6. Meningkatkan reusabilitas komponen.

7. Ulasan awal cepat terjadi.

8. Mendorong umpan balik pelanggan.

9. Integrasi dari awal menyelesaikan banyak masalah integrasi.

Kerugian dari Model RAD adalah sebagai berikut :

1. Ketergantungan pada anggota tim yang kuat secara teknis untuk mengidentifikasi persyaratan
bisnis.

2. Hanya sistem yang dapat dimodulasi dapat dibangun menggunakan RAD.

3. Membutuhkan para pengembang / perancang yang sangat terampil.

4. Ketergantungan tinggi pada keterampilan pemodelan.

5. Tidak dapat diterapkan untuk proyek yang lebih murah karena biaya pemodelan dan
pembuatan kode otomatis sangat tinggi.

6. Kompleksitas manajemen lebih banyak.

7. Cocok untuk sistem yang berbasis komponen dan terukur.

8. Membutuhkan keterlibatan pengguna sepanjang siklus hidup.

9. Cocok untuk proyek yang membutuhkan waktu pengembangan yang lebih singkat.
3.2.6 Agile
Agile Methods dikembangkan karena pada metodologi tradisional terdapat banyak hal yang membuat
proses pengembangan tidak dapat berhasil dengan baik sesuai tuntutan user. Konsep Agile Software
Development dicetuskan oleh Kent Beck dan 16 rekannya dengan menyatakan bahwa Agile Software
Development adalah cara membangun software dengan melakukannya dan membantu orang lain
membangunnya sekaligus.

Agile methods merupakan salah satu dari beberapa metode yang digunakan dalam penSgembangan
sooftware. Agile method adalah jenis pegembangan sistem jangka pendek yang memerlukan adaptasi
cepat dan pengembang terhadap perubahan dalam bentuk apapun.

Dalam Agile Software Development interaksi dan personel lebih penting dari pada proses dan alat,
software yang berfungsi lebih penting daripada dokumentasi yang lengkap, kolaborasi dengan klien
lebih penting dari pada negosiasi kontrak, dan sikap tanggap terhadap perubahan lebih penting
daripada mengikuti rencana.

Agile Method juga dapat diartikan sekelompok metodologi pengembangan software yang didasarkan
pada prinsip-prinsip yang sama atau pengembangan system jangka pendek yang memerlukan adaptasi
cepat dari pengembang terhadap perubahan dalam bentuk apapun.

Agile Method percaya bahwa setiap proyek harus ditangani secara berbeda dan metode yang ada
perlu disesuaikan agar sesuai dengan kebutuhan proyek. Di Agile, tugas dibagi ke kotak waktu (bingkai
waktu kecil) untuk memberikan fitur-fitur spesifik untuk rilis.

Pendekatan berulang diambil dan perangkat lunak yang bekerja dibangun setelah setiap iterasi. Setiap
build bersifat inkremental dalam hal fitur; build terakhir berisi semua fitur yang dibutuhkan oleh
pelanggan.

Berikut ini adalah ilustrasi grafis dari Model Agile:

Proses pemikiran Agile telah dimulai pada awal pengembangan perangkat lunak dan mulai menjadi
populer seiring waktu karena fleksibilitas dan kemampuan beradaptasi.
Metode Agile yang paling populer termasuk Rational Unified Process (1994), Scrum (1995), Crystal
Clear, Extreme Programming (1996), Pengembangan Perangkat Lunak Adaptif, Pengembangan
Berbasis Fitur, dan Metode Pengembangan Sistem Dinamis (DSDM) (1995). Ini sekarang secara kolektif
disebut sebagai Metodologi Agile, setelah Manifesto Agile diterbitkan pada tahun 2001.

3.2.6.1 Prinsip Agile Software Development

1. Kepuasan klien adalah prioritas utama dengan menghasilkan produk lebih awal dan terus
menerus.

2. Menerima perubahan kebutuhan, sekalipun diakhir pengembangan.

3. Penyerahan hasil/software dalam hitungan waktu beberapa minggu sampai beberapa bulan.

4. Pihak bisnis dan pengembang harus bekerja sama setiap hari selama pengembangan berjalan.

5. Membangun proyek dilingkungan orang-orang yang bermotivasi tinggi yang bekerja dalam
lingkungan yang mendukun dan yang dipercaya untuk dapat menyelesaikan proyek.

6. Komunikasi dengan berhadapan langsung adalah komunikasi yang efektif dan efisien.

7. Software yang berfungsi adalah ukuran utama dari kemajuan proyek.

8. Dukungan yang stabil dari sponsor, pembangun, dan pengguna diperlukan untuk menjaga
perkembangan yang berkesinambungan.

9. Perhatian kepada kehebatan teknis dan desain yang bagus meningkatkan sifat agile.

10. Kesederhanaan penting.

11. Arsitektur, kebutuhan dan desain yang bagus muncuk dari tim yang mengatur dirinya sendiri.

12. Secara periodik tim evaluasi diri dan mencari cara untuk lebih efektif dan segera melakukannya

Dengan prinsip-prinsip tersebut Agile Process Model berusaha untuk menyiasati 3 asumsi penting
tentang proyek software pada umumnya:

1. Kebutuhan software sulit diprediksi dari awal dan selalu akan berubah. Selain itu, prioritas klien
juga sering berubah seiring berjalannya proyek.

2. Desain dan pembangunan sering tumpang tindih. Sulit diperkirakan seberapa jauh desain yang
diperlukan sebelum pembangunan.

3. Analisis, desain, pembangunan dan testing tidak dapat diperkirakan seperti yang diinginkan.

3.2.6.2 Model Agile - Pro dan Kontra

Agile metode sedang diterima secara luas di dunia perangkat lunak baru-baru ini. Namun, metode ini
mungkin tidak selalu cocok untuk semua produk. Berikut adalah beberapa pro dan kontra dari model
Agile.

3.2.6.3 Keuntungan dan Kerugian Model Agile

1. Keuntungan dari Model Agile adalah sebagai berikut:
a. Adalah pendekatan yang sangat realistis untuk pengembangan perangkat lunak.
b. Mempromosikan kerja tim dan pelatihan silang.
c. Fungsionalitas dapat dikembangkan dengan cepat dan didemonstrasikan.
d. Persyaratan sumber daya minimum.
e. Cocok untuk persyaratan tetap atau berubah.
 f. Menghasilkan solusi kerja parsial awal.
g. Model yang bagus untuk lingkungan yang berubah dengan mantap.
h. Aturan minimal, dokumentasi mudah digunakan.
i. Memungkinkan pengembangan dan pengiriman bersamaan dalam konteks yang
direncanakan secara keseluruhan.
j. Sedikit atau tidak ada perencanaan yang diperlukan.
k. Mudah dikelola.
l. Memberikan fleksibilitas kepada pengembang.
2. Kerugian dari Model Agile adalah sebagai berikut -
a. Tidak cocok untuk menangani dependensi yang rumit.
b. Lebih banyak risiko keberlanjutan, pemeliharaan dan diperpanjang.
c. Rencana keseluruhan, pemimpin lincah dan latihan PM tangkas adalah suatu keharusan
yang tanpanya tidak akan berhasil.
d. Manajemen pengiriman yang ketat menentukan ruang lingkup, fungsi yang akan
dikirimkan, dan penyesuaian untuk memenuhi tenggat waktu.
e. Sangat bergantung pada interaksi pelanggan, jadi jika pelanggan tidak jelas, tim dapat
didorong ke arah yang salah.
f. Ada ketergantungan individu yang sangat tinggi, karena ada dokumentasi minimum yang
dihasilkan.
g. Transfer teknologi ke anggota tim baru mungkin cukup menantang karena kurangnya
dokumentasi.

3.2.6.4 Model-model Agile method

1. Extreme Programmning (XP)

Proyek Pemrograman Extreme pertama dimulai 6 Maret 1996. Extreme Programming adalah salah
satu dari beberapa Proses Agile populer. Sudah terbukti sangat sukses di banyak perusahaan dari
berbagai ukuran dan industri di seluruh dunia.

Extreme Pemrograman menekankan kerja sama tim. Pengelola, pelanggan, dan pengembang semua
mitra setara dalam sebuah tim kolaboratif. Extreme Pemrograman menerapkan, sederhana namun
efektif yang memungkinkan tim lingkungan menjadi sangat produktif. Tim mengorganisir diri
mengatasi masalah untuk menyelesaikannya seefisien mungkin.

Extreme Programming adalah metode pengembangan perangkat lunak yang ringan dan termasuk
salah satu agile methods yang dipelopori oleh Kent Beck, Ron Jeffries, dan Ward Cunningham. Extreme
Programming merupakan agile methods yang paling banyak digunakan dan menjadi sebuah
pendekatan yang sangat terkenal. Sasaran Extreme Programming adalah tim yang dibentuk berukuran
antara kecil sampai medium saja, tidak perlu menggunakan sebuah tim yang besar. Hal ini
dimaksudkan untuk menghadapi requirements yang tidak jelas maupun terjadinya perubahan-
perubahan requirements yang sangat cepat.

Extreme Programming sebagai sebuah metode yang dinamis diperlihatkan dalam empat values yang
dimilikinya dan keempatnya merupakan dasar-dasar yang diperlukan dalam Extreme Programming.
Kent Beck menyatakan bahwa tujuan jangka pendek individu sering berbenturan dengan tujuan sosial
jangka panjang. Karena itu dibuatlah values yang menjadi aturan, hukuman, dan juga penghargaan.
Keempat values tersebut adalah :

a. Komunikasi (Communication)

Tugas utama developer dalam membangun suatu sistem perangkat lunak adalah
mengkomunikasikan kebutuhan sistem kepada pengembang perangkat lunak. Komunikasi dalam
 Extreme Programmning dibangun dengan melakukan pemrograman berpasangan (pair
programming). Developer didampingi oleh pihak klien dalam melakukan coding dan unit testing
sehingga klien bisa terlibat langsung dalam pemrograman sambil berkomunikasi dengan
developer. Tujuannya untuk memberikan pandangan pengembang sesuai dengan pandangan
pengguna sistem.

b. Kesederhanaan (Simplicity)

XP mencoba untuk mencari solusi paling sederhana dan praktis. Perbedaan metode ini dengan
metodologi pengembangan sistem konvensional lainnya terletak pada proses desain dan coding
yang terfokus pada kebutuhan saat ini daripada kebutuhan besok, seminggu lagi atau sebulan lagi.
Lebih baik melakukan hal yang sederhana dan mengembangkannya besok jika diperlukan.

c. Umpan Balik (Feedback)

Hal ini diperlukan untuk mengetahui kemajuan dari proses dan kualitas dari aplikasi yang
dibangun. Informasi ini harus dikumpulkan setiap interval waktu yang singkat secara konsisten. Ini
dimaksudkan agar hal-hal yang menjadi masalah dalam proses pengembangan dapat diketahui
sedini mungkin. Setiap feed back ditanggapi dengan melakukan tes, unit test atau system
integration dan jangan menunda karena biaya akan membengkak (uang, tenaga, waktu).

d. Keberanian (Courage)

Berani mencoba ide baru. Berani mengerjakan kembali dan setiap kali kesalahan ditemukan,
langsung diperbaiki. Contoh dari courage adalah komitmen untuk selalu melakukan design dan
coding untuk saat ini dan bukan untuk esok. Ketika ada kode yang terlalu rumit, sulit dibaca dan
dipahami, tidak sesuai dengan kemauan pelanggan, dll maka seharusnya kode program seperti itu
di refactor (kalau perlu dibangun ulang). Hal ini menjadikan pengembang merasa nyaman
dengan refactoringprogram ketika diperlukan

Extreme Programming menggunakan pendekatan berorientasi objek. Pada aktifitas Perencanaan

terjadi pengumpulan user stories dari klien yang klien tetapkan prioritasnya. Setiap story ditetapkan
harga dan lama pembangunan, jika terlalu besar, story dapat dipecah menjadi beberapa story yang
lebih kecil. Terjadi pemeriksaan dan pertimbangkan resiko dan aktifitas Desain kegiatannya sederhana
yaitu memanfaatkan kartu CRC (Class-Responsibility-Collaborator) untuk identifikasi dan mengatur
class-class di konsep OO. Jika temuikan kesulitan, prototype dibangun [ini namanya spike solution].

Extreme Programmning adalah suatu bentuk pembangunan perangkat lunak yang berbasis nilai
kemudahan, komunikasi, umpan balik, dan keberanian. Bekerja dalam whole team bersama-sama
dengan praktek yang mudah.

Dalam Extreme Programming terdapat 12 practices utama yaitu :

1. Planning Game

Hubungan antara Customer dengan Programer untuk memperkirakan kenbutuhan –kebutuhan dari
Custumer dalam implementasinya.

a. Small, frequent releases : Memproduksi dengan cepat.

b. System metaphors
System metaphors antara Customer dengan Programeruntuk menunjukkan semua perkembangan
dengan menjelaskan bagaimana cara kerja system.

a. Simple design: Perhatiannya pada pendisainnan atau perancngan solusi yang sederhana
b. Testing (unit testing & TDD) : Pelaksanaan pengujian atau testing keseluruhan
c. Frequent refactoring

Penyusunan system kembali dengan cara duplikat atau salinan,memperbaiki komunikasi,

menambahkan kelenturan.

a. Pair programming : Dua orang menulis kode pada 1 komputer

b. Collective code ownership : Siapapun dapat merubah bagian pada pengkodean setiap saat.
c. Continuous integration : Bagian baru code di gabungkan ke dalam kode dasar
d. 40-hour weak : Max 40 jam kerja seminggu,
e. On-site customer : Customer harus hadir dan ada setiap saat untuk teamnya.
f. Coding standards : Terdapat aturan pengkodean dan di ikuti oleh programmer.

Keuntungan dan Kerugian

a. Keuntungan Extreme Programmning:

Menjalin komunikasi yang baik dengan client. Meningkatkan komunikasi dan sifat saling
menghargai antar developer.

b. Kerugian Extreme Programmning:

Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima. Tidak bisa
membuat kode yang detail di awal (prinsip simplicity dan juga anjuran untuk melakukan apa yang
diperlukan hari itu juga).

Proses Extreme Programming (XP)

2. Adaptive Software Development (ASD)

Adaptive Software Development (ASD) diajukan oleh Jim Highsmith sebagai teknik untuk membangun
software dan sistem yang kompleks. Filosofi yang mendasari Adaptive Software Development (ASD)
adalah kolaborasi manusia dan tim yang mengatur diri sendiri.

a. System kerja adaptive software development : Collaboration dan Learning.

b. Adaptive cycle planning yaitu menggunakan informasi awal seperti misi dari klien, batasan proyek
dan kebutuhan dasar untuk definisikan rangkaian software increment (produk software yang
secara berkala diserahkan)
 Collaboration : orang-orang yang bermotivasi tinggi bekerja sama: saling melengkapi, rela
membantu, kerja keras, trampil di bidangnya, dan komunikasikan masalah untuk hasilkan
penyelesaian yang efektif.
c. Learning: tim pembangun sering merasa sudah tahu semua hal tentang proyek,
 Padahal tidak selamanya begitu. Karena itu proses ini membuat mereka belajar lebih tentang
proyek melalui 3 cara:
a) Focus group: klien dan pengguna memberi masukan terhadap software
b) Formal Technique Reviews: Tim ASD lengkap melakukan review
c) Postmortems: Tim ASD lakukan instrospeksi pada kinerja dan proses.

Proses Adaptive Software Development (ASD)

3. Dynamic Systems Development Method (DSDM)

Dynamic System Development Method (DSDM) adalah suatu kerangka dalam pengembangan suatu
project, terutama digunakan untuk metode pengembangan perangkat lunak.

DSDM merupakan iteratif dan incremental pendekatan yang mencakup prinsip-prinsip pembangunan
Agile, termasuk keterlibatan pengguna atau pelanggan secara terus-menerus, intinya DSDM suatu
metode yang mendekati Incremental dan Agile Alliance.

Dynamic System Development Method menyajikan kerangka kerja (framework) untuk membangun
dan memelihara sistem dalam waktu yang terbatas melalui penggunaan prototip yang incremental
dalam lingkungan yang terkondisikan.
Metode ini bisa membuat pengerjaan software lebih cepat 80%.Hal -hal yang perlu diperhatikan jika
menggunakan dynamic system development method:

a. Feasibility study, siapkan requirement, dan batasan, lalu uji apakah sesuai gunakan proses
DSDM.
b. Business Study, susun kebutuhan fungsional dan informasi, tentukan arsitektur aplikasi dan
identifikasi kebutuhan pemeliharaan untuk aplikasi.
c. Functional model iteration, perlihatkan fungsi perangkat lunak ke klien untuk
mendapatkan feedback.
d. Design and Build Iteration, cek ulang prototip yang dibangun dan pastikan bahwa prototip
dibangun dengan cara yang memungkinkan fungsi tersebut benar-benar bekerja.
e. Implementation: buat perangkat lunak sesuai protoip yang ada dan terus
tambah fungsionalitasnya.

Beberapa karakteristik DSDM yaitu sebagai berikut :

a. Menyajikan kerangka kerja (Framework) untuk membangun dan memelihara sistem dalam
waktu yang terbatas melalui penggunaan prototyping yang incremental dalam lingkungan
yang terkondisikan.
b. Membangun software dengan cepaSt yaitu 80% dari proyek diserahkan dalam 20% dari waktu
total untuk menyerahkan proyek secara utuh.
c. Aktifitas Feasibility Study yaitu dengan requirement, lalu uji apakah sesuai gunakan proses
DSDM
d. Aktifitas Business Study yaitu susunam kebutuhan fungsional dan informasi, menentukan
arsitektur aplikasi dan identifikasi kebutuhan pemeliharaan untuk aplikasi.
e. Aktifitas Functional model iteration yaitu menghasilkan incremental prototype yang
perlihatkan fungsi software ke client untuk dapatkan kebutuhan lebih jelas dan konfirmasi.
f. Aktifitas Design and Build Iteration yaitu melakukan cek ulang prototype yang di bangun untuk
memastikan bahwa prototype yang di bangun dengan cara tersebut memungkinkan semua
fungsi benar-benar bekerja.
g. Aktifitas Implementation yaitu menempatkan software pada lingkungan sebenarnya
sekalipun belum lengkap atau masih ada perubahan.
h. DSDM dapat dikombinasikan dengan XP yang menghasilkan kombinasi model proses
mengikuti metode DSDM dan praktek yang sejalan dengan XP.
i. Telah di jelaskan beberapa karakteristik DSDM, pada tujuannya untuk menciptakan suatu
rangkaian RPL yang cepat sama hal nya dengan XP model.

Proses Dynamic Systems Development Method (DSDM)

4. Scrum Methodology

Salah satu metode agile yang paling banyak digunakan adalah scrum, scrum pertama kali
diperkenalkan oleh Takeuchi dan Nonaka yang menggunakan nya untuk menjelaskan inovasi dalam
sebuah pendekatan pengembangan produk yang mengambil filosofi dari pelatihan olahraga rugby.

Scrum berbeda dengan SDLC tradisional seperti waterfall, perbedaan itu dapat dilihat dari segi
pembagian roles, meeting yang dilakukan juga bagaimana proses pembuatan product berlangsung.
Pada scrum proses development suatu sistem tidak sama dengan yang dilakukan oleh framework
tradisional seperti waterfall dimana setiap proses akan sangat bergantung pada proses lainnya
sehingga bila ada suatu proses yang terhambat maka akan sangat mengganggu dan dapat membawa
kepada kegagalan proyek.

Pada Scrum pembagian roles dibagi menjadi tiga yaitu product owner, scrum master, dan scrum team
(Mahalaksmi & Sundararajan, 2013).

a. Product Owner disini adalah wakil dari pelanggan yang kita miliki dimana product owner
adalah tempat keputusan terakhir terkait product yang akan dibuat baik dari pengaturan
bagaimana fitur yang akan disediakan, kapan product akan di release dan apa konten apa saja
yang disediakan, product owner pun harus mengurus product backlog dimana product
backlog dapat diubah oleh product owner bila dirasa ada yang lebih prioritas. Product owner
pun harus bertanggung jawab terkait dengan keuntungan dari pada product yang akan dibuat.
b. Scrum master bertugas untuk membantu anggota tim dan bertanggung jawab untuk
menyelesaikan semua halangan yang dihadapi saat membuat product. Scrum master juga
bertanggung jawab dalam pelaksanaan daily scrum baik dari kapan dan bagaimana meeting
akan berlangsung, selain itu scum master pun harus bisa membuat tim fokus kepada proyek
pembuatan produk dan tidak teralihkan kepada hal lain.Untuk menjadi seorang scrum master
dibutuhkan kepemimpinan yang hebat dan juga kemampuan yang hebat sehingga tim dapat
mempercayai mereka.
c. Scrum team bisa dipastikan adalah kumpulan dari orang yang bertanggung jawab dalam
membuat product baik itu seorang programmer, tester, designer dan lainnya yang terkait
dalam pembuatn product.

Biasanya scrum team dibentuk dari 5-10 orang. Team juga dibentuk dalam dua nilai yaitu untuk self-
organizing dan juga cross-functional.
Nilai self-organizing disini adalah bagaimana mengatur karakter-karakter dari tiap anggota team
sehingga team tidak hanya dikendalikan oleh satu orang yang sangat berpengaruh, team akan selalu
bekerja layaknya perusahaan start-up yang mau mengambil inisiatif dan resiko, tim membentuk
konsep yang dimengerti oleh mereka.

Self-organizing ini akan bisa terjadi dengan adanya tiga kondisi yaitu otonomi mereka untuk bekerja
yang tidak akan diganggu oleh top-management, self-transcendence dimana tim akan mengambil
resiko untuk membuat sistem yang lebih baik lagi melewati dari ekspektasi top-management
walaupun akan menimbulkan perdebatan seperti yang pernah terjadi pada tim projek honda, dan
kondisi yang terakhir adalah cross-fertilization adalah kondisi dimana tim dibuat dengan berbagai
macam background sehingga pemikiran akan semakin kaya dan setiap orang akan mendapatkan
masukan yang berbeda untuk membangun pengetahuan mereka akan proyek dari berbagai sudut
pandang (Takeuchi & Nonaka, 1986).

Dikarenakan keberagaman background maka setiap tim akan mendapatkan informasi dari berbagai
bentuk sehingga fungsi mereka tidak hanya satu saja untuk seorang programmer tidak melulu hanya
memikirkan tentang program tetapi bisa juga dia menjadi pemberi ide mengenai pasar yang ada ini
lah yang disebut nilai cross-functional.

Cara Kerja SCRUM

Gambar diatas adalah bagaimana proses dari bagaimana framework scrum akan dilakukan.

Awalnya dimana product owner akan memulainya dengan mengkonversi segala keinginan dari
pelanggan menjadi product backlog dimana product backlog adalah segala list terkait dengan
keberhasilan proyek, dalam pengembangan software bisa dalam bentuk fitur ataupun bagaimana
arsitektur sistem yang akan dibuat.

Lalu product backlog itu akan dibawa kepada sprint planning meeting yang akan didatangi oleh semua
team agar dapat memberikan pengetahuan kepada semua anggota team bagaimana sistem yang akan
dibuat sehingga dari situ akan dibuatlah sprint backlog yaitu apa saja yang akan dilakukan agar
pengembangan dapat berhasil.

Setelah sprint backlog dibuat maka akan dilakukan lah sprint yaitu proses pengembangan atau
pembuatan sistem yang biasanya berlangsung selama 1-4 minggu, saat proses sprint tidak boleh ada
gangguan dari luar, yang dilakukan oleh team adalah tetap mengikuti dari sprint backlog yang sudah
dibuat.

Selama pelaksanaan sprint diadakan daily scrum yaitu pertemuan yang dihadiri oleh semua anggota
team untuk sharing masalah apa saja yang mereka hadapi saat pengembangan kemarin. Saat jangka
waktu pelaksanaan suatu sprint selesai maka akan dilaksanakan review yang dimana menunjukan fitur
apa saja yang sudah diselesaikan pada proses sprint yang sudah dilakukan.

Lalu akan dilakukan lagi proses sprint dengan sprint backlog yang berbeda hingga semua product
backlog dapat dipenuhi semuanya, saat team merasa product backlog dapat di refinemenet atau
dievolusi maka team dapat melakukannya saat proses sprint.

Saat semua product backlog semuanya terpenuhi maka akan dilaksanakan retrospective yang beguna
untuk mereview secara keseluruhan kinerja dari project owner, scrum master dan juga team yang
nantinya akan digunakan sebagai feedback agar proyek selanjutnya dapat lebih baik lagi.

Perlu diingat juga walaupun diberikan kebebasan pada team tetapi management tetap juga memiliki
beberapa control (Takeuchi & Nonaka, 1986) yaitu:

a. Memilih orang yang akan masuk ke dalam tim atau proyek dan juga memonitpring team
tersebut juga menambahkan dan mengurangi jumlah anggota team bila dirasa perlu.
b. Membuat suasana kerja yang terbuka
c. Meyakinkan para developer ataupun engineers untuk mendengarkan secara langsung
bagaimana keinginan dari pelanggan mereka.
d. Mengevaluasi serta memberikan penghargaan berdasarkan performa team
e. Mengatur bagaimana ritme yang ada pada proses pengembangan
f. Mentoleransi dan juga mengantisipasi kesalahan
g. Bila menggunakan supplier maka management pun akan meyakinkan supplier agar menjadi
h. self-organizing. Mengikutkan mereka dalam proyek juga merupakan langkah yang tepat

Ada lima nilai yang perlu diperhatikan agar scrum framework ini dapat berhasil diimplementasikan
pada suatu proyek yaitu fokus, keberanian, keterbukaan, komitmen dan respect (Jeldi & Chavali,
2013). Setiap nilai ini harus dimiliki oleh setiap orang yang berada pada team baik dari project owner,
scrum master dan juga scrum team.

Dalam menggunakan scrum kita pun harus mencocokan apakah proyek yang kita jalani cocok atau
tidak untuk mengimplementasikan scrum dikarenakan scrum juga memiliki beberapa kelemahan yaitu
scrum sangat kurang dalam hal dokumentasi sehingga kita harus memastikan apakah dokumentasi
proyek sangat berpengaruh pada proyek anda atau tidak (Mahalaksmi & Sundararajan, 2013). Selain
itu kerjasama tim sangat dibutuhkan dalam menggunakan scrum sehingga bila kerjasama team kurang
dan dedikasi untuk mengerjakan proyek kurang maka proyek akan bisa menemui kegagalan.

5. Crystal

Alistair Cockburn dan Jim Highsmith menciptakan keluarga Crystal agile methods15 untuk mencapai
pendekatan pengembangan perangkat lunak yang menempatkan premium pada "manuver" selama
apa yang dikarakterisasi Cockburn sebagai "seorang resourcelimited, permainan kooperatif
penemuan dan komunikasi, dengan tujuan utama memberikan perangkat lunak yang bermanfaat dan
berfungsi serta tujuan sekunder untuk menyiapkan yang berikutnya permainan ”Untuk mencapai
kemampuan manuver, Cockburn dan Highsmith telah mendefinisikan satu set metodologi, masing-
masing dengan unsur-unsur inti yang umum untuk semua, dan peran, proses pola, produk kerja, dan
praktik yang unik untuk masing-masing. Keluarga Crystal adalah sebenarnya satu set contoh proses
tangkas yang telah terbukti efektif untuk berbeda jenis proyek. Tujuannya adalah untuk
memungkinkan tim gesit untuk memilih anggota keluarga kristal yang paling sesuai untuk proyek dan
lingkungan mereka.

6. Feature Driven Development (FDD)

Feature Driven Development (FDD) merupakan proses yang didesain dan dilaksanakan untuk
menyajikan hasil kerja secara berulang-ulang dalam waktu tertentu dan dapat diukur.

FDD merupakan pendekatan yang mengacu pada pembuatan sistem menggunakan metode yang
mudah dimengerti dan diimplementasikan, teknik problem solving, dan pelaporan yang mudah
dimengerti dan dikontrol oleh stakeholders.

Dengan metode FDD, tim pengembang diberikan informasi yang cukup dan alat bantu untuk
menyelesaikan proyek. Pemimpin proyek dan manajer diberikan informasi berdasarkan waktu
mengenai tim dan proyek yang sedang berjalan untuk menghindari risiko yang terjadi. Pelaporan
menjadi lebih mudah, tidak membebani, periodik, dan akurat.

Pengguna juga dapat secara langsung melihat bagian mereka sebagai hasil progress proyek dan
memberikan feedback dalam tahap pengembangan yang bertujuan untuk menciptakan sistem sesuai
keinginan klien.

Terdapat lima kelebihan yang dimiliki oleh metode Feature Driven Development yang menjadi nilai
tambah bagi para pengembang sistem saat mengerjakan proyeknya. Kelebihan Feature Driven
Development antara lain :

a. Tangible results rather than process pride.

Proses dalam metode FDD mengutamakan sesuatu yang dapat diukur ketimbang proses-proses
perancangan yang rumit dan menghabiskan waktu, sumber daya, dan biaya. Pada saat merancang
proyek, penjadwalan langsung diarahkan ke dalam bentuk fitur.

b. A system for building system is necessary.

Sistem yang dibangun harus rapi dan kuat agar para pengembang dapat bekerja dan menghasilkan
sebuah
sistem yang diharapkan oleh klien.

c. Simple is better.

Perancangan dibuat sesederhana mungkin, tetapi dapat memenuhi semua persyaratan yang
diberikan oleh klien sehingga mereka mendapatkan gambaran sistem dengan mudah.

d. Process steps should be obviously valuable to each team member.

Setiap langkah atau proses selama pengembangan sistem harus dapat dinilai dan terukur bagi
para pengembang sistem. Selain itu, desain kode juga menjadi lebih mudah dan efektif pada saat
pemeriksaan.

e. Good processes move to the background.

 Semua proses lebih baik dikerjakan di belakang sehingga pengerjaan dengan metode FDD
terlihat lebih sederhana.

Beberapa kekurangan yang dimiliki oleh metode Feature Driven Development yang diperoleh dari
hasil studi analitik adalah sebagai berikut.

a. Membutuhkan jumlah pekerja yang banyak (10-250 orang) yang dibagi ke dalam beberapa
divisi. Semakin banyak pekerja, biaya yang dikeluarkan semakin tinggi.
b. Lebih menekankan pengembang dengan keterampilan tinggi dan sulit untuk mencari
pengembang dengan kriteria tersebut.
c. Dalam FDD terdapat class owner yang menangani setiap fitur. Masalahnya adalah ketika fitur
A memiliki dependensi terhadap fitur B dan fitur B mengalami perubahan, fitur A harus
menunggu kepastian dari fitur B yang menyebabkan mundurnya jadwal proyek.
d. Pada intinya, FDD bersifat individual, maka dapat terjadi saling tunggu antar fitur yang terkait.
FDD membatasi penambahan fitur kurang dari 10% dari total waktu, biaya, dan kualitas.
Perubahan fitur hanya dilakukan pada sebuah proses dan keterlibatan klien hanya pada
beberapa tahapan.
e. Jumlah jam kerja FDD tidak terikat sehingga dapat menyebabkan para pengembang tidak
bekerja secara optimal di pertengahan, tetapi pada akhir jadwal mereka akan bekerja lebih
ekstra.

Cara Kerja FDD

Cara kerja FDD dapat digambarkan melalui studi kasus terkait bagaimana cara membangun sebuah
website review dengan metode FDD. Berikut adalah studi kasusnya, seorang klien berencana akan
membangun sebuah perusahaan yang bergerak di bidang review produk elektronik (gadget) dan
karena era internet yang sudah menjamur, klien tersebut ingin usahanya juga bergerak melalui online.

Terpikirlah untuk menciptakan sebuah website review. Akhirnya klien ini mencari sebuah perusahaan
profesional untuk dibuatkan sebuah website review. Setelah berkonsultasi dengan kepala projek,
dihasilkan beberapa ide atau kebutuhan yang diperlukan klien pada website reviewnya antara lain
klien bersedia mengeluarkan budget yang besar, tetapi kualitas yang dihasilkan harus istimewa dan
interaktif. Waktu yang disepakati untuk menyelesaikan proyek ini oleh pihak pengembang adalah dua
bulan.

Singkat cerita, sang pemimpin projek mengambil kesimpulan bahwa mereka akan menggunakan
metode FDD dalam projek kali ini sebab klien meminta untuk menciptakan sebuah website yang
interaktif atau kaya dengan feature. Langkah paling awal, sang pemimpin akan membagi anggotanya
ke dalam beberapa kelompok (grup) dalam hal pembagian tugas pelaksaan projek ini. Pada projek ini
mereka akan bekerja dengan keseluruhan anggota berjumlah enam orang termasuk pemimpin
proyek. Mereka semua dalam kelompok besar akan dikumpulkan bersama untuk membahas cara kerja
mereka menggunakan metode FDD.

Oleh karena itu, mereka semua akan menjalani beberapa tahap berikut ini:

a. Develop an Overall Model Phase

Pada tahap awal ini, seluruh anggota pengembang wajib sudah mengetahui dasar dan cara
pengembangan dengan agile process khususnya dengan metode FDD. Kemudian mereka diminta
untuk setiap grup memikirkan, merancang, dan mengajukan apa saja yang mereka harapkan dan
perlukan dalam membuat sebuah website review yang baik.
Setelah semua hasil dikumpulkan, maka mereka akan menggabungkan semuanya itu ke dalam sebuah
gambaran secara garis besar yang mencakup atau menggambarkan keseluruhan sistem yang akan
mereka kembangkan. Biasanya mereka dapat menggunakan tools yang tersedia baik online atau
offline untuk membuat sebuah diagram tentang keseluruhan proses mereka.

Diagram yang biasa diperlukan di sini adalah Use Case Diagram.

Berdasarkan Use Case yang sudah dibuat itulah yang akan dicapai dalam tahap pertama ini (developt
an overall) di mana semua hal yang akan dikembangkan akan disatukan dan membentuk sebuah
perencanaan yang matang secara garis besar.

b. Build a Feature List

Feature list adalah apa yang dilihat klien untuk validitas dan kelengkapan sistem. Fitur dalam langkah
ini berbasis customer bukan teknologi. Bahasa yang digunakan sesederhana mungkin agar klien
paham. Pada tahap selanjutnya setelah menentukan keseluruhan rangkaian sistem, kini para
pengembang harus mengidentifikasi fitur-fitur apa saja yang dapat di jadikan list pada setiap modul
yang dihasilkan. Pada kasus ini sitem memiliki modul “Tampilan Website”.

Jika dijabarkan modul ini memiliki beberapa feature seperti Login, View Profile, Edit Profile, Logout,
List Review, Update Review, Delete Review, Create Page Delete Page. Pada tahap ini pemimpin proyek
(kepala) menargetkan untuk menghasilkan minimal 25 feature untuk projek ini. Tahap ini bias
diimplementasikan juga dengan menggunakan Use Case Diagram. Pembuatan Use Case bisa dilakukan
dengan menggunakan software seperti tahap pertama atau penulisan secara manual (tulisan tangan).

Use case pada taha ini merupakan hal-hal apa saja yang akan dikerjakan dan dikembangkan oleh
kelompok dan menjelaskan apa saja feature yang akan dikembangkan pada setiap modul.

Hasil ini merupakan penjabaran yang dilakukan oleh setiap kelompok sesuai dengan modul yang
mereka kembangkan.

c. Plan by Features

Pada tahap ketiga ini merupakan tahap yang paling penting karena semua perencanaan
pengembangan harus ditentukan di sini. Semua kelompok harus membuat dokumentasi terhadap apa
saja yang telah mereka buat dalam modul. Setiap modul harus ditentukan waktu yang dibutuhkan
menyelesaikannya dengan penjabaran masing- masing feature.

Pemimpin projek akan mengumpulkan semua estimasi dari masing-masing kelompok dan kemudian
akan membuat sebuah list atau agenda waktu secara keseluruhan. Hal itu dapat dilakukan dengan
menggunakan gantt chart atau mind maps atau keduanya. Fungsi dibuatnya gantt chart dan
mindmaps adalah untuk membantu para pengembang melihat keseluruhan progres yang telah
berjalan lebih baik

Gantt chart dan mind maps akan membantu para pengembang lebih mudah untuk mengetahui tugas
mereka masing masing. Setiap modul digambarkan dengan jelas beserta fitur-fitur yang dibutuhkan.

d. Design by Features

Setiap fitur dibuatkan sequence diagram dan class diagram untuk menunjukkan kepada klien
bagaimana sebuah sistem bekerja sehingga jika ada kebingungan dan ketidaksetujuan dapat
ditanggung
para pengembang pada awal pengerjaan sistem.

e. Build by Feature

Pada akhir tahapan FDD, pengembang membangun sistem yang sudah dirancang dengan
menggunakan bahasa pemrograman dan tools yang sesuai. Mereka juga membuat user interface dari
system tersebut dan membangun server.

7. Agile Modeling (AM)

Agile Modeling adalah suatu metodologi yang praktis untuk proses dokumentasi dan pemodelan
sistem perangkat lunak. Agile Modeling sendiri adalah kumpulan nilai-nilai, prinsip dan praktek-
praktek untuk memodelkan perangkat lunak agar dapat diaplikasian pada proyek pengembangan
perangkat lunak secara efektif dan efisien.

Prinsip dalam Agile Modeling antara lain :

a. Membuat model dengan tujuan: tentukan tujuan sebelum membuat model

b. Mengunakan multiple models: tiap model mewakili aspek yang berbeda dari model lain.
c. Travel light: simpan model-model yang bersifat jangka panjang saja
d. Isi lebih penting dari pada penampilan: modeling menyajikan informasi kepada audiens
yang tepat.
e. Memahami model dan alat yang yang digunakan untuk membuat software
f. Adaptasi secara lokal

Dengan menggunakan Agile Modeling, diharapkan tim pengembang (developer) dapat fokus pada
prinsip dan praktek pemodelan yang efektif.

Gambar Hubungan antara model, dokumen, source code, dan dokumentasi dalam Agile Modelling
Dari sudut pandang agile modeling, dokumen adalah segala sesuatu yang bersifat eksternal dari
source code yang tujuannya adalah untuk menyampaikan informasi secara persisten. Ini berbeda dari
konsep model, yang merupakan abstraksi yang menggambarkan satu atau lebih aspek dari masalah
atau solusi potensial dalam mengatasi masalah.

Beberapa model akan menjadi dokumen, meskipun lebih banyak yang akan dibuang begitu telah
terpenuhi. Beberapa model akan digunakan untuk mendorong pengembangan source code, meskipun
beberapa model mungkin hanya digunakan untuk mendorong pengembangan model lainnya.

Source code adalah urutan instruksi, termasuk komentar yang menggambarkan instruksi tersebut,
untuk sistem komputer.

Meskipun source code jelas sebuah abstraksi, meskipun yang rinci, dalam lingkup agile modelingtidak
akan dianggap sebagai model karena akan dibedakan dari konsepnya. Jadi dokumentasi meliputi
dokumen dan komentar dalam source code (Ambler S. , 2002).

Eelco Gravendeel menyatakan bahwa hanya ada dua jenis dokumentasi dalam Agile (Hazrati, 2009),
yaitu :

1. Dokumen yang diperlukan untuk semua anggota tim untuk bekerja pada proyek

Dalam dunia yang ideal, tim ini merelokasi dan semua pengetahuan akan dibagi dan diserahkan
dengan komunikasi langsung. Namun, jika tim didistribusikan dan pengetahuan harus ditransfer
kemudian menulis dokumen dan melengkapi dengan panggilan audio visual akan sangat berguna.
Satu set dokumen minimal yang umum juga dibutuhkan oleh tim untuk berbicara bahasa macam-
macam dan berada di level yang sama pemahaman. Eelco menyatakan bahwa banyak dokumen,
yang dibuat untuk mendukung penciptaan produk, panggilan untuk perhatian lebih karena
mereka dibuang segera setelah proyek selesai.

2. Dokumentasi untuk dikirim dengan produk akhir.

Dokumen ini merupakan bagian dari pengiriman produk dan kelanjutan hubungan dengan klien
yang baik. Contoh umum termasuk:

o User manual
o Deployment manual
o Pemeliharaan manual (ditujukan untuk mengoperasikan perangkat lunak)
o Teknis dokumentasi (ditujukan untuk menjaga basis kode), dll
Gambar UML statechart yang menggambarkan siklus hidup agile modeling

Pada Gambar diatas dapat disimpulkan bahwa model tidak selalu dokumen. Banyak model bersifat
sementara. Selain itu, dokumen tidak selalu model. Misalnya: kita tidak akan mempertimbangkan
manual untuk menjadi model. Hal ini penting karena banyak orang percaya sebaliknya. Ketika mereka
mendengar kata “model” mereka secara otomatis menerjemahkan ke “dokumen” dan semua konotasi
negatif (meskipun jarang yang positif).

Konsep “model” dan "dokumen"adalah ortogonal karenakitajelas dapat memiliki satu tanpa yang
lainnya.Penerimaan dari ide ini adalah langkah penting menuju menjadi lebih agile.

Kebutuhan Untuk Dokumentasi

Para pengembang agile mengakui bahwa dokumentasi merupakan bagian intrinsik dari sistem
apapun. Ada 4 alasan yang sah untuk membuat dokumentasi (Ambler S. , 2002):

1. Stakeholder proyek atau pemilik produk memerlukannya.

Penciptaan dokumentasi merupakan sebuah keputusan bisnis yang fundamental, bukan pada hal
teknis. Para pengembang perangkat lunak berinvestasi sumber daya dari stakeholder proyek
dalam pengembangan dokumentasi, karena itu, mereka harus memiliki kata terakhir mengenai
apakah uang mereka akan dikeluarkan atau tidak. Jika stakeholder proyek meminta dokumentasi
dari pihak pengembang, mungkin pada saran pihak pengambang itu sendiri, dan memahami trade-
off yang terlibat, maka pihak pengembang harus membuat dokumen.

2. Untuk menentukan model kontrak.

Kontrak merupakan persetujuan antara dua pihak yang tertulis dan dilaksanakan oleh hukum.
Model Kontrak menentukan bagaimana sistem yang dikembangkan dan sistem eksternal
berinteraksi satu sama lain(Jakob dkk, 2008). Beberapa interaksi dua arah, sedangkan yang lain
adalah uni-directional, membuat interaksi secara eksplisit untuk semua orang yang terlibat. Model
Kontrak sering diperlukan bila kelompok eksternal mengontrol sumber informasi bahwa sistem
yang dikembangkan membutuhkan, seperti database, aplikasi warisan, atau layanan informasi.

3. Untuk mendukung komunikasi dengan anggota tim pada tempat yang berbeda.

Pengembang dalam tanggung jawabnya harus mengkomunikasikan requirements (Josef, 2007).

Tidak mungkin untuk bekerja sama dengan tim pengembangan dan stakeholder proyek (atau
setidaknya yang dibutuhkan pada saat itu) ada setiap saat. Bila pengembang perlu untuk bekerja
dengan tim yang memiliki lokasi yang berbeda, pengembang perlu menemukan cara untuk
berkomunikasi dengan mereka, dan dokumentasi sering menjadi bagian dari solusi(Fricker dkk,
2007).

Untuk menggunakan dokumentasi sebagai sarana utama komunikasi adalah sebuah kesalahan
sebab terlalu mudah untuk terjadi kesalahpahaman tentang sesuatu yang telah ditulis, namun
merupakan mekanisme pendukung yang baik. Cara yang baik untuk berpikir dokumentasi dalam
situasi ini adalah bahwa hal itu merupakan pilihan terakhir.
 4. Untuk memikirkan sesuatu yang lebih.

Banyak orang akan menulis dokumentasi untuk meningkatkan pemahaman mereka sendiri.
Menulis, menempatkan ide-ide di atas kertas, dapat membantu anggota tim untuk memperkuat
tim dan menemukan masalah dengan pemikirannya. Apa yang tampak jelas dalam pikiran sering
menjadi sangat rumit setelah dicoba untuk menggambarkan secara rinci. Untuk itu, disarankan
bahwa orang menulis komentar sebelum mereka menulis kode mereka.

Hal di atas tentu sangat berbeda dengan alasan yang selama ini digunakan untuk pembuatan
dokumentasi. Developer sering dipaksa untuk membuat dokumentasi dengan tujuan yang tidak jelas
demi untuk kepentingan politik, dan dokumen seperti ini biasanya dianggap sebagai dokumen yang
tidak efektif karena hanya akan membuang waktu, tenaga dan biaya.

Adapun alasan-alasan yang tidak jelas untuk pembuatan dokumentasi serta cara untuk mengatasinya
adalah sebagai berikut(Ambler S. W., 2001):

1. Pemohon ingin dilihat berada dalam kontrol.

Orang akan meminta dokumen, seperti spesifikasi dan dokumen arsitektur secara rinci agar
mereka dapat menandatanganinya dan berkata. Setiap kali menemukan hal seperti dalam situasi
ini maka katakan kepada invidu yang meminta dokumen tadi apakah mereka ingin dilihat sebagai
orang bertanggung jawab atas kegagalan proyek karena tim pengembangan terlalu sibuk berfokus
pada dokumentasi yang tidak perlu dan tidak pada perangkat lunak yang sedang dibangun. Saya
kemudian akan menyarankan bahwa alih-alih meminta dokumentasi mereka malah harus
meminta akses ke perangkat lunak itu sendiri, bahkan jika itu hanya sebuah rilis internal perangkat
lunak, sehingga mereka dapat memberikan umpan balik konstruktif tentang hal itu. Mereka masih
dapat dilihat untuk menjadi peserta aktif dalam proyek dan dapat melakukannya dengan cara
yang produktif.

2. Pemohon keliru berpikir bahwa dokumentasi ada hubungannya dengan keberhasilan proyek.
3. Pemohon ingin membenarkan keberadaan mereka.

Ini biasanya terjadi ketika seseorang dalam organisasi yang tidak berguna lagi sangat ingin terlihat
melakukan sesuatu. Hal ini merupakan bahaya yang terselubung karena pemohon sering memiliki
sesuatu yang tampak pada permukaan untuk menjadi alasan yang baik untuk meminta
dokumentasi, ini merupakan sesuatu yang telah mereka lakukan selama bertahun-tahun, dan
manajemen sering berpendapat itu perlu. Untuk mengatasi masalah ini maka minta kepada
pemohon apakah yang mereka inginkan dengan adanya dokumen, mengapa mereka
memerlukannya, mengapa dengan penciptaan dokumentasi bagi mereka adalah lebih penting
daripada pekerjaan lain, dan sebagainya untuk mencoba menentukan yang sebenarnya nilai apa
yang mereka lakukan. Ini adalah pertanyaan yang valid untuk bertanya, meskipun yang tidak
nyaman bagi seseorang yang tidak menambah nilai lebih kepada upaya pembangunan.

4. Pemohon tidak mengetahui yang lebih baik.

Banyak orang telah bekerja dalam organisasi yang telah mengikuti proses non-agile selama
bertahun-tahun, proses yang berpusat pada dokumentasi, proses yang menghasilkan banyak
dokumen untuk diperiksa dan akhirnya akan menghasilkan perangkat lunak. Hal ini yang terbiasa
mereka lakukan sehingga mereka akan hanya meminta pengembang untuk sesuatu yang mereka
sudah dapatkan di masa lalu. Gagasan bahwa pengembang dapat menghasilkan perangkat lunak
 di awal proyek, bahwa itu merupakan tujuan utama, adalah hal yang baru dan sering menjadi hal
yang radikal bagi banyak orang.

5. Prosesnya yang mengatakan untuk membuat dokumen.

Meskipun bukan merupakan permasalahan dengan proses perangkat lunak agile, tapi hal seperti
itu pasti dapat disatukan dengan proses perangkat lunak yang preskriptif. Alasan paling umum
untuk masalah ini termasuk orang yang ingin membenarkan keberadaan mereka (lihat di atas),
orang tidak memahami proses pengembangan perangkat lunak atau setidaknya implikasi dari apa
yang mereka minta, dan situasi di mana tujuan utamanya adalah untuk mendapatkan bayaran
untuk per jamnya sebagai lawan untuk mengembangkan perangkat lunak secara efektif. Strategi
terbaik untuk mengatasi masalah ini adalah untuk menyelidiki apakah penciptaan dokumen
benar-benar memberikan nilai pada usaha yang dilakukan.

6. Seseorang ingin kepastian bahwa semuanya baik-baik saja.

Stakeholder proyek menginvestasikan sumber daya yang penting dalam tim proyek, mereka
mengambil risiko pada developer, dan mereka ingin tahu bahwa investasi mereka sedang
dibelanjakan dengan baik. Untuk mendapatkan kepastian ini mereka akan meminta adanya
dokumentasi, laporan status atau mungkin dokumen secaramenyeluruh, mereka tidak memahami
bahwa perlu mengambil waktu untuk melakukannya dan hal itu jauh dari tujuan sejati yakni
mengembangkan perangkat lunak.Dan mereka tidak menyadari bahwa permintaan yang lebih
baik adalah melihat perangkat lunak itu sendiri (seperti yang ditunjukkan sebelumnya, mereka
tidak tahu lebih baik). Developer harus mengenali kapan hal seperti ini terjadi, yaknijika pada awal
proyek mereka tidak percaya tim pengembang, dan mencari cara alternatif untuk memberikan
jaminan itu.

7. Anggota tim bekerja dengan tim yang lain.

Meskipun telah diidentifikasi Agile Modeling sepertinya tidak tepat dalam situasi ini. Dokumentasi
adalah salah satu cara untuk berkomunikasi tetapi bukan cara terbaik. Sebaiknya temukan
pendekatan alternatif, seperti pertemuan sesekali dengan kelompok lain atau penggunaan alat-
alat kolaboratif, untuk mengurangi ketergantungan tim pada dokumentasi.

8. Dokumen kontrak pengembangan yang secara rutin digunakan kembali untuk kompetisi.

Masalah ini sering terjadi di perusahaan yang bekerja untuk instansi pemerintah, meskipun
perusahaan tersebut mengancam kontraktor mereka dengan menempatkan proyek untuk
tawaran lagi jika mereka tidak melakukannya. Jika tujuan utamanya adalah untuk
mengembangkan perangkat lunak maka seharusnya pengembang fokus untuk melakukannya dan
pengembang lebih mungkin untuk melakukan hal secukupnya untukpembuatan kontrak. Klien
langsung dalam situasi ini sering beroperasi di bawah keyakinan yang sesat bahwa jika
pengembang tidak melakukannya maka mereka dapat mengambil dokumentasi yang dibuat dan
memberikan kepada kontraktor berikutnya yang akan mulai dari apa yang telah dikerjakan oleh
pengembang sebelumnya. Hal ini berbatasan delusi menurut saya. Tapitidak peduli bagaimana
pengembang melihatnya, kontraktor berikutnya sangat tidak mungkin untuk mengambil
keuntungan dari dokumentasi yang dihasilkan tadi.

Pengembang Agile mengakui bahwa dokumentasi yang efektif adalah tindakan penyeimbangan,
tujuannya adalah untuk hanya memiliki dokumentasi yang cukup pada waktu yang tepat dan hanya
untuk audiens yang tepat dan juga merupakan tanggung jawab dari pengembang agile dalam hal ini
adalah business analyst untuk melakukan dokumentasi (Josef, 2007).

8. Rational Unified Process

3.2.7 ADDIE
Model ADDIE adalah proses generik yang secara tradisional digunakan oleh desainer instruksional dan
pengembang pelatihan. Kelima fase — Analisis, Desain, Pengembangan, Implementasi, dan Evaluasi
— merupakan pedoman yang dinamis dan fleksibel untuk membangun pelatihan yang efektif dan alat
pendukung kinerja. Sementara mungkin model desain yang paling umum, ada sejumlah kelemahan
pada model ADDIE yang telah menyebabkan sejumlah spin-off atau variasi.

Ini adalah model Instructional Systems Design (ISD). Sebagian besar model desain instruksional saat
ini adalah spin-off atau variasi model ADDIE; model lain termasuk model Dick & Carey dan Kemp ISD.
Salah satu peningkatan yang diterima secara umum pada model ini adalah penggunaan prototipe
cepat. Ini adalah gagasan menerima umpan balik kontinu atau formatif sementara materi instruksional
sedang dibuat. Model ini berupaya menghemat waktu dan uang dengan menangkap masalah saat
mereka masih mudah diperbaiki.

Teori instruksional juga memainkan peran penting dalam desain bahan ajar. Teori-teori seperti
behaviorisme, konstruktivisme, pembelajaran sosial dan kognitivisme membantu membentuk dan
menentukan hasil dari bahan ajar.

Dalam model ADDIE, setiap langkah memiliki hasil yang dimasukkan ke langkah berikutnya.

c. Tahap Analisis
Dalam tahap analisis, masalah pembelajaran diklarifikasi, tujuan dan sasaran instruksional ditetapkan
dan lingkungan belajar serta pengetahuan dan keterampilan yang sudah ada dari para siswa
diidentifikasi. Di bawah ini adalah beberapa pertanyaan yang dibahas selama fase analisis:

- Siapa audiens dan karakteristik mereka?

- Identifikasi hasil perilaku baru?
- Apa jenis kendala pembelajaran yang ada?
- Apa saja opsi pengirimannya?
- Apa pertimbangan pedagogis online?
 - Apa jadwal waktu untuk penyelesaian proyek?

d. Tahap Desain
Fase desain berhubungan dengan tujuan pembelajaran, instrumen penilaian, latihan, konten, analisis
subjek, perencanaan pelajaran dan pemilihan media. Fase desain harus sistematis dan spesifik.
Sistematis berarti metode yang logis dan teratur untuk mengidentifikasi, mengembangkan, dan
mengevaluasi serangkaian strategi terencana yang ditargetkan untuk mencapai tujuan proyek.
Spesifik berarti setiap elemen dari rencana desain instruksional perlu dilaksanakan dengan
memperhatikan detail. Ini adalah langkah-langkah yang digunakan untuk fase desain:

- Dokumentasi strategi desain instruksional, visual, dan teknis proyek

- Terapkan strategi instruksional sesuai dengan hasil perilaku yang diinginkan oleh domain
(kognitif, afektif, psikomotor).
- Buat storyboard
- Desain antarmuka pengguna dan pengalaman pengguna
- Pembuatan prototipe
- Terapkan desain visual (desain grafis)

e. Tahap Pengembangan

Tahap pengembangan adalah tempat pengembang membuat dan merakit aset konten yang dibuat
dalam fase desain. Programmer bekerja untuk mengembangkan dan / atau mengintegrasikan
teknologi. Penguji melakukan prosedur debugging. Proyek ini ditinjau dan direvisi sesuai dengan
umpan balik yang diberikan.
Tahap Implementasi

Selama tahap implementasi, prosedur untuk melatih fasilitator dan para pembelajar dikembangkan.
Pelatihan fasilitator harus mencakup kurikulum kursus, hasil pembelajaran, metode pengiriman, dan
prosedur pengujian. Persiapan peserta didik termasuk melatih mereka pada alat-alat baru (perangkat
lunak atau perangkat keras), pendaftaran siswa.

Ini juga merupakan fase di mana manajer proyek memastikan bahwa buku, peralatan tangan,
peralatan, CD-ROM dan perangkat lunak tersedia, dan bahwa aplikasi pembelajaran atau situs web
berfungsi.
Tahap Evaluasi

Fase evaluasi terdiri dari dua bagian: formatif dan sumatif. Evaluasi formatif hadir di setiap tahap
proses ADDIE. Evaluasi sumatif terdiri dari tes yang dirancang untuk item yang terkait dengan referensi
kriteria domain tertentu dan memberikan peluang untuk umpan balik dari pengguna.
3.3 Latihan
1. Gambarkan dan jelaskan siklus hidup SDLC!
Jawab:

2. Jelaskan berdasarkan pemahaman saudara mengenai penggunaan metode dan model yang di
pilih sesuai dengan perancangan aplikasi yang saudara akan buat!

Jawab:

3. Pada software engineering, pemodelan perangkat lunak wajib dilakukan di tahap awal. Model
Waterfall merupakan model rekayasa klasik yang masih digunakan. Gambar dan Jelaskan model
waterfall menurut Witson Royce!
Jawab:

DAFTAR PUSTAKA

• “SDLC Tutorial”. https://www.tutorialspoint.com/sdlc/index.htm

• “ADDIE Model”. http://www.instructionaldesign.org/models/addie/

• “Materi V Perencanaan PerancanganSistem

Informasi”.http://learning.upnyk.ac.id/course/view.php?id=551&section=6

• “SDLC-Agile Model”. https://www.tutorialspoint.com/sdlc/sdlc_agile_model.htm

 Modul 4 : Perancangan Proyek
4.1 Tujuan
Mahasiswa mampu membuat perencanaan pembuatan dasar sebuah proyek sistem.

4.2 Dasar Teori

4.2.1 Observasi
Proyek adalah suatu kegiatan mengkoordinasikan segala sesuatu dengan menggunakan perpaduan
sumber daya manusia, teknik, administratif, keuangan untuk mencapai tujuan yang jelas dan dalam
periode waktu tertentu.

4.2.1.1 Observasi pada Estimasi

Perencanaan Proyek (Project Planning) merupakan awal dari serangkaian aktivitas secara kolektif dari
sebuah proses Manajemen Proyek Perangkat Lunak. Proses manajemen proyek perangkat lunak
dimulai dengan kegiatan project planning (perencanaan proyek). Yang pertama dari aktifitas ini adalah
estimation (perkiraan). Estimasi menjadi dasar bagi semua aktivitas perencanaan proyek yang lain dan
perencanaan proyek memberikan sebuah peta jalan bagi suksesnya rekayasa perangkat lunak, maka
tanpa estimasi kita tidak dapat berjalan dengan baik.

Estimasi sumber daya, biaya dan jadwal untuk usaha pengembangan perangkat lunak membutuhkan
pengalaman, mengakses informasi histories yang baik, dan keberanian untuk melakukan pengukuran
kuantitatif bila hanya data kualitatif saja yang ada.Estimasi membawa resiko yang inheren dan resiko
inilah yang membawa kepada ketidakpastian.Dibawah ini merupakan faktor-faktor yang
mempengaruhi estimasi.

Project Complexity (Kompleksitas Proyek)

Kompleksitas Proyek berpengaruh kuat terhadap ketidapastian yang inheren dalam

perencanaan.Tetapi kompleksitas merupakan pengukuran relatif yang dipengaruhi oleh kebiasaan
dengan usaha yang sudah dilakukan pada masa sebelumnya.

Project Size (Ukuran Proyek)

Bila ukuran bertmbah maka ketergantungan diantara berbagai elemen perangkat lunak akan
meningkat dengan cepat. Dekomposisi masalah sebagai suatu pendekatan yang sangat penting dalam
proses estimasi menjadi lebih sulit karena lagi karena elemen-elemen yang akan didekomposisimasih
sangat berat.

Structural Uncertainty (Ketidakpastian Struktural)

Bila metrik perangkat lunak yang komprehensif dapat diperoleh pada proyek yang telah lalu, maka
estimasi dapat dilakukan dengan kepastian yang lebih tinggi.jadwal dapat dibuat untuk menhindari
kesulitan-kesuliatan yang terjadi di masa lalu, dan resiko keseluruhan dapat dikurangi.

4.2.1.2 Karakteristik Proyek

a. Mempunyai tujuan yang jelas, menuju/membuat perubahan

b. Kegiatannya dibatasi oleh waktu; sifatnya sementara, diketahui kapan mulai dan
berakhirnya

c. Dibatasi oleh biaya/budget

 d. Dibatasi oleh kualitas

e. Biasanya tidak berulang-ulang

f. Memerlukan struktur organisasi temporari

4.2.2 Tujuan Perancangan Proyek

Tujuan umum dari perencanaan proyek perangkat lunak adalah:

1. Menyediakan sebuah kerangka kerja yang memungkinkan manajer membuat estimasi yang
dapat dipertanggung-jawabkan mengenai sumber daya, biaya dan jadwal. Estimasi dibuat
dengan sebuah kerangka waktu yang terbatas pada awal sebuah proyek perangkat lunak dan
seharusnya diperbaharui secara teratur selagi proyek sedang berjalan.
2. Untuk pengawasan, penelusuran, dan pemantauan sebuah proyek teknik yang kompleks.

4.2.3 Ruang Lingkup dan Batasan Proyek

Manajemen proyek perangkat lunak merupakan bagian yang penting dalam pembangunan. Tidak
bersifat teknis seperti pengkodean. Manajemen proyek PL ini mampu menentukan apakah proyek
akan berjalan dengan baik sehingga menghasilkan produk yang baik. Berkaitan dengan manajemen
adalah pengelolaan personel dan koordinasi tim, proses, pengukuran proyek-termasuk menentukan
harga dari PL, penjadwalan dan sebagainya.

Aktivitas pertama dalam perencanaan perangkat lunak adalah penentuan ruang lingkup perangkat
lunak yang terdiri dari:

1. Fungsi, Untuk memberikan awalan yang lebih detail pada saat dimulai estimasi.
2. Kinerja, Melingkupi pemrosesan dan kebutuhan waktu respon.
3. Batasan, Mengidentifikasi batas yang ditempatkan pada perangkat lunak oleh hardware
eksternal, memori dan system lain.
4. Interface, Konsep sebuah Interface diinterpretasikan untuk menentukan:
5. Hardware yang mengeksekusi perangkat lunak dan device yang dikontrol secara langsung oleh
perangkat lunak.
6. Software yang sudah ada dan harus dihubungkan dengan perangkat lunak baru.
7. Manusia yang menggunakan perangkat lunak melalui perangkat I/O
8. Prosedur
9. Realibilitas (Keandalan)

Untuk mengerti Ruang Lingkup tersebut, maka perekayasa perangkat lunak harus:

1. Mengerti kebutuhan pelanggan

2. Mengerti konteks bisnis
3. Mengerti batasan-batasan proyek
4. Mengerti motivasi pelanggan
5. Mengerti alur kearah perubahan

Tujuan menentukan ruang lingkup dan batasan proyek, yaitu:

1. Agar proyek tidak overleap dan dapat dimengerti oleh team

2. Kualitas Produk
3. Ketidakpastian
4. Resiko yang mungkin ada
 5. Estimasi Biaya
6. Penjadwalan Project

Teknik yang banyak dipakai secara umum untuk menjembatani jurang komunikasi antara pelanggan
dan pengembang serta untuk memulai proses komunikasi adalah dengan melakukan pertemuan atau
wawancara pendahuluan.Gause & Weinberg mengusulkan bahwa analisis harus memulainya dengan
mengajukan pertanyaan-pertanyaan bebas konteks, yaitu serangkaian pertanyaan yang akan
membawa kepada pemahaman yang mendasar terhadap masalah, orang yang menginginkan suatu
solusi, sifat solusi yang diharapkan, dan efektivitas pertemuan itu sendiri.

Informasi yang dibutuhkan (awal pertemuan antara pelanggan dan pengembang) :

Pertanyaan berfokus pada pelanggan, tujuan keseluruhan serta keuntungan.

Siapa di belakang permintaan kerja ini ?

Siapa yang akan memakai solusi ini?

Apakah keuntungan ekonomi dari solusi yang sukses?

Adakah sumber daya lain bagi solusi ini?

Pertanyaan yang memungkinkan analis memahami masalah lebih baik dan pelanggan
menyuarakan persepsi tentang sebuah solusi.

Bagaimana Anda (pelanggan) menandai output yg baik yg akan dihasilkan oleh sebuah solusi yg baik?

Masalah apa yang dituju solusi ini?

Dapatkah anda menggambarkan lingkungan dimana solusi akan dipakai?

Adakah batasan atau isu kinerja khusus yg akan mempengaruhi.

Teknik Pelaksanaan:

1. Analisis Resiko Formal

2. Perkiraan biaya dan waktu yang diperlukan
3. Manajemen Proyek yang berbasis Matriks
4. Mengumpulkan data pelaksanaan yang telah dilaksanakan
5. Membandingkan pelaksanaan dengan kualitas yang ingin dicapai
6. SDM yang terlibat dalam proyek.
4.3 Latihan
1. Jelaskan tahap observasi estimasi pada perancangan proyek perangkat lunak!
Jawab:

2. Jelaskan tujuan perancangan proyek perangkat lunak.

Jawab:

3. Buatlah perencanaan proyek perangkat lunak untuk proyek perangkat lunak sesuai dengan
manajemen organisasi. Yang di pilih.
Jawab:
DAFTAR PUSTAKA

• “Materi V Perencanaan Perancangan Sistem Informasi”.

http://learning.upnyk.ac.id/course/view.php?id=551&section=6
 Modul 5 : Requirement Modelling
5.1 Tujuan
Mahasiswa mampu merancang sebuah dokumentasi perancangan sistem dari langkah awal (analisa)
hingga pembangunan sistem.

5.2 Dasar Teori

5.2.1 Prinsip-prinsip Analisis

5.2.1.1 Kebutuhan (Requirement)

Sesuatu yang diminta , dibutuhkan

Menurut IEEE (the institute of electrical and electronics engineers)

- Kondisi atau kemampuan yg diperlukan pemakai untuk menyelesaikan persoalan untuk

mencapai sebuah tujuan

- Kondisi atau kemampuan yang harus dimiliki atau dipunyai oleh sistem atau komponen
sistem untuk memenuhi kontrak, standar, spesifikasi, atau dokumen formal lainnya.

Kebutuhan perangkat lunak adalah kondisi, kriteria, syarat atau kemampuan yang harus dimiliki oleh
perangkat lunak untuk memenuhi apa yang disyaratkan atau diinginkan pemakai.

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

1. Kebutuhan fungsional (functional requirement)

Disebut juga kebutuhan operasional, yaitu kebutuhan yang berkaitan dengan fungsi atau proses
transformasi yang harus mampu dikerjakan oleh perangkat lunak atau 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 perangkat lunak dengan elemen perangkat keras,
perangkat lunak, 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 perangkat lunak,
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.

Requirement penting, karena sangat mempengaruhi sukses atau gagalnya pelaksanaan

pengembangan perangkat lunak. Menurut hasil survey DeMarco, 56% kegagalan proyek
pengembangan perangkat lunak dikarenakan ketidaklengkapan pendefinisian kebutuhan dari
perangkat lunak tersebut.

5.2.1.2 Analisis Tersetruktur

Salah satu metode teknis untuk melaksanakan analisis kebutuhan tersebut. Analisis Terstruktur
(Structured Analysis) merupakan salah satu teknik analisis yang mengunakan pendekatan
berorientasi fungsi.

Perangkat Pemodelan Analisis Terstruktur adalah alat bantu pemodelan yang digunakan untuk
menggambarkan hasil pelaksanaan Analisis Terstruktur.

1. Diagram Aliran Data atau Data Flow Diagram (DFD)

2. Kamus Data atau Data Dictionary
3. Structured English
4. Tabel Keputusan atau Decision Table
5. Pohon Keputusan atau Decision Tree

5.2.1.3 Product and Process requirement

Parameter produk adalah requirement pada software untuk dikembangkan (Contohnya “Software
harus memeriksa prasyarat mata kuliah yang diambil mahasiswa”)

Parameter proses adalah batasan – batasan dalam mengembangkan software. Contohnya pilihan
teknik verifikasi. Process requirement juga bisa ditetapkan oleh organisasi pengembang, pelanggan
atau pihak ketiga seperti badan regulator.

5.2.1.4 Requirement fungsional dan nonfungsional

Requirments fungsional menjabarkan fungsi – fungsi yang akan dilaksanakan software. Contohnya
memformat teks. Kadang – kadang disebut juga sebagai kapabilitas.

Requirements non-fungsional memberikan batasan terhadap solusi yang akan dihasilkan. Disebut juga
sebagai quality requirement. Requirement jenis ini masih bisa dibagi lagi menjadi performance
requirements, maintainability requirements, safety requirements, reliability requirements atau salah
satu software requirements lainnya.

5.2.1.5 Emergent Properties

Beberapa requirement merupakan perwakilan dari emergent properties yaitu requirement yang tidak
bisa ditangani oleh satu komponen saja. Keberhasilan dalam menanganinya juga bergantung pada
interoperasi dari berbagai komponen yang ada. Emergent properties amat bergantung pada arsitektur
sistem.
5.2.1.6 Quantifiable Requirements
Software requirement harus bisa dinyatakan dengan jelas, tidak ambigu dan pada beberapa bagiannya
yang sesuai, kuantitatif.

Contoh requirement yang memenuhi syarat: Sebuah perangkat lunak dari suatu call central harus
meningkatkan throughput sebanyak 20% dan sistemnya hanya menghasilkan kesalahan fatal dengan
peluang kurang.

5.2.1.7 System Requirements dan Software Requirements

Dalam topik ini sistem berarti kombinasi dari elemen – elemen yang berinteraksi untuk mencapai
suatu tujuan yang terdefinisikan. Ini termasuk hardware, software, firmware, manusia, informasi,
tehnik, fasilitas, layanan dan berbagai elemen pendukung lainnya

System requirement adalah requirement untuk sistem secara keseluruhan. Dalam sebuah sistem
yang mengandung komponen software, software requirement diperoleh dari system requirement.

5.2.2 Requirement Analysis

Analisis Kebutuhan PL merupakan aktifitas awal dari siklul hidup pengembangan PL. Untuk proyek
besar analisis kebutuhan dilaksanakan setelah aktifitas sistem information engineering dan software
projek planning. Proses mempelajari kebutuhan pemakai untuk mendapatkan definisi kebutuhan
sistem atau perangkat lunak [IEE93]. Proses untuk menetapkan fungsi dan unjuk kerja perangkat
lunak, menyatakan antarmuka perangkat lunak dengan elemen-elemen sistem lain, dan menentukan
kendala yang harus dihadapi perangkat lunak [PRE01].

5.2.2.1 Tujuan Pelaksanaan Analisis Kebutuhan

Tujuan pelaksanaan analisis kebutuhan adalah

1. Memahami masalah secara menyeluruh (komprehensif) yang ada pada perangkat lunak
yang akan dikembang seperti ruang lingkup produk perangkat lunak(product space) dan
pemakai yang akan menggunakannya.
2. Mendefinisikan apa yang harus dikerjakan oleh perangkat lunak untuk memenuhi keinginan
pelanggan.

5.2.2.2 Tahapan Analisis Kebutuhan

Secara teknis pelaksanaan pekerjaan analisis kebutuhan perangkat lunak pada dasarnya terdiri dari
urutan aktivitas:

1. Mempelajari dan memahami persoalan

2. Mengidentifikasi kebutuhan pemakai
3. Mengidentifikasi kebutuhan perangkat lunak
4. Membuat dokumen spesifikasi kebutuhan perangkat lunak
5. Mengkaji ulang (review) kebutuhan

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

1. Pengenalan masalah
2. Evaluasi dan sistesis
3. Pemodelan
4. Spesifikasi
 5. Tinjau ulang (review)

5.2.2.3 Metode Analisis

Metode atau teknik untuk melakukan analisis kebutuhan perangkat lunak dapat dikelompokkan
berdasarkan pendekatan yang diambil pada saat melakukan aktivitas tersebut.

Salah satu metode yang paling populer untuk pendekatan ini adalah Analisis Terstruktur (Structured
Analysis)

1. Berorientasi Aliran Data (Data Flow Oriented atau Functional Oriented)

Berorientasi Aliran Data (Data Flow Oriented atau Functional Oriented). Pada metode ini, hasil
analisis dan perancangan dimodelkan dengan menggunakan beberapa perangkat pemodelan
seperti:

a. Data Flow Diagram (DFD) dan Kamus Data (data dictionary) untuk menggambarkan
fungsi-fungsi dari sistem (system functions).
b. Entity-Relationship Diagram (ERD) untuk menggambarkan data yang disimpan (data
stored).
c. State Transition Diagram (STD) untuk menggambarkan perilaku sistem.
d. Structure Chart untuk menggambarkan struktur program.

2. Berorientasi Struktur Data (Data Structured Oriented)

3. Berorientasi Objek (Object Oriented)

Berorientasi Objek (Object Oriented)

a. Berbeda dengan pendekatan-pendekatan sebelumnya, pendekatan berorientasi objek

memandang sistem yang akan dikembangkan sebagai suatu kumpulan objek yang
berkorespondensi dengan objek-objek dunia nyata.

b. Pada pendekatan ini, informasi dan proses yang dipunyai oleh suatu Objek
“dienkapsulasi” (dibungkus) dalam satu kesatuan.

c. Beberapa metode pengembangan sistem yang berorientasi objek ini diantaranya

adalah:

• Object Oriented Analysis (OOA) dan Object Oriented Design (OOD) dari Peter
Coad dan Edward Yourdon (1990).
• Object Modeling Technique (OMT) dari James Rumbaugh (1987).
• Object Oriented Software Engineering (OOSE).

5.2.2.4 Klasifikasi Requirements

Fungsional dan non fungsional

Apakah suatu requirement didapat dari satu atau lebih requirement yang berlevel lebih tinggi atau
merupakan emergent propety (sub bagian 1.4) atau ditetapkan oleh pihak yang berkepentingan atau
sumber lain.

Apakah requirement ada pada produk atau proses.

Prioritas. Secara umum, semakin tinggi prioritas suatu requirement semakin mendesak pula untuk
dipenuhi dalam produk akhir.
Cakupan dari requirement. . Hal ini sangat berpengaruh pada arsitektur software dan desain
komponen.

Stabilitas. Requirement kadang berubah dalam suatu siklus hidup software bahkan mungkin dalam
proses pengembangannya.

5.2.2.5 Conceptual Modelling

Pemodelan dari permaslahan riil adalah kunci dari analisa software requirements.

Tujuannya untuk membantu memahami permasalahan. Model konseptual terdiri dari model entitas
– entitas dari domain permasalahan yang disusun untuk mewakili relasi riil dan ketergantungan riil.

Ada beberapa model yang bisa dikembangkan. Antara lain aliran data dan kontrol, model keadaan,
pelackan even, interaksi pengguna, model obyek, model data dan lain – lain.

Faktor yang mempengaruhi pemilihan pemodelan:

 Sifat dari permasalahan. Beberapa tipe software menuntut agar aspek tertentu dianalisa
secara menyeluruh

 Keahlian perekayasa software. Lebih baik menggunakan notasi atau metode permodelan yang
sudah familier.

 Process requierement dari pelanggan. Mungkin pelangan ingin menetapkan notasi atau
metode pemodelan tertentu

 Ketersediaan metode dan alat. Meskipun cocok namun jika tidak ditunjang dengan keahlian
dan alat yang baik, suatu notasi atau metode tidak bisa dipakai.

5.2.2.6 Desain Arsitektur dan Alokasi Requirement

Desain arsitektural adalah suatu tahap di mana requirement process dilakukan bersamaan dengan
desain sistem atau software. Karenanya sulit memisahkan dua aktivitas tersebut.

Desain arsitektural sangat berhubungan dengan pemodelan konseptual. Pemetaan domain entitas
dunia nyata menjadi komponen software tidak selalu jelas, sehingga desain arsitektural dianggap
sebagai topik terpisah. Requirement untuk notasi dan metode secara umum sama pada pemodelan
konseptual dan desain arsitektural.

5.2.2.7 Negosiasi Requirement

Topik ini disebut juga sebagai “penyelesaian konflik”. Topik ini membahas penanganan masalah
requirement di mana timbul konflik antara dua pihak yang sama – sama berkepentingan, antara
requirement dengan sumber daya atau requirement fungsional dan non fungsional. Dalam
kebanyakan kasus, keputusan yang diambil secara unilateral bukanlah sikap bijaksana. Karenanya
penting untuk mencapai konsensus dengan pihak yang berkepentingan.

5.2.2.8 Spesifikasi Requirement

Pada kebanyakan profesi perekayasaan, istilah spesifikasi merujuk pada kegiatan memberikan nilai
numerik atau batas pada tujuan produk akhir.

Tetapi definisi ini tidak bisa dipakai pada rekayasa perangkat lunak mengingat banyaknya requirement
yang ada dan kompleksitas interaksinya.
Karenanya pada rekayasa perangkat lunak istilah “spesifikasi requirement software” mengacu pada
pembuatan dokumen baik fisik maupun elektronis.

Pada sistem yang kompleks, terutama yang melibatkan banyak kompone non software, ada 3 jenis
dokumen yang dibuat yaitu definisi sistem, requirement sistem dan requirement perangkat lunak.

Pada produk software yang sederhana hanya satu dari 3 jenis dokumen itu yang perlu dibuat.

Semua tiga jenis dokumen itu akan dijelaskan di sini.

1: Dokumen Definisi Sistem

Dokumen ini menyimpan requirement sebuah sistem.

Dokumen ini mendaftar semua requirement beserta keterangan latar belakang tujuan keseluruhan
sebuah sistem, lingkungan yang menjadi sasaran dan pernyataan batasan, asumsi dan requirement
non-fungsional.

Mungkin juga di dalamnya terdapat model konseptual yang didesain untuk memberikan gambaran
tentang konteks sistem, skenario pemakaian dan entitas - entitas domain yang penting, termasuk juga
data, informasi dan aliran kerja.

2: Spesifikasi Requirement Sistem

Para pengembang dari sebuah sistem berkomponen software dan non-software yang cukup banyak,
seringkali memisahkan deskripsi dari requirement sistem dari deskripsi requirement software.

Dengan cara ini, requirement sistem dispesifikasikan, requirement software didapat dari requirement
sistem dan requirement untuk komponen sosftware dispesifikasikan .

Karena merupakan bidang rekayasa sistem, dokumen jenis ini tidak akan dibahas terperinci di sini.

3: Spesifikasi Requirement Software

Dokumen jenis ini mendirikan dasar untuk sebuah perjanjian antara pelanggan dan kontraktor atau
penyuplai tentang apa yang seharusnya dan tidak seharusnya dikerjakan oleh produk software.

Untuk pembaca yang kurang paham hal – hal yang sifanya teknis, dokumen jenis ini juga didampingi
oleh dokumen definisi requirement software.

Dokumen ini memungkinkan penilaian mendalam tentang requirement sebelum desain dimulai
sehingga mengurangi keharusan desain ulang.

Dokumen ini juga memberikan dasar – dasar realistis untuk memperkirakan biaya, risiko dan
jadwal produksi.

5.2.3 SRS (Software Requirement Specification)

Sebuah dokumen yang berisi pernyataan lengkap dari apa yang dapat dilakukan oleh perangkat lunak,
tanpa menjelaskan bagaimana hal tersebut dikerjakan oleh perangkat lunak.

5.2.3.1 Tujuan Pembuatan SRS

Tujuan Pembuatan SRS :

1. Pemakai potensial (pelanggan) dari sistem

2. Pengembang sistem
3. Mendefinisikan keinginan yang biasanya dinyatakan dalam bentuk penjelasan umum.
 4. Sarana komunikasi antara pelanggan, pemakai, analis, dan perancang perangkat lunak.
5. Dasar untuk merencanakan dan melaksanakan aktivitas pengujian sistem.
6. Acuan untuk melakukan perbaikan dan perubahan perangkat lunak.

5.2.3.2 Syarat Pembentukan SRS

Syarat Pembentukan SRS

1. Mudah diidentifikasi

2. Diuraikan dengan jelas, simple, sederhana, dan concise (jelas, tidak ambiguous)

3. Bisa divalidasi dan bisa dites (test reliable, test accessable)

4. Mampu untuk ditelusuri kembali (tracebility)

5.2.3.3 Hal-hal yang dihindari saat pembentukan

1. Over specification (penjelasan berlebih dan berulang-ulang sehingga menjadi tidak jelas)

2. Tindakan unconcistency (seperti menggunakan istilah yang tidak konsisten)

3. Ambiguity dalam kata atau kalimat seperti menyatakan keterukuran

4. kebutuhan secara tidak jelas misalkan menggunakan kata-kata :minimal, maksimal, optimal,
cepat, user friendly, efisien, fleksible dan lainnya.

5. Menuliskan “mimpi-mimpi”, yaitu hal-hal yang tidak bisa dilakukan.

5.2.3.4 Atribut Penulisan SRS yang Baik

Dokumen SRS yang baik (sempurna) akan ditulis secara:

1. Benar (correct) 12. Dapat melingkupi semua lingkungan

2. Tepat (precise) operasional, misalnya interaksi fisik
3. Unambiguouity dan operasional.
4. Lengkap (complete) 13. Bisa menggambarkan sistem seperti
5. Bisa diverifikasi (verifiable) yang dilihat oleh pemakai.
6. Konsisten 14. Harus toleran (bisa menerima)
7. Understandable terhadap ketidaklengkapan,
8. Bisa dimodifikasi (modifiedable) ketidakpastian (ambiguous) dan
9. Dapat ditelusuri (traceable) ketidakkonsistenan.
10. Harus dapat dibedakan bagian what 15. Harus bisa dilokalisasi dengan
(bagian spesifikasi) dan how (bagian sebuah coupling, yaitu hubungan
yang menjelaskan bagaimana ketergantungan antara dua model
menyelesaikan what tadi). yang tidak terlalu erat.
11. Dapat mencakup dan melingkupi
seluruh sistem
5.2.3.5 Orang yang Terlibat
Ada 9 macam orang yang terlibat dalam pembuatan SKPL:

1. Pemakai (user) 4. Software engineer

2. Client 5. Programmer

3. System analyst (system engineer) 6. Test integration group

 7. Maintenance group 9. Staff dan Clerical Work

8. Technical Support

5.2.3.6 Keberhasilan Pengembangan Perangkat Lunak

Keberhasilan pengembangan perangkat lunak bisa dilihat dari 10 aspek atau titik pandang:

1. Ketelitian dari pembuatnya

2. Kualitas dari spesifikasi perangkat lunak yang dihasilkan (baik, jika ada sedikit kesalahan)
3. Integritas
4. Ketelitian
5. Proses pembuatan yang mantap
6. Mudah dikembangkan
7. Jumlah versi tidak banyak
8. Ketelitian dari model pengembangan yang digunakan untuk meramal atribut perangkat
lunak
9. Efektivitas rencana tes dan integrasi
10. Tingkat persiapan untuk sistem perawatan (mempersiapkan pencarian bugs)

5.3 Latihan
1. Jelaskan prinsip-prinsip analisis kebutuhan rekayasa perangkat lunak!
Jawab:
2. Jelaskan denga lengkap tentang analisis kebutuhan rekayasa perangkat lunak!

Jawab:

3. Buatlah contoh dokumen SRS berdasarkan standar rekomendasi IEEE830 1993!

Jawab:

DAFTAR PUSTAKA

• Pressman, RS., 2008, Software Engineering: A Practitioner’s Approach, New York: McGraw-
Hill
 Modul 6 : System Design
6.1 Tujuan
Mahasiswa mampu merancang sebuah dokumetasi perancangan sistem dari langkah awal (analisis)
hingga pembangunan sistem.

6.2 Dasar Teori

6.2.1 Desain Data
Desain data adalah tahapan pemilihan representasi logis dari objek data yang telah teridentifikasi
dalam Analisis Persyaratan dan Spesifikasi. Prinsip-prinsip :
1. Prinsip-prinsip analisis sistem yang diterapkan pada fungsi dan perilaku PL juga perlu
diterapkan pada data.
2. Semua struktur data dan operasinya harus teridentifikasi.
3. Kamus data harus dibangun untuk merepresentasikan hub antarobjek data dan batasan2nya.
4. Keputusan desain data tingkat rendah harus dilakukan di akhir proses desain data.
5. Konsep information hiding (penyembunyian informasi suatu modul agar tidak diakses oleh
modul lain yang tidak berkepentingan) dan perangkaian sangat penting bagi kualitas PL.
6. Pustaka struktur data dan operasi yang berguna harus dikembangkan agar dapat digunakan
kembali.
7. Desain PL dan bahasa pemrograman harus mendukung spesifikasi dan realisasi tipe data
abstrak.

6.2.2 Desain Arsitektur

Arsitektur merupakan struktur hirarkhi dari komponen program (modul), interaksinya, dan struktur
data yang digunakan. Terdapat beberapa model desain arsitektur :

1. Model Struktural : berdasarkan struktur komponen program

2. Model Kerangka Kerja : berupa peningkatan abstraksi desain berdasarkan kerangka kerja

3. Model Dinamis : menggambarkan perilaku berdasarkan external events

4. Model Proses : fokus pada proses

5. Model Fungsional : menggambarkan hirarkhi fungsional

Perbandingan tentang berbagai macam alat modeling guna membangun desain arsitektur, yaitu:

1. Alat process modeling : Flow Chart, Flow of Document, Data Flow Diagram, Structured Chart,
HIPO Diagram, Pseudocode, Nassi-Shneiderman Chart, Warnier-Orr Diagram, Michael Jackson
Diagram, Functional Decomposition, Action Diagram, Data Navigation Diagram, HOS Chart,
dsb.

2. Alat data modeling : Entity Relationship Diagram, Network Diagram, Hierarchical Diagram,
Table Normalization, atau gabungannya.

3. Alat object modeling : Object Diagram (Coad/Yourdon, Rambaugh, Firesmith, Booch, dsb.)
yang dapat dibangun dengan Oracle Designer/2000, Microsoft Visual Studio – Enterprise Tools
(Modeler), dsb.
 4. Alat working modeling : Excelerator, Easycase, Oracle Designer/2000, Microsoft Visual Studio
- Enterprise Tools (Modeler), dsb.

6.2.2.1 Modularitas
Modularitas dan Kompleksitas Problem

Modularitas diterapkan melalui pembagian PL ke dalam komponen – komponen PL yang dapat

dipanggil terpisah sehingga bila terdapat problem, maka problem tsb akan lebih mudah diselesaikan.
Kompleksitas ( C ) problem (p1 dan p2) yang bergabung menjadi satu, lebih besar dibandingkan bila
problem tersebut dipandang secara terpisah.

C(p1+p2) > C(p1) + C(p2)

Oleh sebab itu modularitas penting dalam desain arsitektur PL. Namun berkaitan dengan biaya,
sebaiknya dihindari kondisi undermodularity maupun overmodularity. Semakin banyak modul
semakin rendah biaya per-modul tetapi semakin tinggi biaya integrasinya.

6.2.2.2 Independensi Fungsional

Konsep ini merupakan pertumbuhan langsung dari modularitas, konsep abstraksi PL, dan Information
Hiding. Independensi diukur melalui Kohesi dan Kopling.

• Kohesi

Modul yang kohesif seharusnya hanya melakukan satu hal saja (kohesi tinggi = fungsional <>
koinsidental).

• Kopling

Sehubungan dengan perangkaian dengan modul lain, maka modul yang baik seharusnya memiliki
hubungan yang sederhana (kopling rendah)

6.2.2.3 Proses Desain Arsitektur

a. Pemetaan Transformasi

Informasi dari ‘dunia eksternal’ mengalir masuk ke dalam PL dan keluar lagi dalam bentuk informasi
dunia eksternal. Misal ketikan keyboard dan bunyi di saluran telpon akan masuk ke pusat transformasi
dan dialirkan ke dunia luar dalam bentuk tampilan layar. Aliran ini disebut aliran transformasi. Dalam
DFD dapat dijumpai adanya aliran transformasi ini.

Guna menyusun struktur program aliran transformasi dari DFD ini dipetakan dengan langkah
pengkajian thd Context DFD, penentuan pusat transformasi, pemfaktoran dan penyaringan, dan
pemetaan. Contohnya sbb.

b. Pemetaan Transaksi

Aliran transaksi ditandai dengan pergerakan data sepanjang jalur masuk yang mengkonversikan
informasi dunia eksternal ke dalam suatu transaksi. Transaksi ini akan menimbulkan jalur aksi. Pusat
aliran informasi tempat banyak jalur aksi berasal disebut pusat transaksi.

Pemetaan DFD yang mengandung aliran transaksi ke struktur program hampir sama dengan pemetaan
aliran transformasi, namun yang diidentifikasi adalah pusat transaksinya (lihat contoh)
6.2.3 Desain Antarmuka (Mobile dan Desktop)
Internal : merupakan desain interface antarmodul dalam PL yang dikendalikan oleh data yang harus
mengalir di antara modul-modul. Aliran transformasi dalam DFD merupakan pijakan utama dalam
desain ini selain kemampuan bahasa pemrograman.

Eksternal : merupakan interface untuk entitas eksternal (tidak termasuk manusia), misalnya sensor
pada PL Safehome.

Manusia – Mesin : merupakan interface antara manusia dengan PL (Human – Computer Interface).
Interface ini memiliki tantangan besar karena berkaitan dengan pengguna dengan berbagai karakter
yang lebih sulit untuk dipelajari. Terdapat tiga kategori pedoman desain HCI sbb.

a. Interaksi Umum

• Format konsisten

• Berikan umpan balik

• Konfirmasi untuk aksi destruktif (misal Hapus)

• Ijinkan pembatalan (misal Undo)

• Kurangi jumlah informasi yang harus diingat

• Efisiensi dalam dialog, gerakan (tangan), pemikiran

• Perlindungan terhadap kegagalan

• Kategorikan aktivitas sejenis dan posisinya di layar

• Sediakan Help yang sensitif konteks

• Berikan petunjuk singkat (tools tips) pada setiap button / ikon / nama

• Gunakan perintah dan nama2 yang pendek

b. Output

• Tampilkan informasi yang relevan dg konteks

• Jangan membanjiri pemakai dg informasi

• Gunakan label, singkatan, warna yg standar dan konsisten

• Peliharalah konteks visual saat pengguna melakukan zoom-in / zoom-out

• Pesan kesalahan harus memiliki arti yang jelas

• Gunakan variasi huruf, indentasi, pengelompokan untuk memudahkan pemahaman

• Gunakan jendela untuk tipe-tipe informasi yang berbeda

• Gunakan tampilan alami (bukan angka / grafik) bila memungkinkan

• Geografi layar dioptimalkan shg tidak ada jendela yang ‘hilang’ / sulit ditemukan

• Berikan kemungkinan kustomisasi output (utk advance user)

 • Jangan ada informasi / data yang tidak lengkap / hilang sebagian

c. Input

• Minimalkan jumlah aksi input (combo box, list, dsb.)

• Konsisten

• Berikan kemungkinan kustomisasi input (utk advance user)

• Mode input harus fleksibel (mouse / keyboard)

• Non-aktifkan button / ikon yang tidak relevan dengan aksi

• Berikan kesempatan untuk mengontrol aliran interaksi (mengubah, membetulkan,

mengulang)

• Sediakan Help

• Jangan meminta aktivitas manual (perhitungan, tanggal, waktu, dsb) bila dapat dilakukan
oleh PL

6.3 Latihan
1. Apa itu desain arsitektur perangkat lunak?
Jawab:
2. Bagaimana data science dan machine learning mempengaruhi desain perangkat lunak?
Jawab:

3. Berikan contoh pemetaan transformasi dan pemetaan transaksi pada desain arsitektur!
Jawab:

DAFTAR PUSTAKA

• Pressman, RS., 2008, Software Engineering: A Practitioner’s Approach, New York: McGraw-
Hill
 Modul 7 : Process Modelling
7.1 Tujuan
Mahasiswa mampu merancang sebuah dokumentasi perancangan sistem dari langkah awal (analisis)
hingga pembangunan sistem.

7.2 Dasar Teori

7.2.1 Flowchart

Diagram alir/Flowchart merupakan gambar yang mewakili langkah-langkah sebuah proses terurut
secara terpisah agar proses tersebut menjadi lebih sederhana sehingga mudah dipahami.

Dalam merancang program, seorang programmer pastinya akan membutuhkan berbagai macam
langkah – langkah dasar yang selanjutnya digambarkan secara grafik dan sekuensial. Dalam dunia
pemrograman, penggambaran langkah – langkah secara grafis dan sekuensial disebut sebagai diagram
alir. Diagram alir memiliki jenis dan simbol yang berbeda-beda yang disesuaikan berdasarkan dengan
fungsinya. Biasanya diagram alir digunakan untuk mempermudah penyelesaian masalah dalam
pemrograman.

7.2.1.1 Sejarah
Diagram alir merupakan metode terstruktur pertama yang diperkenalkan oleh Frank Gilberth kepada
anggota American Society of Mechanical Engineers (ASME) pada tahun 1921 yang kemudian di adopsi
oleh ASME pada tahun 1947 dan dikembangkan oleh Herman Goldstine dan John von Neumann untuk
merencanakan program komputer. Diagram alir dari Goldstine dan John von Neumann dapat
ditemukan dalam laporan “Perencanaan dan Pengkodean Masalah untuk Instrumen Komputasi
Elektronik, bagian II, Volume 1”. Pada tahun 1970, popularitas diagaram alir sebagai metode menurun.
Walaupun begitu, sampai saat ini diagram alir masih digunakan untuk menggambarkan algoritma
komputer.

7.2.1.2 Simbol-Simbol
Berikut adalah symbol-simbil yang digunakan untuk membuat flowchart, yaitu:

s
7.2.2 Swimlane

Swimlane process diagram adalah sebuah diagram flow proses yang menggambarkan interaksi dari
beberapa bagian yang berbeda yang terlibat dalam sebuah lini proses bisnis. Diagram ini
menggunakan format jalur hubungan (swimlane), adapun menggambarkannya dilakukan dengan cara
menampilkan stakeholder pada baris diagram serta kerangka waktu pada kolom diagram; dan
kemudian aktivitasnya ditampilkan menggunakan simbol flowchart. Swim Lane Process Diagram
adalah diagram yang menggambarkan aktivitas dari setiap stakeholder yang terlibat di dalam kegiatan
bisnis perusahaan; diagram ini merepresentasikan flow proses yang menggambarkan interaksi dari
beberapa bagian yang berbeda dan bagaimana perkembangan proses melalui beberapa phase yang
berbeda. Swimlane process diagram yaitu bagan yang menggambarkan setiap Stakeholder yang ada
di Line Of Business(LOB) perusahaan tersebut, yang digambarkan dengan symbol dari flowchart.
Dengan demikian Swimlane process diagram merupakan activity diagram dari para stakeholder yang
memperlihatkan stakeholder yang terlibat di dalam proses line of business (LOB), dan waktu pada
interaksinya.

Swimlane adalah elemen visual yang digunakan dalam diagram alir proses yang menggambarkan siapa
bekerja pada subset tertentu dari sebuah proses. Swimlane tersebut diatur baik horisontal maupun
vertikal dan digunakan untuk mengelompokkan sub-proses sesuai dengan tanggung jawab mereka.
Flowchart swimlane berbeda dengan diagram alur lain. proses dan pengelompokannya
digambarkandengan menempatkannya pada jalur. Garis paralel menjadi jalur untuk pengeolompokan
orang atausubproses. Jalur diberi label untuk menunjukkan bagaimana bagan di kelola. Elemen-
elemen yang terdapat dalam swimlane diagram adalah : (a) Process: Aktual proses dan flow , (b)
Actors: Orang, groups, teams, yang melakukan tahapan proses. (c) Phases: Menunjukkan tahapan dari
project. (d)Symbols: Simbol fisik yang digunakan menggambarkan apa yang terjadi pada setiap
tahapan dari proses.

Format standar sebuah swimlane diagram adalah sebagai berikut :

Swim lane diagram , sering disebut juga “Deployment Process Map” atau “Cross Functional
Flowchart” adalah sebuah diagram yang merepresentasikan flow proses yang menggambarkan
interaksi dari beberapa bagian yang berbeda dan bagaimana perkembangan proses melelui beberapa
phase yang berbeda.

Diagram Stakeholder Activity menunjukkan stakeholder (orang yang secara pribadi berminat dalam
enterprise) yang terlibat dalam proses lini bisnis, dan ketepatan dari interaksi. Diagram menggunakan
format swim lane untuk mengatur stakeholder dengan baris, dan kerangka waktu dengan kolom,
kemudian menggambarkan aktivitas menggunakan simbol bagan alir. Swim lane diagram adalah
sebuah diagram yang merepresentasikan flow proses yang menggambarkan interaksi dari beberapa
bagian yang berbeda dan bagaimana perkembangan proses melelui beberapa phase yang
berbeda. Swimlane membagi aktivitas dalam beberapa kelompok dimana setiap kelompok yang telah
dibagi dibuat untuk dapat merepresentasikan organisasi yang bertanggung jawab untuk aktivitas
tersebut. Setiap swimlane memiliki nama dan juga setiap aksi/aktivitas hanya berada di 1 swimlane
saja.

Berikut merupakan contoh swim lane process diagram pada payroll prosesm dimana terdiri dari
beberapa stakeholder yang terlibat, yaitu: human resources, employee, manager, payroll, dan payroll
vendor.

7.2.3 Use Case

Use case diagram menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang
ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. Sebuah use case
merepresentasikan sebuah interaksi antara aktor dengan sistem. Menggambarkan fungsionalitas yang
diharapkan dari sebuah sistem. Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan
“bagaimana”. Menggambarkan kebutuhan system dari sudut pandang user. Mengfokuskan pada
proses komputerisasi (automated processes). Menggambarkan hubungan antara use case dan actor.
Use case menggambarkan proses system (kebutuhan system dari sudut pandang user). Secara umum
use case adalah:

• Pola perilaku system

• Urutan transaksi yang berhubungan yang dilakukan oleh satu actor

Use Case Modeling

• Core elements

Construct Description Syntax

use case A sequence of actions, including
variants, that a system (or other UseCaseName
entity) can perform, interacting with
actors of the system.
actor A coherent set of roles that users
of use cases play when interacting
with these use cases.
ActorName

system Represents the boundary between

boundary the physical system and the actors
who interact with the physical
system.
 • Core relationships

Construct Description Syntax

association The participation of an actor in a use
case. i.e., instance of an actor and
instances of a use case communicate
with each other.
generalization A taxonomic relationship between a
more general use case and a more
specific use case.
extend A relationship from an extension use
case to a base use case, specifying
how the behavior for the extension
use case can be inserted into the
behavior defined for the base use
case.

Construct Description Syntax

include An relationship from a base use case
to an inclusion use case, specifying
how the behavior for the inclusion use
case is inserted into the behavior
defined for the base use case.

• Use case diagram terdiri dari

a. Use case
Use case dibuat berdasar keperluan actor, merupakan “apa” yang dikerjakan system, bukan
“bagaimana” system mengerjakannya. Use case diberi nama yang menyatakan apa hal yang
dicapai dari hasil interaksinya dengan actor.
Use case dinotasikan dengan gambar (horizontal ellipse)
Nama use case boleh terdiri dari beberapa kata dan tidak boleh ada 2 use case yang memiliki
nama yang sama. Sebuah use case bisa mempunyai dokumentasi. Letakkan use case utama anda
pada pojok kiri atas dari diagram (in western culture people read from left to right, top to bottom,
starting in the top-left corner). Use case diagram tidak terpengaruh urutan waktu, meskipun
demikian supaya mudah dibaca perlu penyusunan use case.

b. Actors
Actor menggambarkan orang, system atau external entitas / stakeholder yang menyediakan
atau menerima informasi dari system. Actor menggambarkan sebuah tugas/peran dan bukannya
posisi sebuah jabatan. Actor memberi input atau menerima informasi dari system.

Notasi actor, yaitu:

Actor biasanya menggunakan Kata benda. Tidak boleh ada komunikasi langsung antar actor.
Indikasi <<system>> untuk sebuah actor yang merupakan sebuah system. Adanya actor bernama
“Time” yang mengindikasikan scheduled events (suatu kejadian yang terjadi secara
periodik/bulanan). Letakkan actor utama anda pada pojok kiri atas dari diagram
 c. Association
Associations bukan menggambarkan aliran data/informasi. Associations digunakan untuk
menggambarkan bagaimana actor terlibat dalam use case. Ada 4 jenis relasi yang bisa timbul pada
use case diagram :
 Association antara actor dan use case
 Association antara use case
 Generalization/Inheritance antara use case
 Generalization/Inheritance antara actors

d. System boundary boxes (optional)

Digambarkan dengan kotak disekitar use case, untuk menggambarkan jangkauan system anda
(scope of of your system). Biasanya digunakan apabila memberikan beberapa alternative system
yang dapat dijadikan pilihan. System boundary boxes dalam penggunaannya optional.

e. Packages (optional)

7.2.4 DFD (Data Flow Diagram)

Diagram alur data (DFD) memetakan arus informasi untuk setiap proses atau sistem. Ini menggunakan
simbol yang didefinisikan seperti persegi panjang, lingkaran dan panah, ditambah label teks singkat,
untuk menunjukkan input data, output, titik penyimpanan dan rute antara setiap tujuan. Diagram alur
data dapat berkisar dari simpulan proses yang sederhana, bahkan digambar tangan, hingga DFD multi-
level yang mendalam yang menggali lebih dalam tentang bagaimana data ditangani. Mereka dapat
digunakan untuk menganalisis sistem yang ada atau memodelkan yang baru. Seperti semua diagram
dan bagan terbaik, DFD sering dapat secara visual "mengatakan" hal-hal yang akan sulit dijelaskan
dalam kata-kata, dan mereka bekerja untuk audiens teknis dan non-teknis, dari pengembang hingga
CEO. Itu sebabnya DFD tetap sangat populer setelah bertahun-tahun. Sementara mereka bekerja
dengan baik untuk perangkat lunak dan sistem aliran data, mereka kurang berlaku saat ini untuk
memvisualisasikan perangkat lunak atau sistem yang interaktif, real-time atau berorientasi database.

Simbol dan Notasi DFD

Dua sistem simbol umum diberi nama setelah penciptanya:

• Yourdon and Coad

• Yourdon dan DeMarco
• Gane dan Sarson

Salah satu perbedaan utama dalam simbol mereka adalah bahwa Yourdon-Coad dan Yourdon-
DeMarco menggunakan lingkaran untuk proses, sementara Gane dan Sarson menggunakan persegi
panjang dengan sudut membulat, kadang-kadang disebut lozenges. Ada variasi simbol lain yang
digunakan juga, jadi hal penting yang harus diingat adalah menjadi jelas dan konsisten dalam bentuk
dan notasi yang Anda gunakan untuk berkomunikasi dan berkolaborasi dengan orang lain.

Dengan menggunakan aturan atau pedoman DFD konvensi apa pun, simbol menggambarkan empat
komponen diagram aliran data.

Entitas eksternal: sistem luar yang mengirim atau menerima data, berkomunikasi dengan sistem yang
sedang digambarkan. Mereka adalah sumber dan tujuan informasi yang memasuki atau meninggalkan
sistem. Mereka mungkin organisasi atau orang luar, sistem komputer atau sistem bisnis. Mereka juga
dikenal sebagai terminator, sumber dan tenggelam atau aktor. Mereka biasanya digambar di tepi
diagram.
Proses: setiap proses yang mengubah data, menghasilkan output. Ini mungkin melakukan
perhitungan, atau mengurutkan data berdasarkan logika, atau mengarahkan aliran data berdasarkan
aturan bisnis. Label pendek digunakan untuk menggambarkan proses, seperti "Kirim pembayaran."

Penyimpanan data: file atau repositori yang menyimpan informasi untuk digunakan nanti, seperti
tabel basis data atau formulir keanggotaan. Setiap penyimpanan data menerima label sederhana,
seperti "Pesanan."

Aliran data: rute yang diambil data antara entitas eksternal, proses dan penyimpanan data. Ini
menggambarkan antarmuka antara komponen lain dan ditampilkan dengan panah, biasanya diberi
label dengan nama data singkat, seperti "Detail Penagihan."

7.2.5 Activity Diagram

Activity diagrams menggambarkan berbagai alir aktivitas dalam sistem yang sedang dirancang,
bagaimana masing-masing alir berawal, decision yang mungkin terjadi, dan bagaimana mereka
berakhir. Activity diagram juga dapat menggambarkan proses paralel yang mungkin terjadi pada
beberapa eksekusi. Activity diagram merupakan state diagram khusus, di mana sebagian besar state
adalah action dan sebagian besar transisi di-trigger oleh selesainya state sebelumnya (internal
processing). Oleh karena itu activity diagram tidak menggambarkan behaviour internal sebuah sistem
(dan interaksi antar subsistem) secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-
jalur aktivitas dari level atas secara umum.

7.2.5.1 Komponen dan Simbol

a. Activity

Activity menggambarkan sebuah pekerjaan/tugas dalam workflow. Pada UML, activity

digambarkan dengan simbola belah ketupat=‘lozenge’ (horizontal top and bottom with convex
sides).
 b. Start State

Start state dengan tegas menunjukkan dimulainya suatu workflow pada sebuah activity diagram.
Hanya ada satu start state dalam sebuah workflow. Pada UML, start state digambarkan dengan
simbol lingkaran yang solid.

c. End State

End state menggambarkan akhir atau terminal dari pada sebuah activity diagram. Bisa terdapat
lebih dari satu end state pada sebuah activity diagram. Pada UML, end state digambarkan dengan
simbol sebuah bull’s eye.

d. Transitions

State transition menunjukkan kegiatan apa berikutnya setelah suatu kegiatan sebelumnya. Pada
UML, state transition digambarkan oleh sebuah solid line dengan panah.

e. Decisions

Decision adalah suatu titik/point pada activity diagram yang mengindikasikan suatu kondisi
dimana ada kemungkinan perbedaan transisi. Pada UML, decision digambarkan dengan sebuah
simbol diamond.

f. Swimlanes

A swimlane adalah di gunakan untuk mempartisi atau berbagi pada diagram aktivitas dan untuk
membantu dan lebih memahami siapa atau apa yang memulai aktivitas.

7.2.6 Sequence Diargam

Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar sistem (termasuk
pengguna, display/form) berupa message yang digambarkan terhadap waktu. Sequence diagram
terdiri atas dimensi vertikal (waktu) dan dimensi horizontal (objek-objek yang terkait). Sequence
diagram biasa digunakan untuk menggambarkan skenario atau rangkaian langkah-langkah yang
dilakukan sebagai respons dari sebuah event untuk menghasilkan output tertentu. Diawali dari apa
yang men-trigger aktivitas tersebut, proses dan perubahan apa saja yang terjadi secara internal dan
output apa yang dihasilkan. Diagram ini secara khusus berasosiasi dengan use case diagram dan
memperlihatkan tahap demi tahap apa yang seharusnya terjadi untuk menghasilkan sesuatu di dalam
use case

7.2.6.1 Tujuan Squence Diagram

• Digunakan untuk memperlihatkan interaksi antar obyek dalam perintah yang berurut.
• Tujuan utama adalah mendefinisikan urutan kejadian yang dapat menghasilkan output yang
diinginkan.
• Mirip dengan activity diagram
• Menggambarkan alur kejadian sebuah aktivitas
• Lebih detail dalam menggambarkan aliran data, termasuk data atau behaviour yang
dikirimkan atau diterima
• Namun kurang mampu menjelaskan detail dari sebuah algoritma (loop, branching).

7.2.6.2 Komponen dan Simbol

7.3 Latihan
1. Jelaskan sejarah Flowchart?
Jawab:

2. Buatlah activity diagram tentang proses bisnis peminjaman dan pengembalian buku
diperpustakaan?
Jawab:
3. Buatlah squence diagram sesuai dengan diagram yang telah dibuat di nomor 2!
Jawab:

DAFTAR PUSTAKA

• “What is a Flowchart”. https://www.lucidchart.com/pages/what-is-a-flowchart-tutorial

• “Diargam Swimlane”. https://sis.binus.ac.id/2014/04/30/diagram-swimlane/

• “What is a Data Flow Diagram”. https://www.lucidchart.com/pages/data-flow-diagram

• Pressman, RS., 2008, Software Engineering: A Practitioner’s Approach, New York: McGraw-
Hill
 Modul 8 : System Building
8.1 Tujuan
Mahasiswa mampu merancang sebuah dokumentasi perancangan sistem dari langkah awal (analisa)
hingga pembangunan sistem.

8.2 Dasar Teori

8.2.1 Bahasa Pemrograman
Unified Modelling Language (UML) adalah sebuah "bahasa" yang telah menjadi standar dalam industri
untuk visualisasi, merancang dan mendokumentasikan sistem informasi atau piranti lunak. UML
menawarkan sebuah standar untuk merancang model sebuah sistem. Seperti bahasa-bahasa lainnya,
UML mendefinisikan notasi dan syntax/semantik.
Notasi UML merupakan sekumpulan bentuk khusus untuk menggambarkan berbagai diagram piranti
lunak. Setiap bentuk memiliki makna tertentu, dan UML syntax mendefinisikan bagaimana bentuk-
bentuk tersebut dapat dikombinasikan. Notasi UML terutama diturunkan dari 3 notasi yang telah ada
sebelumnya: Grady Booch OOD (Object-Oriented Design), Jim Rumbaugh OMT (Object Modeling
Technique), dan Ivar Jacobson OOSE (Object-Oriented Software Engineering).

Berikut adalah sejarah perkembangan UML dari Unified Method 0.8 hingga UML 2.1. UML dimulai
secara resmi pada Oktober 1994, ketika Rumbaugh menggabungkan kekuatan dengan Booch. Mereka
berdua lalu bekerja bersama di Relational Software Cooperation. Proyek ini memfokuskan pada
penyatuan metode booch dan Rumbaugh(OMT). Pada bulan October 1995, UML merilis versi 0.8 dan
pada waktu yang sama juga Jacobson bergabung dengan Relational. Cakupan dari UML pun semakin
meluas. Kemudian dibangunlah persatuan untuk UML dengan beberapa organisasi yang akan
menyumbangkan sumber dayanya untuk bekerja, mengembangkan,dan melengkapi
UML.Banyak partner yang berkontribusi pada UML 1.0, diantaranya Digital Equipment Corporation,
Hawlett-Packard, I-Logix, IBM, ICON Computing, MCI systemhouse, Microsoft, Oracle, Relation, Texas
Insturments dan Unisys. Dari kolaborasi ini dihasilkan UML 1.0 yang merupakan bahasa pemodelan
yang ditetapkan secara baik, expressive, kuat dan cocok untuk lingkungan masalah yang luas. Dan
pada January 1997, UML dijadikan sebagai standar bahasa pemodelan.
Sistem dunia nyata apa pun digunakan oleh pengguna yang berbeda. Pengguna dapat menjadi
pengembang, penguji, pebisnis, analis, dan banyak lagi. Oleh karena itu, sebelum merancang suatu
sistem, arsitektur dibuat dengan perspektif yang berbeda dalam pikiran. Bagian terpenting adalah
memvisualisasikan sistem dari perspektif pemirsa yang berbeda. Semakin baik kita memahami,
semakin baik kita dapat membangun sistem. UML memainkan peran penting dalam mendefinisikan
perspektif yang berbeda dari suatu sistem. Perspektif ini adalah - Desain Pelaksanaan Proses
Penyebaran Pusatnya adalah tampilan Use Case yang menghubungkan keempatnya. Use Case
mewakili fungsionalitas sistem. Oleh karena itu, perspektif lain terhubung dengan use case. Desain
sistem terdiri dari kelas, antarmuka, dan kolaborasi. UML menyediakan diagram kelas, diagram objek
untuk mendukung ini. Implementasi mendefinisikan komponen yang dirangkai bersama untuk
membuat sistem fisik yang lengkap. Diagram komponen UML digunakan untuk mendukung perspektif
implementasi. Proses mendefinisikan aliran sistem. Oleh karena itu, elemen yang sama seperti yang
digunakan dalam Desain juga digunakan untuk mendukung perspektif ini. Deployment
merepresentasikan node fisik dari sistem yang membentuk perangkat keras. Diagram penggunaan
UML digunakan untuk mendukung perspektif ini.
Standar UML saat ini memanggil 13 jenis diagram yang berbeda: kelas, aktivitas, objek, use case,
urutan, paket, status, komunikasi, struktur komposit, tinjauan interaksi, pengaturan waktu, dan
penyebaran.

Diagram ini disusun dalam dua kelompok berbeda: diagram struktural dan diagram perilaku atau
interaksi.

Struktur diagram UML

Diagram kelas Diagram aktivitas

Diagram paket Diagram urutan
Diagram objek Gunakan diagram kasus
Diagram komponen Diagram negara
Diagram struktur komposit Diagram komunikasi
Diagram penyebaran Diagram ikhtisar interaksi
Diagram UML perilaku Diagram waktu

Analisis dan proses desain UML yaitu:

System Development UML, yaitu:

8.2.2 Class Diagram

Class adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan sebuah objek dan
merupakan inti dari pengembangan dan desain berorientasi objek. Class menggambarkan keadaan
(atribut/properti) suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut
(metoda/fungsi). Class diagram menggambarkan struktur dan deskripsi class, package dan objek
beserta hubungan satu sama lain seperti containment, pewarisan, asosiasi, dan lain-lain.

Class memiliki tiga area pokok :

1. Nama (dan stereotype)

2. Atribut

3. Metoda

Atribut dan metoda dapat memiliki salah satu sifat berikut :

 Private, tidak dapat dipanggil dari luar class yang bersangkutan.

 Protected, hanya dapat dipanggil oleh class yang bersangkutan dan anak-anak yang
mewarisinya.

 Public, dapat dipanggil oleh siapa saja

Relationships of Class

There three types of relationship :

1. Is-a (Generalization, Realization: Inheritance)

2. Has-a (Association)

3. Others (Association , Dependency)

Multiplicity of Class

Indikator Variabel Class Diagram

+ Public

# Protected

- Private

$ Static

/ Drived Atribut tidak standar

* Abstrak Fungsi tidak standar

8.3 Latihan
1. Jelaskan pengertian UML?
Jawab:

2. Jelaskan arsitektur UML perbagiannya!

Jawab:

3. Berikan contoh pemetaan transformasi dan pemetaan transaksi pada desain arsitektur!
Jawab:
DAFTAR PUSTAKA

• Pressman, RS., 2008, Software Engineering: A Practitioner’s Approach, New York: McGraw-
Hill

• Sommerville, I, 2007, Software Engineering,Addsion Wesley

• “Belajar Unified Modeling Language (UML)”. https://www.codepolitan.com/unified-

modeling-language-uml
 Modul 9 : System Testing
9.1 Tujuan
Mahasiswa mampu menguji dan memelihara rencana pembangunan sistem yang telah dibuat
sebelumnya.

9.2 Dasar Teori

9.2.1 Dasar-dasar Pengujian Sistem
a. System Testing : Pengujian terhadap integrasi sub-system, yaitu keterhubungan antar sub-
system.
b. Acceptance Testing
 Pengujian terakhirs sebelum sistem dipakai oleh user.
 Melibatkan pengujian dengan data dari pengguna sistem.
 Biasa dikenal sebagai “alpha test” (“beta test” untuk software komersial, dimana
pengujian dilakukan oleh potensial customer).

c. Component Testing
- Pengujian komponen-komponen program.
- Biasanya dilakukan oleh component developer (kecuali untuk system kritis)
d. Integration Testing
- Pengujian kelompok komponen-komponen yang terintegrasi untuk membentuk sub-
system ataupun system
- Dialakukan oleh tim penguji yang independent
- Pengujian berdasarkan spesifikasi sistem

9.2.1.1 Rencana Pengujian

• Proses testing : Deskripsi fase-fase utama dalam pengujian.
• Pelacakan Kebutuhan : Semua kebutuhan user diuji secara individu.
• Item yg diuji : Menspesifikasi komponen sistem yang diuji.
• Jadwal Testing.
• Prosedur Pencatatan Hasil dan Prosedur.
• Kebutuhan akan Hardware dan Software.
• Kendala-kendala : Mis: kekuranga staff, alat, waktu dll.

9.2.1.2 Test Data dan Kasus Test

a. Test Data : Input yang direncanakan digunakan oleh sistem.
b. Test Cases : Input yang digunakan untuk menguji sistem dan memprediksi output dari input
jika sistem beroperasi sesuai dengan spesifikasi.
9.2.2 Kualitas Perangkat Lunak
Kualitas perangkat lunak dapat dinilai melalui ukuran-ukuran dan metode-metode tertentu, serta
melalui pengujian-pengujian software. Salah satu tolak ukur kualitas perangkat lunak adalah ISO 9126,
yang dibuat oleh International Organization for Standardization (ISO) dan International
Electrotechnical Commission (IEC). ISO 9126 mendefinisikan kualitas produk perangkat lunak, model,
karakteristik mutu, dan metrik terkait yang digunakan untuk mengevaluasi dan menetapkan kualitas
sebuah produk software. Standar ISO 9126 telah dikembangkan dalam usaha untuk mengidentifikasi
atribut-atribut kunci kualitas untuk perangkat lunak komputer. Faktor kualitas menurut ISO 9126
meliputi enam karakteristik kualitas sebagai berikut:

1. Functionality (Fungsionalitas). Kemampuan perangkat lunak untuk menyediakan fungsi sesuai

kebutuhan pengguna, ketika digunakan dalam kondisi tertentu.
2. Reliability (Kehandalan). Kemampuan perangkat lunak untuk mempertahankan tingkat kinerja
tertentu, ketika digunakan dalam kondisi tertentu.
3. Usability (Kebergunaan). Kemampuan perangkat lunak untuk dipahami, dipelajari, digunakan,
dan menarik bagi pengguna, ketika digunakan dalam kondisi tertentu.
4. Efficiency (Efisiensi). Kemampuan perangkat lunak untuk memberikan kinerja yang sesuai dan
relatif terhadap jumlah sumber daya yang digunakan pada saat keadaan tersebut.
5. Maintainability (Pemeliharaan). Kemampuan perangkat lunak untuk dimodifikasi. Modifikasi
meliputi koreksi, perbaikan atau adaptasi terhadap perubahan lingkungan, persyaratan, dan
spesifikasi fungsional.
6. Portability (Portabilitas). Kemampuan perangkat lunak untuk ditransfer dari satu lingkungan
ke lingkungan lain.

9.2.3 Jaminan Mutu Sistem

Jaminan kualitas perangkat lunak (Software Quality Assurance/SQA) adalah aktivitas pelindung yang
diaplikasikan pada seluruh proses perangkat lunak.

SQA meliputi :

1. Pendekatan manajemen kualitas.

2. Teknologi rekayasa perangkat lunak yang efektif (metode dan pirantinya).

3. Kajian teknik formal yang diaplikasikan pada keseluruhan proses perngakat lunak.

4. Strategi pengujian multitiered (deret bertingkat).

5. Kontrol dokumentasi perangkat lunak dan perubahan yang dibuat untuknya.

6. Prosedur untuk menjamin kesesuaian dengan standar pengembangan perangkat lunak (bila
dapat diaplikasikan).
7. Mekanisme pengukuran dan pelaporan.

Kualitas perangkat lunak didefinisikan sebagai : Konformansi terhadap kebutuhan fungsional dan
kinerja yang dinyatakan secara eksplisit, standar perkembangan yang didokumentasikan secara
eksplisit, dan karakteristik implisit yang diharapkan bagi semua perangkat lunak yang dikembangkan
secara profesional. Definisi tersebut berfungsi untuk menekankan tiga hal penting, yaitu:

8. Kebutuhan perangkat lunak merupakan fondasi yang melaluinya kualitas diukir.

9. Standar yang telah ditentukan menetapkan serangkaian kriteria pengembangan yang menuntun
cara perangkat lunak direkayasa.

10. Ada serangkaian kebutuhan implisit yang sering tidak dicantumkan.

9.2.4 Black Box Testing

Pendekatan pengujian dimana program dianggap sebagai suatu ‘black-box’ (‘kotak hitam’). Program
test case berbasiskan spesifikasi. Test planning dapat dimulai sejak awal proses pengembangan
system.

9.2.5 White Box Testing

Sering disebut Structural testing. Penentuan test case disesuaikan dengan struktur sistem. Knowledge
program digunakan untuk mengindentifikasi test case tambahan. Tujuannya untuk menguji semua
statemet program (debug).
9.2.6 UAT (User Acceptance Test)
User Acceptance Testing (UAT) merupakan proses verifikasi bahwa solusi yang dibuat dalam sistem
sudah sesuai untuk pengguna. Proses ini berbeda dengan pengujian sistem (memastikan software
tidak crash dan sesuai dengan dokumen permintaan pengguna), melainkan memastikan bahwa solusi
dalam sistem tersebut akan bekerja untuk pengguna (yaitu, tes bahwa pengguna menerima solusi di
dalam sistem).

UAT umumnya dilakukan oleh klien atau pengguna akhir, biasanya tidak fokus pada identifikasi
masalah sederhana seperti kesalahan ejaan, maupun di cacat showstopper, seperti crash perangkat
lunak. Penguji dan pengembang mengidentifikasi dan memperbaiki masalah ini selama tahap awal
pengujian fungsionalitas, pengujian saat integrasi dan pada tahap sistem testing.

Jenis UAT terdiri dari:

a. Alpha & Beta Testing

b. Contract Acceptance Testing
c. Regulation Acceptance Testing
d. Operational Acceptance Testing
e. Black Box Testing

UAT untuk berorientasi objek diambil dari use case diagram (untuk generalisasi: cukup menerangkan
child/anak/spesifikasi nya bukan parent/induk/general nya) sedangkan untuk terstruktur diambil
dari DFD level terkecil.
UAT menggunakan data yang berkesinambungan antara use case (fungsi/proses) yang satu dengan
yang lain dari awal hingga akhir.

9.2.7 Alpha and Beta Testing

Fase Pengujian Alfa dan Beta terutama berfokus pada penemuan produk dan produk yang telah
mereka berikan gambaran yang jelas tentang bagaimana produk tersebut benar-benar digunakan oleh
pengguna waktu nyata. Mereka juga membantu dalam pengalaman pelatihan dengan produk sebelum
diluncurkan dan umpan balik yang berharga diterapkan secara efektif untuk meningkatkan kegunaan
produk.

Tujuan dan metode Pengujian Alpha & Beta melakukan peralihan di antara mereka sendiri
berdasarkan proses yang diikuti oleh proyek dan dapat disesuaikan agar sejalan dengan proses.
Kedua teknik pengujian ini telah menghemat ribuan dolar untuk rilis perangkat lunak berskala besar
untuk perusahaan seperti Apple, Google, Microsoft, dll.

9.2.7.1 Aplha Testing

Pengujian alfa adalah salah satu strategi pengujian perangkat lunak yang paling umum digunakan
dalam pengembangan perangkat lunak. Terutama digunakan oleh organisasi pengembangan produk.

Tes ini berlangsung di situs pengembang. Pengembang mengamati pengguna dan mencatat masalah.
Pengujian alfa adalah pengujian aplikasi saat pengembangan akan selesai. Perubahan desain kecil
masih dapat dilakukan sebagai hasil dari pengujian alfa. Pengujian alfa biasanya dilakukan oleh grup
yang tidak bergantung pada tim desain, tetapi masih dalam perusahaan, mis. insinyur pengujian
perangkat lunak in-house, atau insinyur QA perangkat lunak.
Pengujian alfa adalah pengujian akhir sebelum perangkat lunak dirilis ke masyarakat umum. Ini
memiliki dua fase:
1. Pada tahap pertama pengujian alfa, perangkat lunak diuji oleh pengembang in-house. Mereka
menggunakan perangkat lunak debugger, atau debugger yang dibantu perangkat keras.
Tujuannya adalah untuk menangkap bug dengan cepat.
2. Pada tahap kedua pengujian alfa, perangkat lunak diserahkan kepada staf QA perangkat lunak,
untuk pengujian tambahan dalam lingkungan yang mirip dengan penggunaan yang dimaksudkan.

Pengujian alfa adalah simulasi atau pengujian operasional aktual oleh calon pengguna / pelanggan
atau tim uji independen di situs pengembang. Pengujian alfa sering digunakan untuk perangkat lunak
off-the-shelf sebagai bentuk pengujian penerimaan internal, sebelum perangkat lunak digunakan
untuk pengujian beta.

Diagram berikut menjelaskan fitment pengujian Alpha dalam siklus hidup pengembangan perangkat
lunak.

Pada tahap pertama pengujian alfa, perangkat lunak diuji oleh pengembang internal yang tujuannya
adalah untuk menangkap bug dengan cepat.

Pada tahap kedua pengujian alfa, perangkat lunak diberikan kepada tim QA perangkat lunak untuk
pengujian tambahan.
Pengujian alfa sering dilakukan untuk perangkat lunak Off-the-shelf komersial (COTS) sebagai bentuk
pengujian penerimaan internal, sebelum pengujian beta dilakukan.

9.2.7.2 Beta Testing

Pengujian Beta juga dikenal sebagai pengujian lapangan. Ini terjadi di situs pelanggan. Ini mengirimkan
sistem / perangkat lunak kepada pengguna yang menginstalnya dan menggunakannya di bawah
kondisi kerja dunia nyata.

Tes beta adalah tahap kedua pengujian perangkat lunak di mana sampling dari audiens yang dituju
mencoba produk tersebut. (Beta adalah huruf kedua dari alfabet Yunani.) Awalnya, istilah pengujian
alpha berarti tahap pertama pengujian dalam proses pengembangan perangkat lunak. Tahap pertama
meliputi pengujian unit, pengujian komponen, dan pengujian sistem. Pengujian beta dapat dianggap
"pengujian pra-rilis.

Tujuan pengujian beta adalah menempatkan aplikasi Anda di tangan pengguna nyata di luar tim teknis
Anda sendiri untuk menemukan kekurangan atau masalah apa pun dari perspektif pengguna yang
tidak ingin Anda miliki dalam versi aplikasi final yang dirilis. Contoh: Microsoft dan banyak organisasi
lain merilis versi beta dari produk mereka untuk diuji oleh pengguna.

Diagram berikut menjelaskan kecocokan pengujian Beta dalam siklus hidup pengembangan perangkat
lunak:
9.3 Latihan
1. Jelaskan karakteristik kualitas perangkat lunak!
Jawab:

2. Jelaskan Black Box Testing serta berikan contohnya!

Jawab:

3. Jelaskan White Box Testing sertakan contohnya!

Jawab:
DAFTAR PUSTAKA

• “Kualitas Perangkat Lunak Model ISO 9126”. http://fxekobudi.net/ilmu-komputer/kualitas-

perangkat-lunak-model-iso-9126/

• “BAB 8 Jaminan Kualitas Perangkat Lunak Software Quality Assurance [SQA]”.

http://wsilfi.staff.gunadarma.ac.id/Downloads/files/24049/Jaminan+Kualitas+PL.pdf

• “Panduan Dokumen User Acceptance Test (UAT)”. http://dac.telkomuniversity.ac.id/wp-

content/uploads/2015/06/PAKA06A-Panduan-User-Acceptance-Test-UAT-20170410.pdf

• “AlphaTesting”.https://www.tutorialspoint.com/software_testing_dictionary/alpha_testin
g.htm

• “BetaTesting”.https://www.tutorialspoint.com/software_testing_dictionary/beta_testing.h
tm
 Modul 10 : System Maintenance
10.1 Tujuan
Mahasiswa mampu menguji dan memelihara rencana pembangunan sistem yang telah dibuat
sebelumnya.

10.2 Dasar Teori

10.2.1 Konsep Pemeliharaan Perangkat Lunak
Pemeliharaan Software adalah proses umum pengubahan/pengembangan perangkat lunak setelah
diserahkan ke konsumen. Perubahan mungkin berupa perubahan sederhana untuk membetulkan
error koding atau perubahan yg lebih ekstensif untuk membetulkan error perancangan/perbaikan
signifikan untuk membetulkan error spesifikasi/akomodasi persyaratan baru.
Merupakan siklus terakhir dari SDLC yaitu dengan pemeriksaan periodik, audit dan permintaan
pengguna akan menjadi source untuk melakukan perawatan system diseluruh masa hidup system.
Istilah pemeliharaan perangkat lunak digunakan untuk menjabarkan aktivitas dari analis sistem
(software engineering) yang terjadi pada saat hasil produk perangkat lunak sudah dipergunakan oleh
pemakai (user).

Biasanya pengembangan produk perangkat lunak memerlukan waktu antara 1 sampai dengan 2
tahun, tetapi pada fase pemeliharaan perangkat lunak menghabiskan 5 sampai dengan 10 tahun.
Aktivitas yang terjadi pada fase pemeliharaan antara lain:
1. Penambahan atau peningkatan atau juga perbaikan untuk produk perangkat lunak
2. Adaptasi produk dengan lingkungan mesin yang baru
3. Pembetulan permasalahan yang timbul

10.2.1.1 Tujuan dari pemeliharaan system

1. Untuk memperpanjang usia kegunaan asset dari system tersebut.
2. Untuk menjamin ketersediaan optimum peralatan.
3. Untuk menjamin kesiapan operasional dari seluruh peralatan yang diperlukan dalam
keadaan darurat setiap waktu.
4. Untuk menjamin keselamatan orang yang menggunakan sarana tersebut

10.2.1.2 Siklus Hidup Pemeliharaan Sistem (SMLC)

1. Memahami Permintaan Pemeliharaan.
2. Mentransformasi permintaan pemeliharaan menjadi pengubahan.
3. Menspesifikasi perubahan.
4. Mengembangkan perubahan.
5. Menguji perubahan.
6. Melatih pengguna dan melakukan test penerimaan.
7. Pengkonversian dan meluncurkan operasi.
8. Mengupdate Dokumen.
9. Melakukan pemeriksaan Pasca implementasi.

10.2.1.3 Tiga pendekatan untuk menyusun Pemeliharaan sistem :

1. Pendekatan Pemisahan : Pemeliharaan dan Pemeliharaan
2. Pendekatan Gabungan : Menggabungkan personalia penyusun dan pemelihara menjadi
sebuah kelompok utama sistem informasi.
 3. Pendekatan Fungsional : Variasi dari pendekatan gabungan dengan memindahkan tenaga
profesional sistem dari sistem informasi dan menugasi mereka pada fungsi bisnis untuk
penyusunan maupun pemeliharaan.

10.2.2 Teknik Pemeliharaan Perangkat Lunak

Pemeliharaan sistem dapat digolongkan menjadi empat jenis :
1. Pemeliharaan Korektif
2. Pemeliharaan Adaptif
3. Pemeliharaan Perfektif (Penyempurnaan)
4. Pemeliharaan Preventif

10.2.2.1 Pemeliharaan Korektif (Corrective Maintenance)

Pemeliharaan korektif adalah bagian pemeliharaan sistem yang tidak begitu tinggi nilainya dan lebih
membebani, karena pemeliharaan ini mengkoreksi kesalahan-kesahan yang ditemukan pada saat
sistem berjalan. Umumnya pemeliharaan korektif ini mencakup kondisi penting atau bahaya yang
memerlukan tindakan segera. Kemampuan untuk mendiagnosa atau memperbaiki kesalahan atau
malfungsi dengan cepat sangatlah berharga bagi perusahaan.

10.2.2.2 Pemeliharaan Adaptif (Adaptive Maintenance)

Pemeliharaan adaptif dilakukan untuk menyesuaikan perubahan dalam lingkungan data atau
pemrosesan dan memenuhi persyaratan pemakai baru. Lingkungan tempat sistem beroperasi adalah
dinamik, dengan demikian, sistem harus terus merespon perubahan persyaratan pemakai. Misalnya,
Undang-Undang Perpajakan yang baru mungkin memerlukan suatu perubahan dalam kalkulasi
pembayaran bersih. Umumnya pemeliharaan adatif ini baik dan tidak dapat dihindari.

10.2.2.3 Pemeliharaan Perfektif/Penyempurnaan (Perfective Maintenance)

Pemeliharaan penyempurnaan mempertinggi cara kerja atau maintainabilitas (kemampuan untuk
dipelihara). Tindakan ini juga memungkinkan sistem untuk memenuhi persyaratan pemakai yang
sebelumnya tidak dikenal. Ketika membuat perubahan substansial modul apapun, petugas
pemeliharaan juga menggunakan kesempatan untuk mengupgrade kode, mengganti cabang-cabang
yang kadaluwarsa, memperbaiki kecerobohan, dan mengembangkan dokumentasi. Sebagai contoh,
kegiatan pemeliharaan ini dapat berbentuk perekayasaan ulang dan isi laporan, penentuan logika
pemrosesan yang lebih efisien, dan pengembangan efisiensi pengoperasian perangkat.

10.2.2.4 Pemeliharaan Preventif (Preventif Maintenance)

Pemeliharaan Preventif terdiri atas inspeksi periodik dan pemeriksaan sistem untuk mengungkap dan
mengantisipasi permasalahan. Karena personil pemeliharaan sistem bekerja dalam sistem ini, mereka
seringkali menemukan cacat-cacat (bukan kesalahan yang sebenarnya) yang menandakan
permasalahan potensial. Sementara tidak memerlukan tindakan segera, cacat ini bila tidak dikoreksi
di tingkat awal, jelas sekali akan mempengaruhi baik fungsi sistem maupun kemampuan untuk
memeliharanya dalam waktu dekat.
10.3 Latihan
1. Jelaskan teknik pemeliharaan perangkat lunak?
Jawab:

2. Jelaskan konsep pemeliharaan perangkat lunak?

Jawab:

3. Jelaskan pendekatan untuk menyusun pemeliharaan sistem!

Jawab:

DAFTAR PUSTAKA

• Sundhawati,Dekha.”Konsep dan Teknik Pemeliharaan Perangkat

Lunak”.https://www.google.co.id/search?q=Pemeliharaan+Perangkat+Lunak
 Modul 11 : Validasi RPL

11.1 Tujuan
Mahasiswa mampu menguji dan memelihara rencana pembangunan sistem yang telah dibuat
sebelumnya.

11.2 Dasar Teori

11.2.1 Membangun RPL Sistem Multimedia
Untuk membangun kepercayaan diri, bahwa software yang dibangun sesuai dengan tujuan
pembuatannya. Validation testing adalah ditujukan untuk menunjukan bahwa software yang dibuat
sesuai dengan keinginan customer.
1. Verfication: “doing the thing right”.
2. Validation: “doing the right thing”.
3. Verifikasi : memastikan bahwa software yang didesain dapat memenuhi semua fungsi yang
dibutuhkan customer.
4. Validasi : memastikan fungsi dari software yang sudah dibangun sesuai dengan requirement.
Validasi dilakukan setelah verifikasi. Verifikasi & Validasi adalah proses yang bertujuan untuk
menemukan keberadaan defect dalam sebuah software. Proses verifikasi dan validasi adalah
keseluruhan proses daur hidup V & V harus diterapkan pada setiap tahapan dalam proses software.
Mempunyai dua obyektif principal :
1. Menemukan kekurangan dalam sebuah system.
2. Memperkirakan apakah sistem berguna dan dapat digunakan atau tidak dalam situasi
operasional.

11.2.1.1 Tujuan Verifikasi dan Validasi

1. Verifikasi dan validasi harus memberikan kepastian bahwa software sesuai dengan tujuannya.
2. Hal ini bukan berarti benar-benar bebas dari kekurangan.
3. Harus cukup baik untuk tujuan penggunaannya dan tipe dari penggunaan akan menentukan
derajat kepastian yang dibutuhkan.

11.2.1.2 Kepastian Verifikasi dan Validasi

Tergantung pada tujuan sistem, harapan user dan lingkungan pemasaran

1. Fungsi Software : Tingkatkepastian tergantung pada bagaimana kritikal software terhadapa

sebuah organisasi.
2. Harapan User : User mungkin mempunyai harapan yang rendah terhadap software yang ada.
3. Lingkungan pemasaran : Lebih awal melempar sebuah produk ke pasar lebih penting daripada
menemukan kekurangan dalam program.

11.2.1.3 Verifikasi Statik dan Dinamik

Software inspection. Berhubungan dengan analisis representasi sistemstatik untuk menemukan
masalah (verifikasi statik). Dapat menjadi tambahan dari tool-based document dan code analysis.

Software testing. Berhubungan dengan pelaksanaan dan memperhatikan perilaku produk (dinamik
verifikasi). Sistem dijalankan dengan data tes dan perilaku operasionalnya diperhatikan.
11.2.1.4 Pengujian Program
Dapat mengungkapkan keberadaan kesalahan bukan ketidakberadaannya. Hanya teknik validasi
untuk persyaratan non-functional sebagai sebuah software dapat dijalankan untuk melihat bagaimana
perilakunya. Harusnya digunakan dalam hubungannya dengan verifikasi statik untuk menyediakan
penanganan Verifikasi &Validasi yang menyeluruh. Terdapat beberapa tipe pengujian :

1. Pengujian Kekurangan : Test dirancang untuk menemukan kekurangan sistem. Uji

kekurangan yang berhasil salah satunya adalah menunjukkan keberadaan kekurangan dalam
sebuah system.
2. Pengujian Validasi : Ditujukan untuk memperlihatkan bahwa software sesuai dengan
persyaratannya. Tes yang berhasil adalah salahsatu yang menunjukkan bahwa persyaratan
telah diterapkan secara tepat

Pengembangan Model Verifikasi

Berikut ini merupakan skema pengembangan model verifikasi, yaitu:
11.3 Latihan
1. Jelaskan tujuan validasi dan verifikasi!
Jawab:

2. Jelaskan verifikasi statik dan dinamik!

Jawab:

3. Jelaskan pengembangan model verifikasi!

Jawab:

DAFTAR PUSTAKA

• Roger S Pressman,”Software Enginering: A Practitioners Approach”

• Bob Hughes,”Software Project Management”.