Kontrak Perkuliahan RPL

Pertemuan Pokok Bahasan

1 Perangkat Lunak dan Rekayasa Perangkat Lunak
2 Model Proses Pengembangan Perangkat Lunak
3 Kebutuhan Perangkat Lunak
4 Konsep Perancangan
5 Desain Interface
6 Pemodelan Sistem dengan UML
7 Review/Kuis Pertemuan 1 – 6
8 UTS
9 Perancangan Berorientasi Objek
10 Disain Arsitektur
11 Desain Web
12 Pengujian Perangkat Lunak
13 Pengujian Aplikasi Web
14 Implementasi dan Pemeliharaan
15 Review/Kuis Pertemuan 9 – 14
16 UAS
 Referensi
Bell, Douglas. 2005. Software Engineering for Students, 4th. London: Addison-
Wesley.
Booch, Grady. James Rumbaugh. and Ivar Jacobson. 1999. Unified Modeling
Language User Guide. Canada: Addison-Wesley.
Dennis, Alan. Barbara Haley Wixom . And David Tegarden. 2015. Systems analysis
& design : an object-oriented approach with UML 5th. USA: John Wiley &
Sons, Inc.
Fowler, Martin. 2004. UML Distilled: A Brief Guide to the Standard Object
Modeling Language, 3rd. USA: Addison-Wesley.
Lethbridge, Timothy C., Robert L. 2005. Object-Oriented Software Engineering, 2nd.
London: McGraw-Hill
Pressman, Roger S. and Bruce R. Maxim. 2015. Software Engineering: A
Practitioner’s Approach, 8th. New York: McGraw-Hill.
Shelly, Gary B. and Rosenblatt, Harry J. 2012. Systems Analysis and Design. 9th.
USA: Boston.
Simarmata, Janner. 2009. Rekayasa Perangkat Lunak. Yogyakarta: ANDI.
Sommerville. 2011. Software Engineering, 9th. USA: Addison-Wesley
 RENCANA PEMBELAJARAN
• Pertemuan 1 – 14 disampaikan dengan metode
ceramah, metode diskusi dan latihan soal.
• Mengerjakan soal latihan pada tiap pertemuan
perkuliahan
• Pertemuan 7 Review materi
• Pertemuan 15 Review materi
• Pertemuan 8 Ujian Tengah Semester (UTS)
• Pertemuan 16 Ujian Akhir Semester (UAS)
 Pertemuan 1

PERANGKAT LUNAK
dan
REKAYASA PERANGKAT
LUNAK
 Fokus Pembelajaran

1. Perangkat Lunak 4. Proses Perangkat Lunak

2. Karakteristik Perangkat 5. Praktek Perangkat Lunak
Lunak 6. Mitos-Mitos Perangkat
a. Kategori Perangkat Lunak Lunak
b. Jenis Perangkat Lunak a. Mitos Manajemen
c. Perangkat Lunak Warisan b. Mitos Pelanggan
d. Kegagalan PL c. Mitos Praktisi
3. Rekayasa Perangkat Lunak
 1. PERANGKAT LUNAK
Definisi Perangkat Lunak (PL) adalah:
• Instruksi-instruksi program komputer yang ketika dijalankan
menyediakan fitur-fitur, fungsi-fungsi dan kinerja yang
dikehendaki
• Struktur data yang memungkinkan program-program
memanipulasi informasi
• Informasi deskriptif pada salinan tercetak dan bentuk-bentuk
maya yang menggambarkan pengoperasian dan penggunaan
program
 2. KARAKTERISTIK PERANGKAT
LUNAK

• PL dikembangkan atau direkayasa, bukan

diproduksi dalam konteks manufaktur
• PL tidak mengalami “kelelahan”
• PL dibuat berdasarkan spesifikasi yang diminta
oleh pengguna
A. Kategori Perangkat Lunak
B. Jenis Perangkat Lunak Aplikasi
Jenis PL Aplikasi (Lanjutan)
 C. Perangkat Lunak Warisan

• PL warisan harus diadaptasikan sedemikian rupa sehingga

memenuhi kebutuhan dari lingkungan atau teknologi
komputasi yang baru
• PL warisan harus ditingkatkan kinerjanya supaya dapat
menjalankan kebutuhan bisnis baru
• PL warisan harus diperluas sedemikian rupa agar dapat
saling mengoperasikan dengan sistem/PL/basisdata modern
lainnya
• PL harus dirancang ulang sehingga dapat hidup dalam
lingkungan pengoperasian jaringan komputer
 D. Kegagalan Perangkat Lunak
Faktor-faktor penyebab kegagalan PL:
• Meningkatnya tuntutan
RPL membangun sistem yang lebih besar, sistem yang lebih
kompleks menyebabkan tuntutan berubah. Sistem harus
dibangun dan disampaikan lebih cepat, lebih besar, dan lebih
kompleks. Sistem harus memiliki kemampuan baru yang
sebelumnya dianggap mustahil.
• Harapan yang rendah
Hal ini relatif mudah untuk menulis program komputer tanpa
menggunakan metode dan teknik RPL. Banyak Pengusaha
yang tidak menggunakan metode RPL, akibatnya PL lebih
mahal dan kurang dapat diandalkan.
Stakeholder dalam RPL
3. REKAYASA PERANGKAT LUNAK (RPL)

• RPL adalah disiplin teknik yang berkaitan dengan semua

aspek produksi PL dari tahap awal spesifikasi sistem sampai
pemeliharaan.
• Aspek produksi RPL berkaitan dengan proses teknis dari
pengembangan PL, manajemen proyek PL dan
pengembangan alat-alat, metode, dan teori untuk mendukung
produksi PL.
• RPL merupakan aplikasi dari suatu pendekatan yang
semantik, disiplin, dan dapat diukur pada pengembangan,
operasi, dan perawatan PL.
 RPL (Lanjutan)

PL dalam segala bentuk aplikasinya harus direkayasa, dengan

alasan:
• PL telah menyatu secara maya dengan setiap aspek dalam
kehidupan
• Kebutuhan IT yang sudah banyak dituntut oleh individu, bisnis
dan pemerintah bertambah kompleks
• Individu, bisnis, dan pemerintah mengandalkan PL untuk
mengambil keputusan yang bersifat taktis dan strategis
• Nilai aplikasi terus bertambah, kemungkinan jumlah pengguna
dan usia PL akan bertambah
 4. PROSES PERANGKAT LUNAK
• Suatu proses merupakan sekumpulan aktivitas, aksi, dan tugas
yang dijalankan ketika suatu produk kerja harus dibuat.
• Sebuah proses PL adalah urutan kegiatan yang mengarah ke
produksi produk software.
• Empat kegiatan proses PL adalah:
a. Spesifikasi PL
b. Pengembangan PL
c. Software validasi
d. Software evolusi
 Proses PL (Lanjutan)

• Suatu aktivitas berupaya mencapai tujuan umum dan

diterapkan tanpa memperhatikan lingkungan aplikasi, tanpa
memperhatikan ukuran proyek, tanpa memperhatikan
kompleksitas dan usaha, dan tanpa memperhatikan kekakuan
dari RPL saat diterapkan.
• Suatu tugas konsentrasi pada tujuan yang kecil tetapi
terdefinisi dengan baik.
 Proses PL (Lanjutan)

• Kerangka kerja proses membangun dasar bagi proses RPL

yang lengkap dengan cara mengidentifikasikan aktivitas
kerangka kerja yang cocok untuk semua proses RPL.
• Kerangka kerja proses mencakup sekumpulan akitivitas yang
berperan sebagai penyangga dan cocok dengan keseluruhan
proses PL.
• Aktivitas kerangka kerja proses:
a. Komunikasi
b. Perencanaan
c. Pemodelan
d. Konstruksi
e. Penyerahan PL ke pelanggan/user
 Proses PL (Lanjutan)

• Aktivitas kerangka kerja proses RPL disempurnakan oleh

aktivitas yang bertindak sebagai penyangga.
• Kegiatan-kegiatan penyangga mencakup:
a. Penelusuran dan kendali proyek PL
b. Manajemen risiko
c. Penjaminan kualilitas PL
d. Tinjauan teknis
e. Pengukuran
f. Manajemen konfigurasi PL
g. Manajemen penggunaan ulang
h. Persiapan produk kerja dan produksi
 5. PRAKTEK RPL

Langkah-langkah RPL:
a. Memahami permasalahan
• Siapa yang terkait dalam pemecahan masalah?
• Apa saja yang tidak diketahui?
• Data, fungsi, dan fitur yang dibutuhkan
• Dapatkah masalah dikategorikan (dipecah menjadi
masalah yang lebih kecil)?
• Dapatkah masalah diwakili dengan grafis?
• Dapatkah dibuat sebuah model analisis?
 Praktek RPL (Lanjutan)

b. Merancang solusi
• Pernahkah ada masalah serupa sebelumnya dan telah
didapatkan pemecahan masalahnya?
• Dapatkah sub-masalah didefinisikan?
• Dapatkah menyusun solusinya?
 Praktek RPL (Lanjutan)

c. Menjalankan rancangan
• Apakah solusi cocok dengan masalah?
• Apakah kode program dapat dilacak secara langsung?
• Apakah komponen dari solusi sudah tepat?
d. Memeriksa hasil
• Uji setiap komponen dari solusi dengan menggunakan
strategi pengujian
• Apakah solusi sesuai dengan data, fungsi dan fitur yang
dibutuhkan?
 Prinsip-Prinsip Umum RPL
a. Alasan keberadaan PL
b. Sederhana
c. Pertahankan visi
d. Apa yang dibuat, akan digunakan oleh konsumen atau
pengguna
e. Membuka diri terhadap masa depan
f. Merancang selangkah ke depan sehingga dapat digunakan
kembali
g. Review
6. MITOS-MITOS PL

A. Mitos Manajemen
MITOS-1 Mitos Manajemen

Kita sudah memiliki buku

yang standar dan
prosedur untuk
membangun PL

Realita-1
Apakah buku tersebut mencerminkan
praktek RPL modern, lengkap, dan dapat
beradaptasi dengan keadaan yang
dihadapi saat ini?
 MITOS-2 Mitos Manajemen

Jika kita tertinggal dari

jadwal yang telah ditetap-
kan, kita dapat menambah
jumlah programmer dan
akan memenuhi jadwal
dengan cepat.

Realita-2
Menambah orang baru untuk proyek
PL yang tertunda menyebabkan
penyelesaian proyek PL tersebut
mejadi semakin terlambat.
 MITOS-3 Mitos Manajemen

Jika memutuskan untuk

menyewa orang ketiga
untuk mengerjakan proyek
PL, kita bisa sedikit lega
karena PL dikerjakan oleh
pihak ketiga

Realita-3
Jika sebuah organisasi tidak dapat
memahami cara mengelola dan
mengendalikan proyek PL secara
internal, maka organisasi tersebut akan
bekerja lebih keras lagi ketika
menyewa pihak ketiga.
B. Mitos Pelanggan
MITOS-1 Mitos Pelanggan

Realita-1
MITOS-2 Mitos Pelanggan

Realita-2
C. Mitos Praktisi
MITOS-1 Mitos Praktisi

Realita-1
MITOS-2 Mitos Praktisi

Realita-2
MITOS-3 Mitos Praktisi

Realita-3
 Pertemuan 2

MODEL PROSES
PENGEMBANGAN
PERANGKAT LUNAK
 Fokus Pembelajaran

1. Model Waterfall
2. Model Prototype
3. Model Spiral
4. Model RAD
5. Model Scrum
6. Contoh Studi Kasus dengan Model
Waterfall
 1. MODEL WATERFALL
• Model Waterfall juga disebut siklus hidup klasik (Classic
Life Cycle).
• Merupakan pendekatan sistematis dan berurutan (sequential)
pada PL yang dimulai dengan spesifikasi kebutuhan user dan
berlanjut melalui beberapa tahapan, dan diakhiri dengan
penyerahan sistem/ PL kepada pelanggan.
• Pada prinsipnya, hasil dari setiap tahap adalah satu atau lebih
dokumen yang disetujui (Sign off’).
• Tahap berikutnya tidak boleh dimulai sampai tahap
sebelumnya selesai.
 Model Waterfall

Sumber: Sommerville (2011: 30)

 Tahapan Model Waterfall

1. Requirements Analysis and Definition

Langkah ini merupakan analisa kebutuhan sistem. Berisi
layanan-layanan sistem, kendala, dan tujuan yang
ditetapkan melalui konsultasi dengan pengguna sistem,
kemudian didefinisikan secara rinci yang berfungsi sebagai
spesifikasi sistem.
 Tahapan Model Waterfall (lanjutan)

2. System and Software Design

Proses design mengalokasikan kebutuhan hardware dan
software untuk membangun arsitektur sistem secara
keseluruhan (struktur data, arsitektur PL, interface, dan
detail/algoritma prosedural). Proses design akan
menerjemahkan syarat kebutuhan perancangan PL yang
dapat diperkirakan sebelum dibuat coding.
 Tahapan Model Waterfall (lanjutan)

3. Implementation and Unit Testing

Perancangan PL direalisasikan
sebagai satu set program atau
unit program (coding).

Coding merupakan penerjemahan design dalam bahasa yang

bisa dikenali oleh komputer yang dilakukan oleh
programmer. Kemudian dilanjutkan dengan testing terhadap
pengujian unit dengan melibatkan verifikasi setiap unit agar
memenuhi spesifikasinya.
 Tahapan Model Waterfall (lanjutan)

4. Integration and System Testing

Program-program diintegrasikan dan diuji
sebagai sistem yang lengkap untuk memastikan
bahwa kebutuhan/persyaratan
PL telah dipenuhi. Setelah pengujian,
PL sistem dikirim ke pelanggan
 Tahapan Model Waterfall (lanjutan)

5. Operation and Maintenance

▪ Operasi dan pemeliharaan adalah siklus
hidup terlama.
▪ Sistem ini dipasang & digunakan user.
▪ Perawatan melibatkan koreksi
kesalahan yang tidak ditemukan
sebelumnya, meningkatkan
implementasi
sistem & meningkatkan
layanan sistem saat
persyaratan baru
ditemukan.
Kelebihan Model Waterfall:
Kekurangan Model Waterfall:
 2. MODEL PROTOTYPE
• Prototype adalah pendefinisian sejumlah sasaran PL
berdasarkan kebutuhan dan pemahaman secara umum, tetapi
tidak bisa mengidentifikasi kebutuhan secara rinci untuk
beberapa fungsi dan fitur-fitur.
• Tujuannya adalah untuk membantu dalam tahap analisis dan
desain yang memungkinkan pengguna untuk melihat lebih awal
apa yang akan dilakukan sistem, yaitu untuk memfasilitasi
validasi.
• Prototype dapat digunakan sebagai model proses yang berdiri
sendiri.
 Model Prototype (Lanjutan)

• Pembuatan prototype biasanya digunakan sebagai teknik yang

dapat diimplementasikan di dalam konteks setiap model proses
PL, sehingga membantu stakeholder untuk lebih memahami
apa yang akan dikembangkan ketika spesifikasi kebutuhan
belum jelas.
Model Prototype

Sumber: Pressman (2015: 45)

Tahapan dalam Model Prototype
Tujuan Pengembangan Model Prototype
 Manfaat Model Prototype
Model Prototype dikembangkan dan didemonstrasikan pada
awal proses pembangunan PL, sehingga dapat bermanfaat
untuk:
a. Menghindari kesalahpahaman antara pengembang PL dan
pengguna
b. Beberapa fasilitas yang hilang mungkin dapat terungkap
c. Fasilitas yang sulit digunakan/membingungkan dapat
diidentifikasi dan disempurnakan
d. Pengembang PL mungkin menemukan persyaratan yang
tidak lengkap atau tidak konsisten.
 Masalah pada Model Prototype
1. Stakeholder hanya melihat tampilan PL yang akan dipakai
tanpa mempedulikan bagaimana kerja sistem, dan
pemeliharaan jangka panjang.
2. Perubahan yang dibuat selama pengembangan PL mungkin
akan mengubah struktur arsitektur. Oleh karena itu mungkin
sulit dan mahal untuk pemeliharaannya.
3. Karakteristik sistem yang penting seperti kinerja, keamanan
dan keandalan, mungkin akan diabaikan selama pengembangan
PL.
4. Selama tahap pengembangan, Prototype akan diubah untuk
memenuhi kebutuhan pengguna. kemungkinan perubahan yang
dibuat akan tidak terkontrol dan tidak didokumentasikan
dengan baik.
 3. MODEL SPIRAL
• Model Spiral merupakan suatu model proses PL evolusioner
yang menggabungkan pendekatan prototyping yang bersifat
iteratif dengan aspek yang terkontrol dan sistematis pada
model waterfall.
• Model pengembangan spiral adalah model proses PL yang
dikendalikan risiko yang digunakan untuk memandu para
stakeholder untuk secara bersamaan merekayasa sistem yang
bernuansa PL.
 Model Spiral (Lanjutan)

• Model spiral menggunakan prototype sebagai mekanisme

pengurangan risiko.
• Model spiral menggunakan pendekatan langkah demi
langkah (waterfall) yang sistematis tetapi
menggabungkannya ke dalam kerangka iteratif yang lebih
realistis mencerminkan dunia nyata.
• Model spiral adalah pendekatan realistis untuk
pengembangan sistem berskala besar.
Model Spiral

Sumber: Pressman (2015: 48)

Penjelasan gambar:

a. Proses evolusioner ini dimulai dari titik tengah, ke bagian

luar spiral searah jarum jam.
b. Risiko PL akan dipertimbangkan saat masing-masing
gerakan dibuat dan titik pengukuran dicatat setiap saat
langkah-langkah evolusioner dilewati.
c. Lintasan pertama di sekitar spiral dapat menghasilkan
spesifikasi produk, putaran berikutnya di sekitar spiral
mungkin digunakan untuk mengembangkan suatu prototype
dan pada lintasan berikutnya secara progresif bergerak ke
versi PL yang semakin canggih.
Penjelasan gambar (lanjutan)

d. Setiap melewati lintasan menghasilkan penyesuaian pada

perencanaan proyek.
e. Biaya dan jadwal disesuaikan berdasarkan umpan balik
yang berasal dari pelanggan setelah pengiriman produk.
f. Selain itu, dilakukan penyesuaian jumlah iterasi yang
direncanakan untuk menyelesaikan produk PL.
Keuntungan
Model
Spriral
Kerugian Model Spriral
 4. MODEL Rapid Application
Development (RAD)
• RAD adalah teknik berbasis tim yang mempercepat
pengembangan SI dan menghasilkan fungsi-fungsi SI.
• RAD menggunakan pendekatan kelompok
• Produk akhir RAD adalah sistem informasi baru.
• RAD adalah metodologi yang lengkap, dengan 4 fase siklus
hidup yang sejajar dengan fase SDLC tradisional.
• Penggunaan RAD untuk mengurangi biaya dan waktu
pengembangan, dan meningkatkan probabilitas keberhasilan
 Model RAD (Lanjutan)

• RAD sangat bergantung pada prototype dan keterlibatan

pengguna.
• Berdasarkan input pengguna, prototype dimodifikasi dan proses
interaktif berlanjut sampai sistem benar-benar dikembangkan
dan pengguna puas.
• Interaksi berkelanjutan antara fase desain dan konstruksi
pengguna
• Tim proyek menggunakan CASE tools untuk membangun
prototype dan membuat aliran dokumentasi yang berkelanjutan.
Fase dan Aktivitas RAD

Sumber: Shelly (2012: 148)

Fase RAD
 Tujuan RAD
a. Mengurangi waktu dan biaya pengembangan dengan
melibatkan pengguna dalam setiap fase pengembangan sistem.
b. Membuat modifikasi yang diperlukan dengan cepat, seiring
dengan perkembangan desain.
c. Membatasi biaya perubahan yang biasanya terjadi dalam
jadwal pengembangan yang berlarut-larut.
d. Membutuhkan sistem informasi untuk mendukung fungsi
bisnis baru, karena digerakkan oleh pengguna.
e. Dengan input pengguna, membantu tim pengembangan
merancang sistem yang membutuhkan antarmuka pengguna
yang interaktif atau kompleks.
 Keuntungan dan Kerugian RAD
Keuntungan utama:
• sistem dapat dikembangkan lebih cepat dengan penghematan
biaya yang signifikan

Kerugian:
• Menekankan mekanisme sistem itu sendiri dan tidak
menekankan kebutuhan strategis bisnis perusahaan.
• Baik untuk jangka pendek.
• Memungkinkan lebih sedikit waktu untuk mengembangkan
kualitas, konsistensi, & standar desain.
• RAD dapat menjadi alternatif yang menarik, jika suatu
organisasi memahami risiko yang mungkin terjadi
 5. MODEL SCRUM

• Scrum adalah sebuah proses yang agile untuk menangani

produk yang kompleks.
• Scrum digunakan untuk memandu kegiatan pengembangan
dalam suatu proses yang mencakup kerangka kerja seperti:
kebutuhan, analisis, desain, evolusi, dan pengiriman.
• Scrum menekankan penggunaan seperangkat pola proses PL
yang telah terbukti efektif untuk proyek dengan jadwal yang
ketat, perubahan kebutuhan, dan kekritisan bisnis
Tahapan
Pengembangan
Scrum
 Model Scrum

Sumber: Pressman (2015:78)

 Penjelasan gambar
a. Gagasan awal adalah bahwa seluruh tim harus
diberdayakan untuk membuat keputusan sehingga istilah
‘Manajer Proyek', telah dengan sengaja dihindari.
b. Scrum Master adalah seorang fasilitator yang mengatur
• pertemuan harian
• melacak backlog dari pekerjaan yang harus dilakukan
• mencatat keputusan
• mengukur kemajuan terhadap backlog
• berkomunikasi dengan pelanggan dan manajemen di
luar tim
 Penjelasan gambar (lanjutan)

c. Seluruh tim menghadiri pertemuan harian, agar tetap fokus

pada tugas masing-masing.
d. Selama pertemuan, semua anggota tim berbagi informasi,
melaporkan kemajuan mereka sejak pertemuan terakhir,
menjelaskan masalah yang muncul, dan apa yang
direncanakan untuk hari berikutnya.
e. Ini berarti bahwa semua orang di tim tahu apa yang sedang
terjadi, dan jika masalah muncul, dapat saling membanttu.
f. Semua orang berpartisipasi dalam perencanaan jangka
pendek ini.
Keuntungan Model Scrum
 Model V-Model

• Model V-Model adalah model pengembangan perangkat

lunak yang menggabungkan antara pengembangan
perangkat lunak dengan pengujian perangkat lunak.
• Model ini sering juga disebut sebagai Verification and
Validation Model atau V-Model.
• Pada Model V-Model, proses pengembangan perangkat
lunak dan pengujian perangkat lunak dijalankan secara
bersamaan.
• Proses pengembangan perangkat lunak yang dilakukan pada
Model V-Model terdiri dari beberapa tahapan, antara lain:
➢ Requirements Analysis: Pada tahap ini, kebutuhan
fungsional dan non-fungsional dari perangkat lunak dianalisis
dan didokumentasikan. Dokumen kebutuhan ini akan menjadi
acuan bagi seluruh tahap selanjutnya.
➢ Sistem Design: Pada tahap ini, perangkat lunak dirancang
arsitektur secara keseluruhan, termasuk arsitektur perangkat
lunak, kebutuhan perangkat keras dan perangkat lunak, serta
spesifikasi teknis lainnya.
➢ Architectural Design: Pada tahap ini, arsitektur perangkat
lunak dirancang secara lebih detail. Seluruh komponen
perangkat lunak dijelaskan dengan baik.
➢ Module Design: Pada tahap ini, modul-modul yang
dibutuhkan oleh perangkat lunak dirancang secara detail,
termasuk spesifikasi teknis untuk masing-masing modul.
➢ Implementation: Pada tahap ini, perangkat lunak
dikembangkan dengan mengikuti rancangan yang telah
disepakati pada tahap sebelumnya.
➢ Testing: Pada tahap ini, perangkat lunak diuji secara
menyeluruh untuk memastikan bahwa perangkat lunak
berjalan dengan baik dan sesuai dengan kebutuhan.
➢ Deployment: Pada tahap ini, perangkat lunak siap untuk
digunakan dan diinstal pada lingkungan yang ditargetkan.
➢ Maintenance: Pada tahap ini, perangkat lunak dipelihara dan
diperbaiki untuk memastikan bahwa perangkat lunak tetap
berjalan dengan baik.
• Dalam Model V-Model, tahapan pengembangan perangkat
lunak dan pengujian perangkat lunak berjalan secara
bersamaan.
• Setiap tahapan pengembangan perangkat lunak dipasangkan
dengan tahapan pengujian perangkat lunak yang sesuai.
• Hal ini memastikan bahwa perangkat lunak yang dihasilkan
sudah sesuai dengan kebutuhan dan telah diuji dengan baik
sejak awal pengembangan.
 Kelebihan Model V-Model

• mampu memastikan kualitas perangkat lunak secara keseluruhan,

karena setiap tahap pengembangan perangkat lunak dipasangkan
dengan tahap pengujian perangkat lunak yang sesuai.
• Model ini juga memberikan kejelasan dan struktur yang baik
dalam proses pengembangan perangkat lunak

Kekurangan Model V-Model

• proses pengembangan dan pengujian perangkat lunak yang
cukup kompleks dan memerlukan banyak sumber daya.
• Model ini kurang fleksibel dalam mengakomodasi perubahan
kebutuhan pelanggan atau keadaan lingkungan.
 Model Iterative-Incremental

• Model Iterative-Incremental adalah pemodelan perangkat

lunak yang menggabungkan antara model waterfall dan
model spiral.
• Model ini dilakukan secara iteratif dan terus menerus dengan
menggunakan pendekatan incremental.
• Pada setiap iterasi, model iterative-incremental
mengembangkan produk yang dapat berdiri sendiri, tetapi
terus mengintegrasikan dengan produk iterasi sebelumnya.
• Proses pengembangan pada model ini dimulai dengan
melakukan analisis kebutuhan, kemudian desain,
implementasi, dan pengujian.
 Model Iterative-Incremental

• Selama pengembangan produk, pengembar akan melakukan

evaluasi setiap kali iterasi selesai.
• Hasil evaluasi akan digunakan untuk memperbaiki dan
memperbaiki kekurangan produk pada iterasi selanjutnya.
• Dalam setiap iterasi, produk yang dikembangkan akan lebih
baik dan lebih lengkap dari iterasi sebelumnya.
 Kelebihan Model Iterative- Incremental

• Fleksibilitas dalam mengubah kebutuhan atau perubahan desain

di awal proses pengembangan, serta meminimalkan resiko
terhadap kegagalan pengembangan produk.
• Model iterative-incremental juga memberikan hasil produk yang
lebih berkualitas dan dapat lebih cepat diluncurkan ke pasaran
karena adanya evaluasi dan perbaikan pada setiap iterasi

Kekurangan Iterative- Incremental

• Proses pengembangan yang dapat memakan waktu yang lebih
lama karena iterasi yang terus menerus.
• Biaya pengembangan juga dapat meningkat karena harus
melakukan evaluasi pada setiap iterasi. Oleh karena itu, model ini
cocok digunakan pada proyek-proyek dengan skala besar dan
kompleks
 Model Agile

• Model Agile adalah sebuah pendekatan pemodelan perangkat

lunak yang menekankan pada kerja sama tim, respons
terhadap perubahan, dan pengiriman produk yang berfungsi
dengan cepat.
• Model ini berfokus pada pengembangan perangkat lunak
secara iteratif dan bertahap, serta berusaha untuk
memberikan nilai tambah dalam setiap tahap pengembangan.
 Model Agile

• Beberapa karakteristik penting dari Model Agile antara lain:

➢ Pendekatan berbasis tim: Model Agile menempatkan tim
sebagai fokus utama dalam pengembangan perangkat
lunak. Semua anggota tim bekerja secara kolaboratif dan
terlibat dalam setiap tahap pengembangan.
➢ Responsif terhadap perubahan: Karena perubahan
terjadi di dalam pengembangan perangkat lunak, Model
Agile menempatkan fleksibilitas dan adaptabilitas sebagai
prioritas dalam setiap tahap pengembangan. Tim harus siap
untuk mengatasi perubahan dan menyesuaikan diri dengan
kebutuhan pelanggan.
➢ Pengiriman produk yang berfungsi dengan cepat:
Model Agile menekankan pada pengiriman produk yang
berfungsi dengan cepat dan memberikan nilai tambah
kepada pelanggan. Ini berarti setiap iterasi harus
menghasilkan produk yang dapat digunakan dan
memberikan nilai tambah kepada pelanggan.
➢ Komunikasi yang efektif: Komunikasi yang efektif sangat
penting dalam Model Agile. Tim harus terus
berkomunikasi secara terbuka dan transparan, memastikan
bahwa semua anggota tim memiliki pemahaman yang
sama tentang proyek dan tujuan pengembangan.
➢ Perbaikan terus-menerus: Model Agile menempatkan
perbaikan sebagai prioritas dalam pengembangan
perangkat lunak. Setiap iterasi harus mengevaluasi kinerja
tim dan menentukan cara untuk meningkatkan proses
pengembangan. terus-menerus
 Model Agile

• Dalam Model Agile, pengembangan perangkat lunak

dilakukan dalam serangkaian iterasi pendek, yang dikenal
sebagai sprint.
• Setiap sprint memiliki durasi tetap dan menghasilkan produk
yang dapat digunakan.
• Tim secara teratur bertemu untuk mengevaluasi kemajuan
dan menentukan cara untuk memperbaiki proses.
• Model Agile sering digunakan dalam pengembangan
perangkat lunak yang kompleks atau yang memerlukan
fleksibilitas dan adaptabilitas yang tinggi.
• Beberapa kerangka kerja yang populer dalam Model Agile
antara lain Scrum, Kanban, dan Extreme Programming (XP).
 6. CONTOH STUDI KASUS
Tema: Sistem Pemesanan Makanan (Kue) pada Usaha UMKM
Untuk mempermudah pengelolaan usaha makanan, seorang
anggota baru UMKM akan membuat sebuah program berbasis
desktop. Program akan dioperasikan oleh seorang admin yang
bertanggung jawab pada semua pemesanan makanan/kue.
Admin akan mencatat data Pelanggan dan pesanannya yang
selanjutnya akan dibuatkan nota pemesanan berikut struk
pembayaran. Pesanan akan diproses kemudian sesuai dengan
jadwalnya.
Setiap akhir bulan Admin membuat Laporan Pemesanan dan
Laporan Penjualan yang akan diserahkan kepada Pemilik Usaha
UMKM.
 Contoh dengan Model Waterfall Sommerville (2011: 30)

Dalam tahap ini terdapat kebutuhan admin. Admin dapat

mencatat data pesanan, mengelola data pelanggan, membuat
laporan bulanan, dan dapat login ke sistem.
Pada tahap ini membuat rancangan sistem menggu-
kan UML yang terdiri dari Use Case Diagram,
Activity Diagram, Sequential Diagram. Sedangkan
rancangan data base menggunakan ERD dan LRS.
Pada tahap ini dilakukan proses pembu-
atan coding menggunakan bahasa
pemrograman Java dan database dengan
MySQL.
Dalam tahap ini dilakukan
pengujian fungsional
menggunakan Black Box
Testing.
Dalam tahap ini akan dilakukan instalasi sistem dan
pemeliharaan berupa perbaikan pada program apabila
ditemukan kesalahan dan backup data akan dilakukan
secara rutin untuk mencegah terjadinya kehilangan data.
 Tugas Kelompok
• Mahasiswa membuat rancangan pengembangan PL
menggunakan model Waterfall lengkap dengan tahapannya,
dan tuliskan referensinya, contoh (nama_pengarang, tahun).
• Kelompok maksimal 3 orang, dan akan terus berkelompok
sampai pertemuan ke-14.
• Tiap kelompok mengerjakan Judul Sistem yang berbeda.
• Judul Sistem (Desktop/Web/Mobile) ditentukan oleh Dosen, dan
Mhs tidak diperkenankan mengutip atau menulis ulang dari
jurnal/artikel yang ada di internet atau makalah lainnya.
• Dikumpulkan pada Pertemuan-3
 Pertemuan 3

KEBUTUHAN
PERANGKAT LUNAK
 Fokus Pembelajaran
1. Rekayasa Kebutuhan
A. Inception
B. Elicitation
C. Elaboration
D. Negosiasi
E. Spesification
F. Validation
G. Requirement Management
2. Persyaratan Fungsional dan Non-Fungsional
 1. REKAYASA KEBUTUHAN
• Kebutuhan untuk suatu sistem adalah deskripsi tentang apa yang
harus dilakukan oleh sistem berupa layanan yang diberikan dan
kendala dalam operasinya.
• Kebutuhan ini mencerminkan kebutuhan Pengguna sistem yang
melayani tujuan tertentu seperti mengontrol perangkat,
menempatkan pesanan, atau mencari informasi.
• Proses mencari tahu, menganalisis, mendokumentasikan serta
memeriksa layanan dan kendala ini disebut Rekayasa Kebutuhan
(Requirement Engineering).
• Rekayasa Kebutuhan harus disesuaikan dengan kebutuhan proses,
proyek, produk, dan orang-orang yang melakukan pekerjaan.
 Jenis Kebutuhan:
1. Kebutuhan Pengguna adalah pernyataan, dalam bahasa
alami ditambah diagram, dari layanan apa yang diharapkan
sistem untuk diberikan kepada pengguna sistem dan
kendala di mana ia harus beroperasi.
2. Kebutuhan Sistem adalah deskripsi yang lebih rinci
tentang fungsi, layanan, dan kendala operasional sistem
perangkat lunak. Dokumen Kebutuhan sistem (kadang-
kadang disebut spesifikasi fungsional) harus
mendefinisikan secara tepat apa yang akan
diimplementasikan.
Kegiatan pada Rekayasa Kebutuhan
 A. Pengenalan Permasalahan (Inception)

• Proyek PL dimulai ketika kebutuhan bisnis atau pasar

atau layanan baru telah diidentifikasi atau ditemukan.
• Menetapkan pemahaman dasar tentang masalah,
siapa yang menginginkan solusi, sifat solusi, serta
keefektifan komunikasi dan kolaborasi antara
stakeholder dengan tim PL.
A. Inception
 B. Pengenalan Lanjutan (Elicitation)

• Bagian penting dari elisitasi adalah untuk menetapkan tujuan

bisnis.
• Masalah yang sering dijumpai:
✓ Lingkup permasalahan: tentang batasan sistem tidak jelas
atau rincian teknis yang membingungkan
✓ Permasalahan yang berkaitan dengan pemahaman
✓ Permasalahan yang berkaitan dengan kestabilan
 Pengenalan Lanjutan (Lanjutan)

Kegiatan pada tahap ini adalah:

1. Kebutuhan penemuan
adalah proses pengumpulan informasi tentang sistem yang
diperlukan dan sistem yang ada, filterisasi pengguna dan
kebutuhan sistem.
Sumber informasi selama tahap penemuan kebutuhan
termasuk dokumentasi, stakeholder, dan spesifikasi sistem.
 Pengenalan Lanjutan (Lanjutan)

2. Klasifikasi Kebutuhan dan Organisasi

Kegiatan ini mengumpulkan kebutuhan yang tidak
terstruktur dan kebutuhan kelompok yang bersifat koheren.
Cara pengelompokkan kebutuhan menggunakan model
arsitektur sistem untuk mengidentifikasi sub-sistem dan
untuk menghubungkan kebutuhan dengan masing-masing
sub-sistem.
3. Kebutuhan Prioritas dan Negosiasi
Kegiatan ini berkaitan dengan memprioritaskan kebutuhan
dan menemukan cara penyelesaian konflik melalui negosiasi.
 C. Elaborasi (Elaboration)
• Elaborasi dilakukan dengan cara membuat dan
penyempurnaan skenario pengguna yang menggambarkan
bagaimana pengguna akhir (dan aktor lain) akan berinteraksi
dengan sistem. Misalnya dengan 2 mesin ATM yang berbeda
cara menggunakannya
 D. Negosiasi
• Konflik yang terjadi antara pengguna, pengguna dan
stakeholder harus didamaikan dengan pendekatan yang
bersifat iteratif untuk menentukan skala prioritas kebutuhan,
menilai biaya-biaya dan risiko masing-masing.
 E. Spesifikasi (Specification)
• Spesifikasi kebutuhan adalah proses menuliskan kebutuhan
pengguna dan kebutuhan sistem ke dalam dokumen
kebutuhan.
• Spesifikasi dapat berupa dokumen tertulis, model grafis, model
matematika formal, kumpulan skenario penggunaan sistem/PL,
prototipe, atau kombinasi dari semuanya.
• Kebutuhan pengguna menggambarkan kebutuhan fungsional
dan non-fungsional sehingga dapat dimengerti oleh pengguna
sistem (perilaku eksternal dari sistem) yang tidak memiliki
pengetahuan teknis.
• Dokumen kebutuhan tidak boleh menyertakan rincian
arsitektur atau desain sistem.
 1). Spesifikasi Bahasa
• Bahasa alami telah digunakan untuk menulis kebutuhan PL
sejak awal RPL yang bersifat ekspresif, intuitif, dan universal.
• Panduan sederhana:
1. Buat format standar dan pastikan bahwa semua definisi
kebutuhan mematuhi format tsb.
2. Gunakan bahasa secara konsisten
3. Gunakan penjelasan teks (tebal, miring, atau warna) untuk
memilih bagian-bagian penting dari kebutuhan.
4. Jangan berasumsi bahwa pembaca memahami bahasa RPL,
hindari penggunaan jargon, singkatan, dan akronim.
5. Sebisa mungkin, harus mencoba mengaitkan alasan dengan
setiap kebutuhan pengguna
Contoh penggunaan bahasa dan jenis font
yang tidak konsisten

Contoh Jargon
✓ UKM
✓ SP
✓ Checkout
✓ ASAP
Contoh inkonsistensi
 2). Spesifikasi Struktur
• Bahasa alami terstruktur adalah cara penulisan kebutuhan sistem
dimana kebebasan dalam penulisan terbatas dan semua kebutuhan
ditulis dengan cara standar.
• Informasi untuk menentukan persyaratan fungsional:
 F. Validasi (Validation)
• Validasi kebutuhan adalah proses pengecekan
kebutuhan yang benar-benar menentukan sistem yang
diinginkan oleh pengguna.
• Validasi melakukan pemeriksaan untuk memastikan
bahwa:
✓ Semua kebutuhan PL telah dinyatakan dengan jelas
✓ Inkonsistensi, kelalaian, dan kesalahan telah
terdeteksi dan diperbaiki
✓ Produk kerja sesuai dengan standar yang ditetapkan
untuk proses, proyek, dan produk.
Hal-hal yang perlu pemeriksaan
 G. Manajemen Kebutuhan
(Requirement Management)
• Adalah serangkaian kegiatan yang membantu tim proyek
untuk mengidentifikasi, mengontrol, dan melacak kebutuhan-
kebutuhan dan melacak perubahan terhadap kebutuhan saat
proyek berlangsung.
• Ada beberapa alasan mengapa perubahan tidak dapat
dihindari:
1. Lingkungan bisnis dan teknis sistem selalu berubah setelah
instalasi.
2. Pengguna sistem bukan orang yang sama.
3. Sistem besar biasanya memiliki komunitas pengguna yang
beragam
 1). Kebutuhan Perencanaan Manajemen
Tahap perencanaan menetapkan tingkat detail manajemen
kebutuhan yang diperlukan, dengan memutuskan:
 2). Kebutuhan Manajemen Perubahan

• Kebutuhan manajemen perubahan harus diterapkan

untuk semua perubahan yang diajukan pada kebutuhan
sistem setelah dokumen kebutuhan disetujui.
• Ada tiga tahapan utama untuk proses manajemen
perubahan:
1. Analisis masalah dan spesifikasi perubahan
2. Analisis dan biaya perubahan
3. Perubahan implementasi
 2. PERSYARATAN FUNGSIONAL dan
NON-FUNGSIONAL
• Persyaratan Fungsional adalah layanan yang harus
disediakan sistem, bagaimana sistem harus bereaksi terhadap
input tertentu, dan bagaimana sistem harus berperilaku dalam
situasi tertentu.

• Persyaratan Non-Fungsional adalah batasan pada layanan

atau fungsi yang ditawarkan oleh sistem.
Termasuk:
✓ Kendala waktu
✓ Kendala pada proses pengembangan
✓ Kendala yang dikenakan oleh standar
 A. Persyaratan Fungsional
• Persyaratan fungsional menggambarkan apa yang harus
dilakukan oleh sistem. Dengan kata lain, menggambarkan
layanan yang disediakan bagi pengguna.
• Jika sistem tidak memenuhi persyaratan fungsional berarti
sistem tidak berfungsi dengan baik.
• Persyaratan ini tergantung pada jenis PL yang dikembangkan,
pengguna, dan pendekatan umum yang diambil oleh organisasi
saat menulis Persyaratan.
• Kebutuhan pengguna dijelaskan secara abstrak yang dapat
dipahami oleh pengguna sistem, terutama untuk kebutuhan
sistem yang lebih spesifik menggambarkan fungsi-fungsi
sistem, input dan output, dan pengecualian secara rinci
 Persyaratan Fungsional (Lanjutan)

• Meskipun suatu sistem masih dapat berfungsi jika persyaratan

non-fungsionalnya tidak dipenuhi, sistem tersebut mungkin
tidak memenuhi harapan pengguna, pemangku kepentingan,
atau kebutuhan bisnis.
• Persyaratan fungsional dapat dibagi menjadi tiga kelompok:
a. Persyaratan bisnis. Menjelaskan tujuan dan harapan
proyek, manfaat yang dapat diperoleh dari proyek,
kemungkinan kendala proyek, dan ruang lingkupnya;
b. Persyaratan pengguna. Melibatkan kebutuhan pengguna
dan aktivitas apa yang dapat dilakukannya dalam sistem
c. Persyaratan sistem. Termasuk tindakan sistem, spesifikasi
perangkat lunak dan perangkat keras, dan sebagainya
Hal-hal penting dalam Persyaratan Fungsional
 B. Persyaratan Non-Fungsional
• Persyaratan non-fungsional menjelaskan bagaimana sistem
melakukannya
• Persyaratan non-fungsional adalah kebutuhan yang tidak
secara langsung terkait dengan layanan spesifik yang
disampaikan oleh sistem kepada penggunanya.
• Persyaratan non-fungsional juga menjaga persyaratan
fungsional tetap beroperasi. Misalnya atribut yang membuat
produk terjangkau, mudah digunakan, dan mudah diakses.
• Persyaratan non-fungsional menentukan standar kinerja dan
kualitas atribut perangkat lunak, misalnya. kegunaan sistem,
efektivitas, keamanan, skalabilitas, dll.
 Persyaratan Non-Fungsional (lanjutan)

• Jika suatu aplikasi tidak memenuhi persyaratan non-

fungsional, aplikasi tersebut akan terus menjalankan fungsi
dasarnya, namun tidak akan mampu memberikan pengalaman
pengguna yang luar biasa.
• Persyaratan non-fungsional muncul melalui kebutuhan
pengguna, karena keterbatasan anggaran, kebijakan organisasi,
kebutuhan interoperabilitas dengan software/hardware, atau
faktor eksternal seperti peraturan keselamatan atau undang-
undang privasi.
• Dapat berupa kendala pada implementasi sistem seperti
kemampuan perangkat I/O, representasi data yang digunakan
dalam antarmuka dengan sistem lain.
 Persyaratan Non-Fungsional (lanjutan)

Implementasi persyaratan non-fungsional dapat disebarluaskan

di seluruh sistem, dengan alasan:
1. Persyaratan non-fungsional dapat mempengaruhi
keseluruhan arsitektur sistem daripada komponen individu.
Misalnya, untuk memastikan bahwa terpenuhinya kebutuhan
kinerja harus mengatur sistem untuk meminimalkan
komunikasi antar komponen.
2. Persyaratan non-fungsional tunggal, seperti kebutuhan
keamanan, dapat menghasilkan sejumlah kebutuhan
fungsional terkait yang menentukan layanan sistem baru
yang diperlukan.
 Karakteristik Persyaratan Non-Fungsional

1. Kebutuhan produk
Kebutuhan ini menentukan atau membatasi perilaku perangkat
lunak.
• Kebutuhan kinerja tentang seberapa cepat sistem harus
dijalankan dan berapa banyak memori yang dibutuhkan
• Kebutuhan keandalan yang menetapkan tingkat kegagalan
yang dapat diterima
• Kebutuhan keamanan
• Kebutuhan kegunaan
Karakteristik Persyaratan Non-Fungsional #2

2. Kebutuhan Organisasi
Adalah kebutuhan sistem yang luas yang berasal dari
kebijakan dan prosedur di organisasi pengguna dan
pengembang.
• Kebutuhan operasional yang menentukan bagaimana sistem
akan digunakan
• Kebutuhan proses pengembangan yang menentukan bahasa
pemrograman, lingkungan pengembangan atau proses
standar yang akan digunakan
• Kebutuhan lingkungan yang menentukan lingkungan
operasi sistem.
Karakteristik Persyaratan Non-Fungsional #3

3. Kebutuhan Eksternal
Mencakup semua kebutuhan yang berasal dari faktor eksternal
ke sistem dan proses pengembangannya.
• Kebutuhan peraturan yang mengatur apa yang harus
dilakukan untuk sistem yang akan disetujui untuk
digunakan oleh regulator, seperti bank sentral
• Kebutuhan legislatif yang memastikan bahwa sistem
beroperasi sesuai peraturan
• Kebutuhan etis yang memastikan bahwa sistem akan
diterima oleh pengguna dan masyarakat umum
Karakteristik Persyaratan Non-Fungsional
Contoh Persyaratan Fungsional dan Non-Fungsional
Contoh Persyaratan Non-Fungsional
Contoh Requirement
 Tugas Kelompok
• Mahasiswa menyebutkan Persyaratan Fungsional dan Non-
Fungsional
• Nama Kelompok dan Judul Sistem sama dengan Pertemuan-2.
• Contoh pada Sistem Pendaftaran berobat jalan di Klinik
(hanya contoh saja):
A. Persyaratan Fungsional
1. Kebutuhan Pasien
2. Kebutuhan Admin/Petugas Pendaftaran
B. Persyaratan Non-Fungsional
1. Kebutuhan Kegunaan
2. Kebutuhan Performa
 Pertemuan 4

KONSEP
PERANCANGAN
 Fokus Pembelajaran
1. Model Perancangan
2. Proses Perancangan
3. Konsep Perancangan
A. Abstraksi
B. Arsitektur
C. Pattern
D. Pemisahan Perhatian
E. Modularisasi
F. Penyembunyian Informasi
G. Independensi Funsi
H. Penghalusan
I. Refaktorisasi
 1. PENDAHULUAN
• Perancangan PL merupakan tempat di mana aturan kreativitas
(kebutuhan stakeholder, kebutuhan bisnis, dan pertimbangan
teknis) semuanya secara bersamaan disatukan untuk membentuk
sebuah produk atau sistem/PL.
• Perancangan menciptakan representasi atau model PL,
• Model perancangan memberikan detail tentang arsitektur PL,
struktur data, antarmuka, & komponen yang diperlukan untuk
mengimplementasikan sistem.
• Tujuan perancangan PL adalah untuk menghasilkan model atau
representasi PL yang memperlihatkan kekuatan, komoditi, dan
kenyamanan.
Gambar hasil rancangan Gambar implementasi
 Model Perancangan
1. Perancangan data/kelas
• Mengubah model kelas menjadi realisasi kelas
perancangan dan struktur data yang diperlukan untuk
mengimplementasikan PL.
• Objek, hubungan dan konten data rinci yang digambarkan
oleh atribut kelas dan notasi lainnya memberikan dasar
untuk aktivitas perancangan data.
• Bagian dari perancangan kelas dapat terjadi bersamaan
dengan perancangan arsitektur PL.
• Perancangan kelas yang lebih rinci terjadi karena setiap
komponen PL dirancang.
 Model Perancangan (lanjutan)

2. Perancangan arsitektur
• Mendefinisikan hubungan antara elemen struktural utama
dari PL, gaya dan pola arsitektur yang dapat digunakan
untuk mencapai kebutuhan yang ditentukan untuk sistem,
dan kendala yang mempengaruhi cara di mana arsitektur
dapat diimplementasikan.
• Mewakili perancangan kerangka kerja arsitektur sistem
berbasis komputer berasal dari model kebutuhan.
 Model Perancangan (lanjutan)

3. Perancangan antarmuka
• Menggambarkan bagaimana PL berkomunikasi dengan
sistem, dan dengan manusia yang menggunakannya.
• Antarmuka menyiratkan aliran informasi (misal data atau
kontrol) dan jenis perilaku tertentu.
• Perancangan antarmuka pada tingkat komponen mengubah
elemen struktural dari arsitektur PL menjadi deskripsi
prosedural komponen PL.
• Informasi yang diperoleh dari model berbasis kelas dan
model perilaku berfungsi sebagai dasar untuk perancangan
komponen.
Contoh perancangan
 2. PROSES PERANCANGAN
• Perancangan PL adalah proses yang bersifat iteratif dimana
spesifikasi kebutuhan PL diterjemahkan menjadi “blue print"
untuk membangun PL.
• Blue print menggambarkan pandangan holistik PL. Yaitu,
perancangan diwakili pada tingkat abstraksi yang tinggi pada
tingkat yang dapat langsung ditelusuri ke tujuan sistem dan
data yang lebih rinci, fungsional, dan kebutuhan perilaku.
• Saat iterasi perancangan PL berlangsung, penghalusan lebih
lanjut akan menggerakkan abstraksi yang lebih rendah.
 A. Atribut-Atribut Kualitas PL
Tiga karakteristik umum yang berfungsi sebagai panduan untuk
evaluasi perancangan yang baik:
1. Perancangan PL harus menerapkan semua spesifikasi
kebutuhan yang secara eksplisit ada dalam model kebutuhan,
dan mengakomodasi semua spesifikasi kebutuhan implisit
yang diinginkan oleh stakeholder.
2. Perancangan PL harus menghasilkan produk kerja yang
mudah dibaca dan dimengerti bagi mereka yang membuat
kode-kode program dan yang akan melakukan mengujian
untuk kemudian mendukung PL.
3. Perancangan PL seharusnya menyediakan gambaran lengkap
tentang PL, menangani permasalahan data, fungsional, dan
perilaku dari perspektif implementasi.
Contoh spesifikasi kebutuhan obat
 Panduan Kualitas PL
Tujuannya untuk mengevaluasi kualitas representasi
perancangan.
1. Rancangan PL harus menunjukkan arsitektur yang:
• telah dibuat menggunakan gaya atau pola arsitektur yang
dapat dikenali
• tersusun atas komponen-komponen yang menunjukkan
karakteristik perancangan yang baik
• dapat diimplementasikan secara evolusioner, dan
memfasilitasi implementasi dan pengujian.
2. Rancangan PL harus bersifat modular, artinya PL harus secara
logis menjadi bagian dalam elemen-elemen atau subsistem.
Contoh rancangan yang tidak memberikan
informasi jelas untuk menu Web. Seharusnya
dituliskan secara langsung menu yang
dimaksud, seperti Beranda,
Keranjang, Registrasi, Login
 Panduan Kualitas PL (Lanjutan)

3. Rancangan PL harus berisi representasi data, arsitektur,

objek-objek, antarmuka, dan komponen yang berbeda.
4. Rancangan PL harus memuat struktur data yang sesuai untuk
kelas yang akan diimplementasikan dan digambarkan dari
pola-pola data yang dapat dikenali.
5. Rancangan PL harus mengarah pada komponen yang
menunjukkan karakteristik fungsional yang bersifat
independen.
 Panduan Kualitas PL (Lanjutan)

6. Rancangan PL harus memuat antarmuka yang mengurangi

kompleksitas hubungan antar komponen dan dengan
lingkungan eksternal. Minimalisasi keterlibatan Pengguna
terhadap sistem. Seperti contoh penggunaan QR code, yang
tujuannya untuk mengurangi kesalahan.
 Panduan Kualitas PL (Lanjutan)

7. Rancangan PL harus diturunkan dari metode perulangan

yang dikendalikan oleh informasi yang diperoleh selama
analisis kebutuhan PL.
8. Sebuah perancangan harus direpresentasikan menggunakan
notasi yang secara efektif mengkomunikasikan maknanya.
Contoh berikut
penggunaan icon
yang tidak sesuai
dengan maknanya.
 Atribut-Atribut Kualitas
1. Fungsionalitas
Dinilai dengan mengevaluasi sejumlah fitur dan kemampuan
program, fungsi-fungsi umum yang disampaikan, dan
keamanan sistem secara keseluruhan.
2. Peggunaan
Dinilai dengan mempertimbangkan faktor manusia, estetika,
konsistensi, dan dokumentasi.
3. Keandalan
Dievaluasi dengan mengukur frekuensi dan tingkat keparahan
kegagalan, akurasi hasil keluaran, waktu antar kegagalan,
recovery, dan prediktabilitas program.
 Atribut-Atribut Kualitas (Lanjutan)
4. Kinerja
Diukur menggunakan kecepatan pemrosesan, waktu tanggap,
konsumsi sumber daya, throughput, dan efisiensi.
5. Daya dukung
Menggabungkan kemampuan program untuk dikembangkan,
kemampuan beradaptasi, dan kemampuan melayani
kebutuhan pengguna, kemampuan uji, kompatibilitas,
konfigurabilitas (kemampuan untuk mengatur dan mengontrol
elemen-elemen konfigurasi PL).
 3. KONSEP-KONSEP PERANCANGAN

Konsep perancangan pada dasarnya akan menyediakan

kebutuhan:
• Kriteria yang digunakan untuk membagi PL menjadi
komponen yang bersifat mandiri
• Rincian fungsi/struktur data yang dapat dipisahkan dari
representasi konseptual
• Kriteria yang digunakan untuk mendefinisikan kualitas teknis
perancangan PL
 A. Abstraksi
• Pada tingkat abstraksi tertinggi, penyelesaian masalah
dinyatakan dalam istilah luas menggunakan bahasa pada
lingkungan permasalahan.
• Pada tingkat abstraksi lebih rendah, deskripsi yang lebih rinci
dari penyelesaian masalah harus diberikan.
• Terminologi berorientasi masalah digabungkan dengan
terminologi berorientasi implementasi dengan tujuan untuk
lebih dapat menyelesaikan permasalahan
• Pada tingkat abstraksi yang paling rendah, penyelesaian
masalah diupayakan agar dapat langsung diimplementasikan
menggunakan bahasa pemrograman yang dipilih.
 B. Arsitektur

• Arsitektur sistem/PL merupakan struktur keseluruhan PL dan

cara bagaimana struktur tersebut memberikan integritas
konseptual untuk suatu sistem/PL.
• Arsitektur sistem/PL juga merupakan struktur/organisasi dari
komponen program (modul) yang menjelaskan bagaimana
komponen-komponen tersebut berinteraksi, dan struktur data
yang digunakan oleh komponen.
 Arsitektur (Lanjutan)
Properti sebagai bagian dari perancangan arsitektur:
• Properti Struktural
Mendefinisikan komponen sistem (modul, objek, filter) dan
menjelaskan bagaimana komponen-komponen tersebut
dikemas dan berinteraksi satu sama lain.
• Properti Fungsional Tambahan
Deskripsi perancangan arsitektural seharusnya bisa
menyelesaikan permasalahan tentang bagaimana arsitektur
perancangan mencapai kebutuhan akan kinerja, kapasitas,
keandalan, keamanan, kemampuan beradaptasi, dan
karakteristik lainnya.
• Keluarga sistem yang berhubungan
Perancangan arsitektural seharusnya dibuat melalui pola
perulangan/iterasi.
Gambar perancangan arsitektur
 C. Pattern (Pola)
• Pola adalah suatu wawasan yang di dalamnya memuat esensi
dari solusi yang terbukti untuk permasalahan perancangan PL
dalam konteks tertentu [Brad Appleton].
• Tujuan dari setiap pola perancangan adalah untuk memberikan
deskripsi yang memungkinkan perancang untuk menentukan:
1. Apakah pola berlaku untuk pekerjaan saat ini
2. Apakah pola dapat digunakan kembali
3. Apakah pola dapat berfungsi sebagai panduan untuk
mengembangkan pola yang serupa, tetapi secara
fungsional atau struktural berbeda.
 D. Pemisahan Perhatian
• Pemisahan perhatian adalah konsep perancangan yang
menunjukkan bahwa masalah yang kompleks dapat
diselesaikan jika permasalahan itu dibagi menjadi bagian-
bagian yang lebih kecil yang lebih mudah diselesaikan
dan/atau dioptimalkan secara independen.
• Pemisahan perhatian dapat diimplementasikan menggunakan
konsep perancangan PL yang saling berhubungan seperti:
modularitas, aspek-aspek, kemandirian fungsional, dan
penghalusan.
 E. Modularitas
• Modularitas adalah atribut tunggal dari PL yang
memungkinkan suatu program untuk dapat dikelola secara
cerdas.
• PL monolitik adalah program besar yang terdiri dari satu
modul.
• PL monolitik tidak dapat dengan mudah dipahami oleh
rekayasawan PL. Jumlah lintasan kendali, rentang referensi,
jumlah variabel, dan kompleksitas keseluruhan hampir tidak
mungkin dimengerti.
 Modularitas (Lanjutan)
• Lebih banyak modul berarti ukuran modul semakin lebih kecil.
• Bertambahnya jumlah modul, maka upaya (biaya) yang terkait
dengan pengintegrasian modul juga bertambah.
• Tujuan Modularitas:
✓ Pengembangan PL dapat lebih mudah direncanakan
✓ Versi-versi PL dapat didefinisikan
✓ Perubahan-perubahan dapat dengan mudah
diakomodasikan
✓ Testing dan debugging dapat dilakukan secara lebih efisien
✓ Mudah dalam pemeliharaan PL
 F. Penyembunyian Informasi
• Maksudnya bahwa Modul PL harus dispesifikasikan dan
dirancang sedemikian rupa sehingga informasi (algoritma dan
data) yang terdapat dalam modul tidak dapat diakses oleh
modul lain yang tidak memerlukan informasi tersebut.
• Penyembunyian informasi (Information hiding) menyiratkan
bahwa modularitas yang efektif dapat dicapai dengan
mendefinisikan sejumlah modul independen yang
berkomunikasi satu sama lain dalam hal informasi yang
diperlukan untuk mencapai fungsi PL.
• Manfaatnya ketika modifikasi tertentu perlu dilakukan selama
pengujian PL dan kemudian selama pemeliharaan PL.
 G. Independensi Fungsional
• Konsep independensi fungsional adalah hasil langsung dari
pemisahan masalah, modularitas, dan konsep abstraksi dan
penyembunyian informasi.
• Independensi fungsional dicapai dengan cara mengembangkan
modul yang memiliki fungsi tunggal (single-minded) dan
memiliki interaksi yang bersifat tertutup dengan modul lain →
contoh pada sub sistem penggajian
• Modul independen lebih mudah dikembangkan karena fungsi-
fungsi di dalamnya dapat dilokalisasi dan antarmuka
disederhanakan.
• Modul independen lebih mudah dipelihara dan diuji
 Kemandirian Fungsional (Lanjutan)
Modul independesi mempunyai kriteria kualitatif:
1. Kohesivitas
• Adalah indikasi dari kekuatan fungsional relatif suatu
modul.
• Umumnya melakukan pekerjaan tunggal dan hanya
memerlukan sedikit interaksi dengan komponen lainnya
2. Kebergantungan (coupling)
• Adalah indikasi dari kemandirian relatif antar modul.
• Coupling tergantung pada kompleksitas antarmuka yang
menghubungkan modul-modul yang ada dalam program,
yaitu titik masuk suatu modul, dan data apa yang melewati
antarmuka modul.
 H. Penghalusan
• Penghalusan merupakan proses elaborasi yang dimulai dengan
pernyataan fungsi (atau deskripsi informasi) yang
didefinisikan pada tingkat abstraksi yang tinggi.
• Penghalusan langkah demi langkah menggunakan strategi
perancangan top-down.
• Hirarki PL dikembangkan dengan melakukan dekomposisi
pernyataan fungsi yang bersifat makro (abstraksi prosedural)
secara bertahap hingga pernyataan dalam bahasa pemrograman
dapat tercapai.
• Penghalusan membantu untuk mendapatkan rincian pada
tingkat rendah saat perancangan berlangsung.
 I. Refaktorisasi
• Refaktorisasi adalah teknik reorganisasi perancangan PL yang
bertujuan untuk menyederhanakan perancangan (atau kode)
dari komponen tanpa harus mengubah fungsi atau perilakunya.
• Refaktorisasi PL, diperiksa kembali untuk:
✓ Menemukan redundansi
✓ Menemukan elemen perancangan yang tidak digunakan
✓ Menemukan algoritma yang tidak efisien (tidak perlu)
✓ Menemukan struktur data yang konstruksinya buruk
✓ Menemukan kegagalan perancangan lainnya yang dapat
diperbaiki untuk menghasilkan perancangan yang lebih
baik.
 Pertemuan 5

PERANCANGAN
ANTARMUKA ( Desain
User Interface)
 Fokus Pembelajaran

1. Prinsip Dasar Desain User Interface (UI)

2. Desain Navigasi
3. Desain Input
4. Desain Output
5. Mobile Computing dan Desain UI
6. Media Sosial dan Desain UI
7. Studi Kasus
 1. PRINSIP DASAR DESAIN USER INTERFACE (UI)

• Antarmuka pengguna (User Interface) menggambarkan

bagaimana pengguna berinteraksi dengan sistem komputer
yang meliputi semua perangkat keras, perangkat lunak,
layar, menu, fungsi, output, dan fitur yang mempengaruhi
komunikasi dua arah antara pengguna dan komputer.
• UI mencakup tampilan layar yang menyediakan navigasi
melalui sistem, layar dan formulir yang menangkap data,
dan laporan yang dihasilkan sistem (baik di atas kertas, di
Web, atau melalui media lain).
• Dalam arti luas, UI mencakup semua komunikasi dan
instruksi yang diperlukan untuk memasukkan data ke sistem
dan untuk memperoleh keluaran dalam bentuk tampilan
layar atau laporan tercetak
Prinsip Dasar Desain UI
Tiga Hal Mendasar pada UI
Desain Standar Antarmuka
Prinsip dasar desain dari sudut
pandang Pengguna
Pedoman dalam merancang UI yang mudah digunakan,
menarik, dan efisien:
 2. DESAIN NAVIGASI
• Tujuan dari sistem navigasi adalah membuat sistem
sesederhana mungkin untuk digunakan.
• Komponen navigasi antarmuka memungkinkan pengguna
memasukkan perintah untuk menavigasi sistem dan
melakukan tindakan untuk memasukkan dan meninjau
informasi yang dikandungnya.
• Semua kontrol harus jelas dan mudah dipahami serta
ditempatkan di lokasi yang intuitif di layar. Idealnya,
kontrol harus mengantisipasi apa yang akan dilakukan
pengguna dan menyederhanakan upayanya.
• Misalnya, untuk instalasi biasa, pengguna cukup terus
menekan tombol berikutnya (Next).
Prinsip Merancang Kontrol Navigasi
 Pesan (Message)
• Pesan adalah cara sistem merespons pengguna dan memberi
tahu tentang status interaksi.
• Pesan harus jelas, ringkas, dan lengkap, yang terkadang
memiliki tujuan yang bertentangan.
• Pesan harus benar secara tata bahasa, bebas dari jargon dan
singkatan.
• Pesan mengharuskan pengguna untuk mengakuinya (dengan
mengklik), daripada ditampilkan selama beberapa detik dan
kemudian menghilang. Kecuali pesan yang memberi tahu
pengguna tentang penundaan pemrosesan, yang akan hilang
setelah penundaan tersebut selesai.
• Pesan kesalahan harus memberikan nomor pesan. Nomor pesan
tidak ditujukan untuk pengguna, seperti kode pesan 404, 500.
Tipe Pesan (Message)
 3. DESAIN INPUT
• Input memfasilitasi masuknya data ke dalam sistem
komputer, baik data terstruktur seperti informasi pesanan
(nomor barang, jumlah, biaya) maupun data tidak
terstruktur, misalnya komentar.
• Desain input berarti merancang layar yang digunakan untuk
memasukkan informasi serta segala bentuk dimana
pengguna menulis atau mengetik informasi.
• Tujuan dari desain input adalah untuk memastikan kualitas,
menangkap informasi yang akurat, dan ketepatan waktu dari
data masukan
• Prinsip dasar desain masukan mencerminkan sifat masukan
(batch atau online) dan cara menyederhanakan
pengumpulannya.
 a. Dokumen Sumber dan Formulir
• Dokumen sumber mengumpulkan data masukan, memicu
atau mengotorisasi tindakan, dan menyediakan catatan
transaksi asli.
• Dokumen sumber biasanya mencakup:
 Zona memuat nama/logo perusahaan, judul & nomor formulir.
 Zona kontrol berisi kode, informasi identifikasi, nomor, dan
tanggal yang digunakan untuk menyimpan formulir yang
sudah diisi.
 Zona instruksi berisi instruksi untuk mengisi formulir.
 Zona isi berisi keterangan dan area untuk memasukkan data
variabel. Jika total disertakan dalam formulir, total tersebut
akan muncul di zona total.
 Zona otorisasi berisi tanda tangan yang diperlukan.
 Dokumen Sumber dan Formulir (lanjutan)
• Tata letak formulir yang baik yaitu mudah diisi dan
menyediakan ruang yang cukup, baik secara vertikal
maupun horizontal.
• Formulir harus menunjukkan posisi entri data dengan jelas
menggunakan garis atau kotak kosong dan keterangan
deskriptif.
• Informasi yang mengalir dalam formulir dari kiri ke kanan
dan atas ke bawah agar sesuai dengan cara pengguna
membaca dokumen secara alami.
• Desain formulir berbasis web adalah kebanyakan orang
membaca dan berinteraksi secara berbeda dengan informasi
di layar dibandingkan dengan formulir kertas. pengguna
memindai halaman, memilih kata dan kalimat individual.
 b. Layar Entri Data
• Entri data adalah proses memasukkan data secara manual ke
dalam sistem, biasanya dalam bentuk penekanan tombol, klik
mouse, layar sentuh, atau kata-kata yang diucapkan.
• Desain masukan menentukan bagaimana data akan ditangkap
dan dimasukkan ke dalam sistem.
• Metode entri data online yang paling efektif adalah pengisian
formulir kosong yang menyerupai dokumen sumber pada
layar.
 Layar Entri Data (lanjutan)

Pedoman merancang layar entri data:

1. Batasi akses pengguna ke lokasi layar tempat data
dimasukkan. Misalnya, ketika Mahasiswa memasukkan NIM
(8 digit), jika entri valid, sistem menampilkan data mahasiswa
sehingga Mahasiswa dapat memverifikasinya.

2. Berikan keterangan deskriptif dan tunjukkan kepada pengguna

di mana harus memasukkan data dengan ukuran masukan atau
maksimum.
 Layar Entri Data (lanjutan)
3. Menampilkan contoh format jika pengguna harus
memasukkan nilai dalam kolom dalam format tertentu.
Misalnya, format tanggal adalah MM-DD-YYYY.
Sebaiknya gunakan input mask atau bantuan kalender.

4. Memerlukan penekanan tombol penutup untuk setiap field

dengan menekan tombol enter atau tombol tab yang
menandakan akhir dari entri kolom. Hindari desain yang
berpindah secara otomatis ke item berikutnya ketika
bidangnya penuh.
 Layar Entri Data (lanjutan)
5. Tidak mengharuskan pengguna mengetikkan angka nol di
depan untuk tipe numerik sesuai panjang field. Misalnya
jika nomor peserta tiga digit adalah 025, cukup dengan
mengetikkan 25, bukan 025.
6. Tidak mengharuskan pengguna mengetikkan angka nol di
akhir angka yang menyertakan desimal. Misalnya ketika
pengguna mengetikkan uang 100, sistem harus
menafsirkan nilai tersebut sebagai 100,00 jika field telah
diformat (input mask). Titik desimal hanya untuk
menunjukkan tempat desimal bukan nol, seperti 100,25.
7. Tampilkan nilai default sehingga operator dapat menekan
tombol enter untuk menerima nilai yang disarankan. Jika
nilai defaultnya tidak sesuai, operator dapat mengubahnya.
 Layar Entri Data (lanjutan)
8. Gunakan nilai default ketika nilai field akan konstan untuk
rekaman yang berurutan atau sepanjang sesi entri data.
Misalnya, jika catatan dimasukkan secara berurutan
berdasarkan tanggal, maka tanggal yang digunakan dalam
transaksi pertama harus digunakan sebagai tanggal default
hingga tanggal baru dimasukkan, dan pada saat itu tanggal
baru menjadi nilai default.
 Layar Entri Data (lanjutan)
9. Memberikan pesan kesalahan jika
pengguna memasukkan nilai yang
tidak dapat diterima. Metode yang
lebih baik dengan menyediakan
kotak daftar drop-down yang berisi
nilai yang dapat diterima yang
memungkinkan pengguna memilih
nilai dengan mengklik.
10. Berikan cara untuk keluar dari layar entri data kapan saja
tanpa memasukkan data entri. Misalnya, mengklik tombol
Batalkan Pesanan dan akan kembali ke awal formulir.
 Layar Entri Data (lanjutan)
11. Memberikan kesempatan
kepada pengguna untuk
mengonfirmasi keakuratan
data yang dimasukkan
sebelum menyimpan data
dengan menampilkan pesan.
12. Menyediakan sarana bagi pengguna untuk berpindah antar
kolom pada formulir dalam urutan standar atau dalam
urutan apa pun yang dipilihnya. Misalnya, penyisipan
secara otomatis akan berpindah ke kolom berikutnya,
dalam urutan yang telah ditentukan.
 Layar Entri Data (lanjutan)

13. Rancang tata letak formulir layar agar sesuai dengan tata
letak dokumen sumber. Jika Formulir lebih dari satu layar
masukan harus menggunakan desain yang sama.
14. Izinkan pengguna untuk menambah, mengubah,
menghapus, melihat catatan. dan mencari (search) data.
15. Menyediakan metode yang memungkinkan pengguna
mencari informasi spesifik. Misalnya mencari data yang
jumlahnya besar dan tidak mungkin dilihat satu per satu.
16. Jangan meminta pengguna untuk mengisi data yang
seharusnya bisa diperoleh dari perhitungan otomatis.
Misalnya item “Usia” yang harus diisi pengguna,
seharusnya dapat dihitung dari tanggal sistem dikurang
tanggal lahir pengguna.
 c. Tipe Input
a. Teks
• Digunakan untuk memasukkan teks.
• Memiliki panjang tetap dan dapat menerima jumlah teks
yang banyak.
• Dapat berisi satu atau beberapa baris informasi tekstual.
• Memiliki label field yang ditempatkan di sebelah kiri area
entri, ukurannya dibatasi dengan jelas oleh sebuah kotak
atau serangkaian garis bawah.
• Kotak teks harus mengizinkan fungsi GUI standar, seperti
cut, copy, paste.
 Tipe Input #2
b. Angka
• Digunakan untuk memasukkan nomor.
• Input Mask untuk beberapa perangkat lunak dapat secara
otomatis memformat angka saat dimasukkan, sehingga
3452478 menjadi $34,524.78.
• Tanggal mempunyai suatu bentuk format angka khusus.
• Jangan pernah menggunakan kotak nomor untuk kotak
pilihan.

c. Kotak Seleksi.
• Memungkinkan pengguna untuk memilih nilai dari daftar
yang telah ditentukan sebelumnya.
• Item dalam daftar harus disusun dalam urutan yang
bermakna, misalnya urut abjad untuk daftar panjang.
Kotak Seleksi
 Tipe Selection Box

Sumber: Allan Denis (2005)

Tipe Box Input
 d. Validasi Input
• Semua data yang dimasukkan ke dalam sistem perlu
divalidasi untuk memastikan keakuratannya. Mengurangi
jumlah kesalahan input akan meningkatkan kualitas data.
• Idealnya, sistem komputer tidak boleh menerima data yang
gagal dalam pemeriksaan validasi penting untuk mencegah
informasi yang tidak valid memasuki sistem.
• Aturan validasi data meningkatkan kualitas masukan
dengan menguji data dan menolak entri apa pun yang gagal
memenuhi ketentuan yang ditentukan.
• Setiap sistem harus menggunakan setidaknya satu
pemeriksaan validasi pada semua data yang dimasukkan.
Jenis Pemeriksaan Validasi
Pemrosesan Online versus Batch
Teknologi Input
• Metode masukan harus hemat biaya, tepat waktu, dan
sesederhana mungkin, bagaimana dan kapan data masuk ke
sistem.
• Keuntungan metode input online adalah validasi langsung
dan ketersediaan data.
Teknologi umum otomatisasi data sumber
1. Point-of-Sale (POS) yang dilengkapi
dengan pemindai kode batang dan
pemindai gesek magnetik untuk
memasukkan data dari kartu
debit/credit.

2. ATM yang membaca strip data pada kartu bank.

3. Barcode yang digunakan untuk input data dan dibaca oleh
mesin untuk mengidentifikasi informasi tertentu. Contoh
barcode untuk menyimpan informasi produk seperti kode,
nama produk, harga, dll. Barcode pada gelang pasien yang
menyimpan data tentang pasien.
Teknologi umum otomatisasi data sumber
4. ID-Card sebagai tanda pengenal seseorang pada sebuah
organisasi/perusahaan/instansi.
5. Kode ISBN pada buku yang terdiri dari deretan angka 13
digit, sebagai identifikasi terhadap satu judul buku yang
diterbitkan oleh penerbit. Hal ini juga menandakan hak
paten bagi pengarang.
6. RFID yang digunakan untuk
melakukan identifikasi dan
pengambilan data dengan
menggunakan barcode atau strip
data magnetik.
 4. DESAIN OUTPUT
• Output adalah apa yang dihasilkan sistem, baik di layar, di
atas kertas, atau di media lain seperti Web.
• Output merupakan bagian yang paling terlihat dari sistem
apa pun karena alasan utama penggunaan sistem informasi
adalah untuk mengakses informasi yang dihasilkannya.
• Tujuan dari mekanisme keluaran adalah untuk menyajikan
informasi kepada pengguna sehingga dapat memahaminya
secara akurat dengan sedikit usaha.
• Prinsip dasar desain output mencerminkan bagaimana
output digunakan dan cara untuk membuatnya lebih mudah
bagi pengguna untuk memahaminya
 Desain Output (lanjutan)

Beberapa hal yang diperhatikan sebelum merancang keluaran:

• Tujuan keluarannya
• Siapa yang menginginkan informasi tersebut, mengapa
informasi tersebut dibutuhkan, dan bagaimana informasi
tersebut akan digunakan.
• Informasi spesifik apa yang akan disertakan.
• Apakah hasilnya akan dicetak, dilihat di layar, atau
keduanya. Dan jenis perangkat apa yang akan digunakan.
• Kapan informasi akan diberikan, dan seberapa sering
informasi tersebut harus diperbarui.
• Apakah ada masalah keamanan atau kerahasiaan.
Tipe Output
 Teknologi Output
• Desainer membuat desain output untuk formulir, laporan,
dokumen, dan jenis keluaran aktual lainnya dengan
mempertimbangkan format dan cara pengiriman,
penyimpanan, dan pengambilannya.
• Format laporan yang sering digunakan adalah PDF. Laporan
ini disimpan dalam format elektronik di server sehingga
pengguna dapat dengan mudah mengaksesnya.
• Laporan elektronik dapat dibuat sesuai kebutuhan sistem.
Keuntungannya adalah biaya yang rendah, format
penyimpanan yang sesuai, mudah diakses, dan mudah
dikirimkan ke pengguna lainnya.
 Teknologi yang diperlukan untuk membuat output sistem:

1. Berbasis Internet. Misalnya, suatu bisnis dapat

menghubungkan sistem inventarisnya ke situs Web sehingga
output dari sistem inventaris ditampilkan sebagai katalog
online. Pelanggan dapat meninjau item, mendapatkan harga
terkini, dan memeriksa ketersediaan produk.
2. Email. Pengguna menggunakan email untuk bertukar
dokumen, data, dan jadwal serta untuk berbagi informasi yang
diperlukan untuk melakukan pekerjaan mereka.
3. Blog. Berguna untuk memposting berita, mengulas peristiwa
terkini, dan mempromosikan produk.
4. Pesan Singkat. Adalah layanan pesan teks yang
memungkinkan adanya pertukaran pesan teks singkat antar
perangkat seluler.
 Teknologi yang diperlukan untuk membuat output sistem#2:

5. Perangkat Nirkabel. Pesan dan data dapat dikirim ke

beragam perangkat seluler seperti PDA, komputer
genggam, smartphone, dan produk nirkabel serupa yang
menggabungkan daya komputasi portabel, kemampuan
multimedia, dan akses Internet.
6. Audio Digital, Gambar, dan Video. Suara, gambar, dan
klip video dapat ditangkap, disimpan dalam format digital,
dan dikirimkan sebagai output kepada pengguna yang
dapat mereproduksi konten tersebut.
7. Podcast. Adalah file audio digital berformat khusus yang
dapat diunduh dari berbagai penyedia konten. Banyak
perusahaan menggunakan podcast sebagai alat penjualan
dan pemasaran, dan untuk berkomunikasi dengan
karyawan mereka sendiri.
 Teknologi yang diperlukan untuk membuat output sistem#3:

8. Sistem Faksimili Otomatis. Memungkinkan pelanggan

meminta faks menggunakan email, melalui situs Web
perusahaan, atau melalui telepon. Responsnya dikirimkan
dalam hitungan detik kembali ke mesin faks pengguna.
9. Output Komputer ke Mikrofilm (COM). Digunakan
untuk memindai dan menyimpan gambar dokumen asli
guna menyediakan pengelolaan dan pengarsipan arsip
berkualitas tinggi. Sistem COM sangat penting untuk
alasan hukum, seperti menampilkan tanda tangan, stempel
tanggal, atau fitur visual lainnya dari suatu dokumen.
 5. MOBILE COMPUTING dan DESAIN UI
Pedoman desain:
• Pada konteks seluler, fokus pada apa yang dibutuhkan pengguna
dan bukan pada apa yang mungkin diinginkan pengguna.
• Jika pengguna memerlukan akses ke situs lengkap, pastikan untuk
memberikan tautan ke situs tersebut di lokasi yang jelas.
• Manfaatkan kemampuan unik yang ada pada perangkat seluler
seperti GPS bawaan, kemampuan pengenalan suara, kamera untuk
pemindaian, layar sentuh untuk penggunaan gerakan canggih, dan
umpan balik haptik (getaran/pulsa).
• Pertimbangkan sebuah telepon yang memiliki lebar yang terbatas,
manfaatkan scroll-down dan scroll-up daripada dari kiri ke kanan.
• Optimalkan aplikasi seluler termasuk meminimalkan berapa kali
perangkat harus berinteraksi dengan server untuk download/upload.
Navigasi Layar Sentuh
6. MEDIA SOSIAL dan DESAIN UI
• Desainer harus memahami siapa target pengguna Medsos
• Pahami kebutuhan fungsional dari Medsos yang akan
dibangun.
• Tentukan jenis kehadiran media sosial apa yang
diperlukan untuk memenuhi kebutuhan pengguna secara
efektif.
• Setiap platform media sosial memiliki “niche” pasar.
Sehingga perlu menerapkan banyak aplikasi berbeda di
berbagai platform berbeda untuk memenuhi persyaratan
kehadiran media sosial secara efektif.
Pedoman mengembangkan situs media
sosial
 7. CONTOH STUDI KASUS
Tema: Sistem Pemesanan Makanan (Kue) pada Usaha UMKM
Untuk mempermudah pengelolaan usaha makanan,
seorang anggota baru UMKM akan membuat sebuah
program berbasis desktop. Program akan dioperasikan
oleh seorang admin yang bertanggung jawab pada semua
pemesanan makanan/kue.
Admin akan mencatat data Pelanggan dan pesanannya
yang selanjutnya akan dibuatkan nota pemesanan berikut
struk pembayaran. Pesanan akan diproses kemudian
sesuai dengan jadwalnya.
Setiap akhir bulan Admin membuat Laporan Pemesanan
dan Laporan Penjualan yang akan diserahkan kepada
Pemilik Usaha UMKM.
 Tugas Kelompok
• Mahasiswa membuat rancangan User Interface sesuai
kasus kelompok masing-masing.
• Desain yang dibuat adalah Desain Navigasi, Desain Input,
dan Desain Output.
• Rancangan tidak boleh sama dengan kelompok lainnya.
• Tools yang digunakan untuk menggambarkan UI bebas.
• Dikumpulkan melalui MyBest dalam format Word.
• Anggota kelompok masih mengikuti tugas sebelumnya
 Pertemuan 6

PEMODELAN SISTEM
dengan UML
 Fokus Pembelajaran
1. Pemodelan Sistem
2. Unified Modeling Language
3. Use Case Diagram
4. Acivity Diagram
5. Sequence Diagram
6. Studi Kasus
 1. PEMODELAN SISTEM
• Model membantu pengguna, manajer, dan profesional IT
memahami desain suatu sistem.
• Pemodelan sistem adalah proses pengembangan model abstrak
suatu sistem, dimana masing-masing model menyajikan
pandangan atau perspektif yang berbeda dari sistem tersebut.
• Pemodelan sistem juga berarti merepresentasikan sistem
menggunakan semacam notasi grafis, seperti UML.
• Aspek terpenting dari model sistem adalah tidak adanya detail.
• Model merupakan abstraksi dari sistem yang sedang dipelajari
dan bukan representasi alternatif dari sistem tersebut.
Representasi sistem harus memelihara semua informasi
tentang entitas yang diwakili.
 Pemodelan Sistem (Lanjutan)

Model sistem akan dikembangkan pada:

1. Model sistem yang ada digunakan selama rekayasa persyaratan
untuk membantu memperjelas apa yang dilakukan sistem yang
ada dan dapat digunakan sebagai dasar untuk mendiskusikan
kekuatan dan kelemahannya. Ini kemudian mengarah pada
persyaratan untuk sistem baru.
2. Model sistem baru digunakan selama rekayasa persyaratan
untuk membantu menjelaskan persyaratan yang diusulkan
kepada Stakeholder.
Perspektif dalam mengembangkan model
 2. UNIFIED MODELING LANGUAGE (UML)

• Menurut Booch, [Link]. “UML adalah bahasa standar untuk

menulis blue print PL. UML dapat digunakan untuk
memvisualisasikan, menentukan, membuat, dan
mendokumentasikan artefak dari sistem PL secara intensif”.
• UML sesuai untuk sistem pemodelan mulai dari sistem informasi
perusahaan, aplikasi berbasis web yang terdistribusi, bahkan
sampai sistem real time embedded yang sulit.
• UML adalah proses yang independen, walaupun secara optimal
harus digunakan dalam proses yang menggunakan case driven,
architecture-centric, iterative, dan incremental.
UML adalah bahasa untuk:

a. Visualizing
Beberapa hal dimodelkan secara tekstual atau dengan model
grafis. UML adalah bahasa grafis yang menggunakan
sekelompok simbol grafis. Setiap simbol dalam notasi UML
didefinisikan dengan baik secara semantik, sehingga
pengembang dapat menulis model UML dan dapat menafsirkan
model itu dengan jelas.
b. Specifying
UML dapat membangun model yang tepat, tidak ambigu, dan
lengkap. UML membahas spesifikasi semua keputusan analisis,
perancangan, dan implementasi penting yang harus dilakukan
dalam mengembangkan dan menerapkan sistem PL yang
intensif.
UML adalah bahasa untuk (lanjutan)
c. Constructing
UML bukan bahasa pemrograman visual, namun modelnya
bisa langsung terhubung ke berbagai bahasa pemrograman,
dan memungkinkan untuk memetakan ke bahasa
pemrograman seperti Java, C ++, atau Visual Basic, atau
bahkan ke tabel dalam basis data relasional atau penyimpanan
database berorientasi objek yang tetap.
d. Documenting
UML membahas dokumentasi arsitektur sistem dan semua
detailnya. UML menyediakan bahasa untuk mengekspresikan
persyaratan dan tes. UML juga menyediakan bahasa untuk
memodelkan kegiatan perencanaan proyek.
UML versi 2.0 dibagi menjadi 2 kelompok:
 Diagram-Diagram dalam UML
1. Class Diagram
Menunjukkan seperangkat kelas, antarmuka, dan kolaborasi
dan hubungan di antara mereka. Class Diagram membahas
desain statis dari suatu sistem.
2. Object Diagram
Menunjukkan satu set objek dan hubungan antara objek.
Diagram objek memodelkan instance dari hal-hal yang
terdapat dalam Class Diagram. Diagram objek digunakan
untuk memodelkan desain statis suatu sistem, untuk
memvisualisasikan, menentukan, dan mendokumentasikan
model struktural, dan membangun aspek statis sistem melalui
teknik maju (forward) dan mundur (reverse).
 Diagram-Diagram dalam UML (Lanjutan)
3. Component Diagram
Menunjukkan organisasi dan ketergantungan antar
sekumpulan komponen.
4. Deployment Diagram
Menunjukkan konfigurasi komponen dalam proses eksekusi
aplikasi. Diagram ini terdiri dari node yang merupakan
perangkat keras dan membungkus satu atau lebih komponen.
5. Use Case Diagram
Menunjukkan sebuah interaksi antara satu atau lebih aktor
dengan sistem informasi yang akan dibuat. Diagram ini sangat
penting dalam mengatur dan memodelkan perilaku suatu
sistem.
 Diagram-Diagram dalam UML (Lanjutan)

6. Sequence Diagram
Diagram interaksi yang menekankan urutan waktu pada
pesan. Menempatkan objek yang berpartisipasi dalam
interaksi pada sumbu X dan menempatkan pesan antar objek
sepanjang sumbu Y, sedangkan waktu digambarkan dari atas
ke bawah.
7. Activity Diagram
Diagram yang menunjukkan arus dari aktivitas ke aktivitas
dalam suatu sistem. Activity Diagram membahas pandangan
dinamis suatu sistem, dan sangat penting dalam pemodelan
fungsi suatu sistem dan menekankan aliran kontrol antar
objek.
 Diagram-Diagram dalam UML (Lanjutan)
8. Statechart Diagram
Menggambarkan perubahan status atau transisi status dari
sebuah mesin atau sistem atau objek. Statechart sangat penting
dalam memodelkan perilaku antarmuka, kelas, atau kolaborasi
dan menekankan perilaku dari suatu objek, yang sangat
berguna dalam memodelkan sistem reaktif.
9. Collaboration Diagram
Diagram interaksi yang menekankan struktur organisasi objek
yang mengirim dan menerima pesan. Diagram ini merupakan
perluasan dari diagram objek, yaitu memberikan tambahan
asosiasi antara objek, dan menunjukkan objek mengirimkan
message ke objek-objek yang lain.
 Diagram-Diagram dalam UML (Lanjutan)
10. Package Diagram
Diagram paket sering digunakan untuk melihat
ketergantungan antar paket. Karena sebuah paket dapat rusak
jika paket lain yang menjadi sandarannya berubah. Paket
paket juga biasa digunakan untuk mengelompokkan Use Case
dan Class.
11. Profile Diagram
Adalah mekanisme ekstensibilitas yang memungkinkan
memperluas dan menyesuaikan UML dengan menambahkan
blok penyusun baru, membuat properti baru, dan menentukan
semantik baru agar bahasanya sesuai dengan domain masalah
yang spesifik.
 Diagram-Diagram dalam UML (Lanjutan)
12. Composite Structure Diagram
Adalah diagram struktural UML yang berisi kelas, antarmuka,
paket, dan hubungannya, dan memberikan pandangan logis
dari semua, atau bagian dari sistem perangkat lunak.
13. Timing Diagram
Adalah diagram interaksi yang digunakan untuk menunjukkan
interaksi ketika tujuan utama diagram adalah untuk
mempertimbangkan waktu.
 Diagram-Diagram dalam UML (Lanjutan)
14. Interaction Diagram
Diagram UML yang digunakan untuk menangkap perilaku
interaktif suatu sistem. Diagram interaksi fokus pada
menggambarkan aliran pesan dalam suatu sistem. Diagram ini
juga digunakan untuk mewakili urutan yang terurut dalam
suatu sistem dan bertindak sebagai sarana memvisualisasikan
data real-time melalui UML.
15. Communication Diagram
Sejenis diagram interaksi, yang menunjukkan bagaimana
objek berinteraksi. Diagram komunikasi adalah perpanjangan
dari diagram objek yang menunjukkan objek beserta pesan
yang berpindah dari satu objek ke objek lainnya.
 2. USE CASE DIAGRAM
• Use Case Diagram digunakan untuk menggambarkan
serangkaian tindakan (use cases) bahwa sistem dapat
melakukan interaksi di luar sistem (aktor) dengan sistem itu
sendiri (abstraksi).
• Use Case juga digunakan untuk mengetahui fungsi apa saja
yang ada dalam sebuah sistem dan siapa yang berhak
menggunakan fungsi-fungsi itu.
• Nama Use Case didefinisikan semudah mungkin dan dapat
dipahami.
• Dua hal utama pada Use Case yaitu pendefinisian aktor dan use
case.
 Use Case Diagram (Lanjutan)

Use case digunakan untuk

• Merepresentasikan interaksi sistem – pengguna
• Mendefinisikan dan mengatur persyaratan fungsional
dalam suatu sistem
• Menentukan konteks dan persyaratan sistem
• Memodelkan aliran dasar peristiwa dalam use case
 a. Simbol-Simbol Use Case
No Nama Simbol Keterangan
1. Use Case • Digambarkan dengan elips
horizontal
• Nama Use case menggunakan
kata kerja
2. Aktor • Menggambarkan orang,
system/external entitas yang
menyediakan atau menerima
informasi
• Merupakan lingkungan luar dari
sistem
• Nama Aktor menggunakan Kata
benda
• Aktor utama digambarkan pada
pojok kiri atas dari diagram
 Simbol-Simbol Use Case
No Nama Simbol Keterangan
3. Asosiasi • Menggambarkan bagaimana
aktor berinteraksi dengan use
case
• Bukan menggambarkan aliran
data/informasi
4. Generalisasi • Gambarkan generalisasi
antara use case atau antara
aktor dengan panah tertutup
yang mengarah dari child ke
parent
 Simbol-Simbol Use Case
No Nama Simbol Keterangan
5. Relasi • Hubungan antara dua use
include case untuk menunjukkan
adanya perilaku use case yang
dimasukkan ke dalam perilaku
dari base use case
• Tanda panah terbuka harus
terarah ke sub use case
Relasi • Perluasan dari use case lain
extend (optional)
• Tanda panah terbuka harus
terarah ke base use case
6. Boundary • Untuk memperlihatkan batasan
Boxes sistem dengan lingkungan luar
sistem
Contoh penggunaan relasi include dan extend
 b. Deskripsi Use Case
• Use Case Diagram merupakan titik awal yang bagus untuk
memahami sistem, tetapi tidak memberikan detail yang
cukup bagi Analis sistem untuk benar-benar memahami
dengan tepat bagaimana masalah sistem akan dipenuhi.
• Cara terbaik untuk mengungkapkan informasi penting ini
adalah dalam bentuk deskripsi berbasis teks untuk setiap use
case.
• Tidak ada aturan yang jelas dan cepat tentang apa
sebenarnya yang masuk ke dalam deskripsi use case
menurut UML.
 Deskripsi Use Case
Use Case Name Nama Use Case yang akan dijelaskan
Indikasi tentang persyaratan mana yang dipenuhi oleh
Requirement
use case ini sebagian atau seluruhnya
Tempat use case di dalam sistem dan mengapa use case
Goal
ini penting
Pre-Conditions Apa yang terjadi sebelum use case dapat dieksekusi
Post-Conditions Apa yang terjadi setelah use case dieksekusi
Failed End Bagaimana kondisi sistem jika use case gagal
Conditions dijalankan dengan sukses
Primary Actor Aktor utama yang berpartisipasi dalam use case
Tempat untuk mendeskripsikan setiap langkah penting
Main Flow
dalam eksekusi normal use case.
Deskripsi langkah-langkah alternatif apa pun dari
Alternatif Flow
langkah-langkah yang dijelaskan di Alur Utama.
 3. ACTIVITY DIAGRAM
• Activity Diagram adalah teknik untuk menggambarkan logika
prosedural, proses bisnis, dan jaringan kerja antara pengguna
dan sistem.
• Menggunakan notasi yang mirip flowchart, meskipun terdapat
sedikit perbedaan notasi karena diagram ini mendukung
behavior paralel.
• Activity diagram dibuat berdasarkan sebuah atau beberapa
use case pada use case diagram
• Memungkinkan melakukan proses untuk memilih urutan dalam
melakukannya atau hanya menyebutkan aturan-aturan
rangkaian dasar yang harus diikuti, karena proses-proses sering
muncul secara paralel.
 Simbol-Simbol Activity Diagram
No Nama Simbol Keterangan
1. Start • Menjelaskan awal proses kerja
dalam activity diagram
• Hanya ada satu simbol start
2. End • Menandai kondisi akhir dari suatu
aktivitas dan merepresentasikan
penyelesaian semua arus proses
• Bisa lebih dari satu simbol end
3. Activity • Menunjukkan kegiatan yang
membentuk proses dalam
diagram
4. Join • Menggabungkan dua atau lebih
aktivitas bersamaan dan
menghasilkan hanya satu aktivitas
yang terjadi dalam satu waktu
 Simbol-Simbol Activity Diagram
No Nama Simbol Keterangan
5. Fork • Membagi aliran aktivitas tunggal
menjadi beberapa aktivitas
bersamaan

6. Decision • Mewakili keputusan yang memiliki

setidaknya dua jalur bercabang
yang kondisinya sesuai dengan
opsi pencabangan
7. Connector • Menunjukkan arah aliran atau
aliran kontrol dari aktivitas
8. Swimlane • Cara untuk mengelompokkan
aktivitas berdasarkan aktor
• Menggunakan garis vertikal
 4. SEQUENCE DIAGRAM
• Sequence diagram menggambarkan interaksi antar objek di
dalam dan di sekitar sistem (termasuk pengguna, display, dan
sebagainya) berupa message yang digambarkan terhadap
waktu.
• Sequence diagram menggambarkan interaksi yang fokusnya
pada urutan pesan yang dipertukarkan, bersama dengan
spesifikasi kemunculannya yang sesuai pada garis hidup.
• Sequence diagram terdiri atas dimensi vertikal (waktu) dan
dimensi horizontal (objek-objek yang terkait).
• Diagram ini secara khusus berasosiasi dengan use case
diagram
 Fungsi Sequence Diagram:

a. Menentukan detail dari Use Case.

b. Memodelkan logika prosedur, fungsi, atau operasi yang
terdapat dalam sistem.
c. Untuk melihat bagaimana objek dan komponen saling
berinteraksi satu sama lain untuk menyelesaikan suatu
proses.
d. Merencanakan dan memahami fungsionalitas secara rinci
dari skenario yang ada atau yang akan datang.
 Simbol Sequence Diagram
No Simbol Nama Fungsi
1 ;Objek Object Komponen utama Sequence Diagram

Menggambarkan orang yang sedang

2 Actor
berinteaksi dengan sistem
Menggambarkan hubungan kegiatan
3 Entity Class
yang akan dilakukan
Boundary Menggambarkan sebuah
4
Class penggambaran dari form
Control Menggambarkan penghubung antara
5
Class boundary dengan tabel
Menggambarkan tempat mulai dan
6 Life Line
berakhirnya sebuah message
7 Message Menggambarkan pengiriman pesan
 Loop dan Kondisi
• Loop dan kondisi menggunakan kerangka interaksi, yaitu cara
penandaan sebuah bagian sequence diagram.
• Kerangka terdiri dari beberapa daerah yang dipisahkan menjadi
beberapa fragmen.
• Setiap kerangka memiliki sebuah operator.
• Setiap fragmen memiliki sebuah guard.
• Guard merupakan sebuah ekspresi kondisional dalam tanda
kurung [ ], dan menunjukkan bahwa pesan akan dikirimkan jika
nilai guard benar.
 Operator Umum untuk Kerangka Interaksi

Operator Keterangan
alt Alternatif dari banyak fragmen. Hanya yang kondisinya
true yang akan dijalankan
opt Optional; fragmen akan dijalankan jika kondisi yang
mendukungnya true
par Paralel; setiap fragmen dijalankan secara paralel
loop Looping, fragmen mungkin dijalankan berulang kali dan
guard menunjukkan basis iterasi
region Critical region; fragmen hanya dapat mempunyai satu
thread untuk menjalankannya
neg Negatif; fragmen menunjukkan interaction yang salah
ref Reference; menunjukkan ke sebuah interaction yang
didefinisikan pada diagram yang lain
sd Sequence diagram
Contoh penggunaan operator:
 5. CONTOH STUDI KASUS
Tema: Sistem Pemesanan Makanan (Kue) pada Usaha UMKM
Untuk memperluas pemasaran usaha makanan, seorang anggota baru
UMKM akan mengembangkan PL menjadi aplikasi berbasis website.
Aplikasi dapat diakses langsung oleh Pelanggan untuk pembelian atau
pemesanan produk makanan.
Pelanggan melihat makanan dari katalog produk kemudian dapat
langsung membeli atau memesan jika produk tidak tersedia, dengan
mengisi form pemesanan.
Pelanggan yang akan membeli/memesan melakukan registrasi dahulu
dengan mengisi data berupa nama, email, nomor telp, alamat, dan
passwd.
Pembayaran dapat berupa transfer bank, virtual akun, dan COD.
Pelanggan yang sudah membayar akan mendapatkan notifikasi bahwa
pembayaran sudah diterima.
A. USE CASE DIAGRAM
 DESKRIPSI USE CASE
Use Case Name Beli Makanan
Pelanggan memilih produk makanan yang tersedia
Requirement
kemudian memasukkan ke dalam keranjang
Pelanggan dapat membeli produk makanan yang
Goal
sudah dimasukkan dalam keranjang
Pre-Conditions Melihat produk makanan
Post-Conditions Checkout
Failed End Conditions Stok makanan tidak tersedia atau habis
Primary Actor Pelanggan
1. Pelanggan membuka web
2. Pelanggan melihat produk makanan
Main Flow 3. Pelanggan memasukkan makanan ke keranjang
4. Sistem menyimpan data yang ada di keranjang
5. Pelanggan melakukan checkout
Alternatif Flow -
B. ACTIVITY DIAGRAM
C. SEQUENCE DIAGRAM
 Latihan
Dosen memberikan contoh kasus, kemudian
memodelkan kasus tersebut dengan diagram-
diagram yang sudah dibahas
 TUGAS KELOMPOK

Buatlah diagram sesuai dengan judul tugas

pada Pertemuan 2.

Diagram yang dibuat:

• Use Case Diagram
• Activity Diagram
• Sequence Diagram