STUDI KASUS PENGEMBANGAN PERANGKAT LUNAK.docx

STUDI KASUS PENGEMBANGAN PERANGKAT LUNAK MANAJEMEN EVENT

1. STUDI KASUS PENGEMBANGAN PERANGKAT LUNAK
CRUD
1. Aplikasi Manajemen Buku Perpustakaan
Deskripsi: Sistem ini memungkinkan pengelolaan inventaris buku di
perpustakaan. Setiap buku memiliki informasi seperti judul, penulis, tahun
terbit, dan kategori.
CRUD:
oCreate: Tambahkan data buku baru ke dalam tabel buku.
oRead: Tampilkan daftar buku yang tersedia.
oUpdate: Ubah informasi buku, seperti memperbarui tahun terbit atau
penulis.
oDelete: Hapus data buku yang sudah tidak ada di perpustakaan.
Implementasi: Siswa dapat membuat tabel buku dan membangun antarmuka
berbasis web menggunakan form HTML untuk setiap fungsi CRUD.
2. Sistem Manajemen Mahasiswa
Deskripsi: Sistem ini berguna untuk mengelola data mahasiswa di kampus,
mencakup nama, jurusan, angkatan, dan alamat.
CRUD:
oCreate: Masukkan data mahasiswa baru.
oRead: Lihat daftar seluruh mahasiswa yang terdaftar.
oUpdate: Perbarui informasi mahasiswa, misalnya mengganti jurusan
atau alamat.
oDelete: Hapus data mahasiswa yang sudah lulus atau tidak aktif.
Implementasi: Tabel mahasiswa di MySQL dan antarmuka web untuk
mengelola data. Studi kasus ini mencakup penggunaan teknik dasar untuk
menangani masukan pengguna dan menampilkan data.
3. Sistem Pendaftaran Kursus Online
Deskripsi: Sistem ini memungkinkan mahasiswa untuk mendaftar kursus
online, yang mencakup nama kursus, pengajar, jadwal, dan kategori.
CRUD:
oCreate: Tambahkan kursus baru yang tersedia untuk pendaftaran.
1

2. oRead: Tampilkan daftar kursus yang tersedia.
oUpdate: Ubah informasi kursus seperti jadwal atau pengajar.
oDelete: Hapus kursus yang sudah tidak tersedia.
Implementasi: Membuat tabel kursus dan pendaftaran, lalu
mengimplementasikan form untuk mengelola kursus serta fungsi pendaftaran
mahasiswa.
4. Sistem Manajemen Penjualan Toko Online Sederhana
Deskripsi: Sistem ini mendukung toko online kecil untuk mengelola produk,
kategori produk, harga, dan stok.
CRUD:
oCreate: Tambahkan produk baru dengan informasi lengkapnya.
oRead: Tampilkan produk yang tersedia untuk pelanggan.
oUpdate: Ubah harga atau stok produk.
oDelete: Hapus produk yang tidak lagi dijual.
Implementasi: Membuat tabel produk dengan fungsi CRUD lengkap, di mana
setiap produk yang ditambahkan atau dihapus akan langsung tercermin dalam
daftar produk toko online.
5. Sistem Manajemen Daftar Kegiatan atau Event
Deskripsi: Sistem ini digunakan untuk mengelola kegiatan atau event, seperti
seminar atau workshop. Setiap kegiatan memiliki data nama acara, tanggal,
lokasi, dan jumlah peserta.
CRUD:
oCreate: Tambahkan acara baru ke sistem.
oRead: Lihat daftar acara yang akan datang.
oUpdate: Ubah detail acara, seperti tanggal atau lokasi.
oDelete: Hapus acara yang sudah selesai atau dibatalkan.
Implementasi: Buat tabel event dengan antarmuka berbasis form HTML dan
PHP untuk menambahkan, memperbarui, dan menghapus acara.
2

3. Software Requirements Specification (SRS) untuk aplikasi web
Sistem Manajemen Daftar Kegiatan atau Event
1. Pendahuluan
1.1 Latar Belakang
Sistem Manajemen Daftar Kegiatan atau Event adalah aplikasi web yang dirancang
untuk mengelola dan menyimpan informasi tentang berbagai kegiatan atau acara.
Aplikasi ini memudahkan pengguna dalam mencatat, memperbarui, dan menghapus
data kegiatan. Pengguna dapat mengelola informasi terkait nama acara, tanggal,
lokasi, dan jumlah peserta, sehingga seluruh informasi terorganisir dan dapat diakses
dengan mudah.
1.2 Tujuan Dokumen
Dokumen ini menjelaskan spesifikasi kebutuhan perangkat lunak untuk aplikasi web
Sistem Manajemen Daftar Kegiatan atau Event. Tujuan dari dokumen ini adalah
memberikan pedoman yang jelas mengenai fungsionalitas dan fitur aplikasi, yang
mencakup kebutuhan fungsional dan non-fungsional.
1.3 Ruang Lingkup
Aplikasi ini ditujukan untuk lembaga atau organisasi yang sering mengadakan acara
atau seminar. Sistem ini memungkinkan pengguna untuk mengelola informasi acara
secara efisien, dengan fungsi untuk menambah, melihat, memperbarui, dan
menghapus data acara.
2. Deskripsi Umum
2.1 Fungsi Utama
1.Manajemen Acara:
oMenambah, memperbarui, dan menghapus informasi acara.
oMelihat daftar acara yang tersedia dengan detail lengkap.
2.Pencarian dan Penyaringan:
oMencari acara berdasarkan nama atau tanggal.
oMenyaring acara berdasarkan waktu atau lokasi.
3.Pengelolaan Peserta:
oMencatat jumlah peserta yang mendaftar pada tiap acara.
oMenampilkan informasi jumlah peserta yang hadir.
3

4. 2.2 Lingkungan Pengguna
Aplikasi ini dirancang untuk digunakan oleh staf administrasi atau panitia acara. User
interface akan disesuaikan agar mudah dipahami oleh pengguna dengan pengetahuan
dasar dalam penggunaan aplikasi berbasis web.
3. Kebutuhan Fungsional
3.1 Manajemen Acara
Menambah Acara: Sistem harus menyediakan formulir untuk menambahkan
acara baru dengan informasi berikut:
oNama Acara
oTanggal
oLokasi
oJumlah peserta yang diharapkan
Memperbarui Acara: Sistem harus memungkinkan pengguna memperbarui
informasi acara yang sudah terdaftar.
Menghapus Acara: Sistem harus menyediakan fungsi untuk menghapus acara
yang tidak lagi relevan.
3.2 Menampilkan Daftar Acara
Sistem harus menampilkan daftar acara dengan kolom informasi seperti nama
acara, tanggal, lokasi, dan jumlah peserta.
Pengguna dapat memilih acara untuk melihat detailnya.
3.3 Pencarian dan Penyaringan
Pencarian Acara: Sistem harus menyediakan fungsi pencarian untuk
menemukan acara berdasarkan nama.
Penyaringan Acara: Sistem harus memiliki opsi untuk menyaring acara
berdasarkan tanggal atau lokasi.
3.4 Pengelolaan Peserta
Sistem harus mencatat jumlah peserta yang telah mendaftar untuk acara
tertentu.
Sistem harus menampilkan jumlah peserta yang telah hadir pada acara
tersebut.
4

5. 4. Kebutuhan Non-Fungsional
4.1 Kinerja
Waktu Respons: Sistem harus memberikan respons dalam waktu kurang dari 2
detik pada setiap tindakan pengguna.
Skalabilitas: Sistem harus mampu menangani hingga 1000 pengguna aktif
sekaligus tanpa penurunan performa.
4.2 Keamanan
Autentikasi: Sistem harus menggunakan login berbasis username dan
password untuk melindungi akses data acara.
Otorisasi: Hanya pengguna yang terautentikasi yang dapat mengubah data
acara.
4.3 Portabilitas
Browser: Sistem harus dapat diakses pada browser modern seperti Chrome,
Firefox, Safari, dan Edge.
Mobile-Friendly: Sistem harus dapat diakses melalui perangkat mobile dengan
antarmuka yang responsif.
4.4 Pemeliharaan
Dokumentasi: Dokumentasi lengkap, termasuk panduan pengguna dan kode
sumber yang terdokumentasi.
Modularitas: Kode harus modular sehingga fitur baru dapat ditambahkan
dengan mudah tanpa mengganggu fungsionalitas yang ada.
5. Antarmuka Pengguna
5.1 Dasbor Utama
Menampilkan semua acara yang akan datang dengan ringkasan informasi.
Terdapat opsi filter dan search di bagian atas.
5.2 Formulir Pengelolaan Acara
Tambah/Edit Acara: Formulir untuk memasukkan atau mengubah informasi
acara dengan tombol Simpan dan Batal.
5.3 Detail Acara
Halaman yang menampilkan informasi lengkap acara dan jumlah peserta.
5

6. 6. Kebutuhan Sistem
6.1 Perangkat Lunak
Server: Apache/Nginx
Bahasa Pemrograman : PHP
Database: MySQL
Frontend: HTML, CSS, JavaScript (opsional menggunakan framework seperti
Bootstrap)
6.2 Perangkat Keras
Server Requirements: RAM minimal 4GB, CPU 2-core, dan ruang penyimpanan
minimal 20GB.
6

7. Use Case Diagram dan User Stories untuk aplikasi web Sistem Manajemen
Daftar Kegiatan atau Event.
1. Use Case Diagram
Dalam aplikasi ini, ada satu aktor utama: Admin, yang bertanggung jawab
untuk mengelola semua kegiatan/event. Berikut adalah Use Case Diagram
untuk aplikasi ini:
Use Case Diagram
plaintext
Salin kode
+-----------------------------+
| Admin |
+-----------------------------+
|
+---------+
| Login |
+---------+
|
v
+---------------------+
| Kelola Data Acara |
+---------------------+
/ | \
/ | \
v v v
+---------+ +------------+ +---------+
| Tambah | | Perbarui | | Hapus |
| Acara | | Acara | | Acara |
+---------+ +------------+ +---------+
7

8. \ /
\ /
\ /
v v
+-----------------------+
| Tampilkan Daftar |
| Acara (Read) |
+-----------------------+
|
v
+------------------+
| Cari dan Filter |
| Acara |
+------------------+
Deskripsi Use Cases
1.Login: Admin masuk ke dalam sistem dengan kredensial untuk
mengakses halaman manajemen acara.
2.Tambah Acara: Admin dapat menambahkan data acara baru, termasuk
nama acara, tanggal, lokasi, dan jumlah peserta.
3.Perbarui Acara: Admin dapat mengedit atau memperbarui informasi
acara yang sudah terdaftar.
4.Hapus Acara: Admin dapat menghapus acara yang sudah tidak berlaku
atau dibatalkan.
5.Tampilkan Daftar Acara: Admin dapat melihat daftar semua acara yang
tersedia dengan detailnya.
6.Cari dan Filter Acara: Admin dapat melakukan pencarian berdasarkan
nama atau filter berdasarkan tanggal atau lokasi acara.
2. User Stories
8

9. 1.Login
oSebagai Admin, saya ingin login ke sistem sehingga saya bisa
mengelola data acara secara aman.
oAcceptance Criteria: Admin dapat memasukkan username dan
password yang benar untuk masuk ke dalam sistem.
2.Tambah Acara
oSebagai Admin, saya ingin menambahkan acara baru dengan detail
lengkap sehingga informasi acara baru tersedia di sistem.
oAcceptance Criteria: Admin dapat menambahkan nama acara,
tanggal, lokasi, dan jumlah peserta, kemudian menyimpan data
tersebut.
3.Perbarui Acara
oSebagai Admin, saya ingin mengedit detail acara yang sudah ada
sehingga saya bisa memperbarui informasi terbaru (misalnya,
perubahan lokasi atau waktu).
oAcceptance Criteria: Admin dapat memperbarui informasi acara dan
menyimpannya dengan mudah, dan perubahan langsung terlihat
pada daftar acara.
4.Hapus Acara
oSebagai Admin, saya ingin menghapus acara yang sudah tidak
diperlukan atau dibatalkan sehingga data yang tersimpan di sistem
tetap relevan.
oAcceptance Criteria: Admin dapat memilih acara yang ingin dihapus
dan mengkonfirmasi penghapusan, setelah itu acara tersebut tidak
lagi muncul di daftar acara.
5.Tampilkan Daftar Acara
oSebagai Admin, saya ingin melihat daftar lengkap semua acara
yang tersedia sehingga saya bisa memantau dan mengelola acara
yang akan datang atau sedang berlangsung.
oAcceptance Criteria: Daftar acara menampilkan informasi lengkap
seperti nama acara, tanggal, lokasi, dan jumlah peserta, dan bisa
diakses secara cepat.
9

10. 6.Cari dan Filter Acara
oSebagai Admin, saya ingin mencari acara tertentu dengan nama
atau filter acara berdasarkan tanggal/lokasi sehingga saya dapat
dengan mudah menemukan acara yang saya cari.
oAcceptance Criteria: Admin dapat memasukkan nama acara atau
memilih filter tertentu, dan sistem akan menampilkan acara yang
relevan.
10

11. Analysis Model aplikasi web Sistem Manajemen Daftar Kegiatan atau Event
1. Entity Relationship Diagram (ERD)
Entitas dan Atribut
1.Acara
oid_acara (Primary Key)
onama_acara
otanggal
olokasi
ojumlah_peserta
2.Pengguna
oid_pengguna (Primary Key)
ousername
opassword
orole (untuk membedakan admin atau peserta jika aplikasi akan
berkembang)
Relasi Antar Entitas
Setiap Acara dapat dikelola oleh satu Pengguna (dalam hal ini adalah
Admin).
Setiap Pengguna dapat mengelola beberapa Acara (relasi one-to-many
antara Pengguna dan Acara).
2. Class Diagram
Kelas dan Metode
1.Class Pengguna
oAtribut:
username
password
11

12. role
oMetode:
login(): untuk masuk ke sistem.
logout(): untuk keluar dari sistem.
2.Class Acara
oAtribut:
nama_acara
tanggal
lokasi
jumlah_peserta
oMetode:
tambahAcara(): untuk menambahkan data acara baru.
updateAcara(): untuk memperbarui data acara.
hapusAcara(): untuk menghapus data acara.
lihatAcara(): untuk menampilkan daftar acara.
cariAcara(): untuk mencari acara berdasarkan nama atau
filter lain.
3. Sequence Diagram
Skenario: Menambah Acara Baru
1.Admin mengakses halaman Tambah Acara.
2.Sistem menampilkan formulir dengan kolom untuk nama_acara, tanggal,
lokasi, dan jumlah_peserta.
3.Admin memasukkan informasi acara dan mengirimkannya.
4.Sistem memvalidasi data input dan menyimpan data ke dalam basis data.
5.Sistem memberikan notifikasi bahwa acara telah berhasil ditambahkan
dan menampilkan daftar acara yang terbaru.
Skenario: Menghapus Acara
12

13. 1.Admin memilih acara yang ingin dihapus dari daftar.
2.Sistem menampilkan peringatan konfirmasi penghapusan.
3.Admin mengonfirmasi penghapusan acara.
4.Sistem menghapus data acara dari basis data.
5.Sistem memperbarui daftar acara dan menampilkan notifikasi bahwa
acara telah berhasil dihapus.
4. Activity Diagram
Menambah Acara
1.Mulai
2.Admin mengakses menu Tambah Acara
3.Sistem menampilkan formulir pengisian data acara
4.Admin memasukkan detail acara dan mengirim data
5.Sistem memvalidasi data
oJika validasi gagal, tampilkan pesan kesalahan
oJika validasi berhasil, lanjut ke penyimpanan data
6.Sistem menyimpan data acara ke dalam database
7.Sistem menampilkan konfirmasi berhasil
8.Selesai
5. Data Flow Diagram (DFD)
Level 1 DFD (Fokus pada aliran data utama)
1.Login
oPengguna memasukkan kredensial -> Sistem memverifikasi ->
Sistem memberikan akses atau menampilkan pesan kesalahan.
2.Kelola Data Acara
13

14. oPengguna mengirim permintaan tambah/edit/hapus acara ->
Sistem memproses permintaan -> Sistem memperbarui database
dan memberikan notifikasi hasil.
3.Tampilkan Daftar Acara
oPengguna meminta daftar acara -> Sistem mengambil data dari
database -> Sistem menampilkan daftar acara kepada pengguna.
6. Use Case Descriptions
Berikut adalah deskripsi mendalam dari beberapa use case utama:
1.Use Case: Tambah Acara
oAktor: Admin
oPrekondisi: Admin sudah login
oDeskripsi: Admin mengakses halaman tambah acara dan
memasukkan detail acara seperti nama, tanggal, lokasi, dan
jumlah peserta. Sistem memvalidasi dan menyimpan data baru.
oPostkondisi: Data acara baru tersimpan di database dan muncul di
daftar acara.
oExceptions: Sistem menampilkan pesan error jika data tidak valid
atau penyimpanan gagal.
2.Use Case: Hapus Acara
oAktor: Admin
oPrekondisi: Admin sudah login
oDeskripsi: Admin memilih acara yang akan dihapus. Sistem
meminta konfirmasi dan menghapus data acara jika dikonfirmasi.
oPostkondisi: Data acara dihapus dari database dan daftar acara
diperbarui.
oExceptions: Sistem menampilkan pesan error jika penghapusan
gagal.
3.Use Case: Cari dan Filter Acara
oAktor: Admin
14

15. oPrekondisi: Admin sudah login
oDeskripsi: Admin memasukkan kata kunci atau filter tertentu
untuk mencari acara. Sistem memproses permintaan dan
menampilkan hasil pencarian.
oPostkondisi: Sistem menampilkan daftar acara yang relevan.
oExceptions: Sistem menampilkan pesan error jika pencarian gagal.
15

16. Design Model untuk aplikasi web Sistem Manajemen Daftar Kegiatan atau Event
1. Arsitektur Aplikasi
Aplikasi ini akan dibangun dengan arsitektur berbasis MVC (Model-View-
Controller) untuk memisahkan logika aplikasi, tampilan, dan manajemen data.
Komponen Utama Arsitektur:
Model: Mengelola data dan aturan bisnis, termasuk entitas seperti acara
dan pengguna.
View: Terdiri dari antarmuka pengguna (User Interface) yang
menampilkan data kepada pengguna, seperti halaman daftar acara,
halaman detail acara, dan formulir untuk tambah/edit acara.
Controller: Bertindak sebagai penghubung antara model dan view,
menangani permintaan dari pengguna, memproses data dari model, dan
menampilkan hasil ke view.
2. Desain Database
Database untuk sistem ini akan memiliki satu tabel utama untuk menyimpan
data acara, serta satu tabel pengguna untuk autentikasi admin. Berikut adalah
struktur tabel:
Tabel acara
id_acara (INT, Primary Key, Auto Increment): ID unik untuk setiap acara.
nama_acara (VARCHAR): Nama acara.
tanggal (DATE): Tanggal acara.
lokasi (VARCHAR): Lokasi acara.
jumlah_peserta (INT): Jumlah peserta yang diharapkan.
Tabel pengguna
id_pengguna (INT, Primary Key, Auto Increment): ID unik untuk setiap
pengguna.
username (VARCHAR): Nama pengguna.
password (VARCHAR): Kata sandi pengguna yang dienkripsi.
3. Desain Interface Pengguna (User Interface)
Halaman Utama (Daftar Acara)
16

17. Fitur: Menampilkan semua acara yang tersedia dalam bentuk tabel atau
kartu.
Komponen UI:
oTabel/Kartu acara dengan kolom untuk nama acara, tanggal,
lokasi, dan jumlah peserta.
oTombol Tambah Acara Baru untuk mengarahkan ke halaman
formulir tambah acara.
oFitur Search dan Filter untuk mencari atau menyaring acara
berdasarkan tanggal atau lokasi.
Halaman Tambah Acara
Fitur: Memungkinkan pengguna menambahkan acara baru ke dalam
sistem.
Komponen UI:
oFormulir input dengan kolom untuk nama_acara, tanggal, lokasi,
dan jumlah_peserta.
oTombol Simpan dan Batal.
Halaman Edit Acara
Fitur: Memungkinkan pengguna memperbarui informasi acara yang ada.
Komponen UI:
oFormulir edit serupa dengan halaman tambah acara, diisi dengan
informasi yang sudah ada.
oTombol Simpan Perubahan dan Batal.
Halaman Login
Fitur: Autentikasi pengguna sebelum mengakses sistem.
Komponen UI:
oInput username dan password.
oTombol Login.
4. Desain Interaksi Antar Komponen
1.Login:
17

18. oInput: Username dan password.
oProses: Controller memverifikasi data login melalui Model
Pengguna.
oOutput: Jika valid, pengguna diarahkan ke halaman utama; jika
tidak valid, pesan kesalahan ditampilkan.
2.Menambahkan Acara :
oInput: Nama acara, tanggal, lokasi, jumlah peserta.
oProses: Controller memvalidasi data input dan mengirimkannya ke
Model Acara untuk disimpan di database.
oOutput: Jika sukses, sistem menampilkan daftar acara terbaru,
termasuk acara yang baru ditambahkan.
3.Mengedit Acara:
oInput: Perubahan pada detail acara.
oProses: Controller memperbarui data acara melalui Model Acara.
oOutput: Jika sukses, sistem kembali ke halaman daftar acara
dengan informasi yang diperbarui.
4.Menghapus Acara:
oInput: ID acara yang akan dihapus.
oProses: Controller meminta Model Acara untuk menghapus acara
yang sesuai di database.
oOutput: Sistem menghapus acara dari daftar dan memperbarui
tampilan.
5.Pencarian dan Penyaringan Acara:
oInput: Kata kunci pencarian atau kriteria filter (misalnya, tanggal
atau lokasi).
oProses: Controller memproses kriteria pencarian/filter dan
meminta Model Acara untuk mencari acara yang sesuai.
oOutput: Sistem menampilkan hasil pencarian/filter di halaman
daftar acara.
5. Wireframe Desain Antarmuka
18

19. Halaman Utama
Header: Menampilkan judul aplikasi, serta tombol logout.
Main Content:
oSearch Bar: Input untuk pencarian acara.
oFilter Options: Dropdown untuk memilih filter.
oTable/Kartu Daftar Acara: Menampilkan daftar acara dengan
kolom nama acara, tanggal, lokasi, dan jumlah peserta.
oTambah Acara Button: Tombol untuk membuka formulir tambah
acara.
Formulir Tambah/Edit Acara
Input Fields: Nama acara, tanggal, lokasi, dan jumlah peserta.
Buttons: Tombol Simpan dan Batal.
Halaman Login
Username Field: Input untuk nama pengguna.
Password Field: Input untuk kata sandi.
Login Button: Tombol untuk masuk.
6. Rancangan Validasi dan Keamanan
1.Validasi Data
oSetiap input, seperti nama acara, tanggal, lokasi, dan jumlah
peserta, harus divalidasi agar sesuai format dan persyaratan data.
oJumlah peserta harus berupa angka dan tanggal harus valid.
2.Keamanan
oEnkripsi password menggunakan hashing (misalnya, bcrypt).
oPenerapan proteksi CSRF pada formulir.
oAutentikasi dan otorisasi untuk mencegah akses tanpa izin.
7. Teknologi yang Direkomendasikan
19

20. Frontend: HTML, CSS (dapat menggunakan Bootstrap atau framework
CSS lainnya), JavaScript untuk interaktivitas.
Backend: PHP sebagai bahasa pemrograman server-side.
Database: MySQL untuk penyimpanan data acara dan pengguna.
Server: Apache atau Nginx untuk hosting aplikasi.
20

21. UI/UX dari aplikasi web Sistem Manajemen Daftar Kegiatan atau
Event
1. Wireframe Desain untuk Halaman Utama (Daftar Acara)
Komponen Utama:
Header:
oBerisi judul aplikasi, nama pengguna yang sedang login, serta opsi
logout.
Navigasi Samping (Opsional jika banyak fitur tambahan):
oTautan cepat ke halaman seperti Daftar Acara, Tambah Acara Baru,
Pengaturan, atau Bantuan.
Konten Utama:
oSearch Bar: Di bagian atas daftar acara, terdapat kolom pencarian yang
memungkinkan pengguna mencari acara berdasarkan nama atau kata
kunci tertentu.
oFilter Options: Tombol dropdown atau pilihan filter di samping kolom
pencarian untuk memfilter acara berdasarkan tanggal atau lokasi.
oDaftar Acara: Tabel atau tampilan kartu dengan kolom berikut:
Nama Acara
Tanggal
Lokasi
Jumlah Peserta
Aksi (untuk opsi Edit dan Hapus)
oTombol Tambah Acara Baru: Tombol ini akan mengarahkan pengguna
ke halaman formulir untuk menambahkan acara baru.
Visual
Desain yang bersih dan modern dengan gaya flat design atau material design
untuk memberikan tampilan yang minimalis namun fungsional.
Penggunaan warna kontras antara latar belakang dan teks, misalnya latar
belakang putih dengan elemen biru atau abu-abu untuk elemen tombol.
UX Considerations:
21

22. Responsif: Pastikan desain menyesuaikan dengan baik pada berbagai
perangkat (desktop, tablet, mobile).
Kecepatan Akses: Optimalkan komponen untuk akses cepat, terutama pada
fitur pencarian dan filter.
Notifikasi Pop-up: Setiap kali ada aksi penting seperti menambah,
memperbarui, atau menghapus acara, tampilkan notifikasi pop-up untuk
memastikan pengguna.
2. Desain Formulir Tambah/Edit Acara
Komponen Utama:
Input Fields:
oNama Acara
oTanggal (pilih dengan date picker untuk memudahkan input)
oLokasi
oJumlah Peserta (validasi input angka saja)
Tombol Simpan: Untuk menyimpan data acara baru atau perubahan data
acara.
Tombol Batal: Untuk membatalkan perubahan dan kembali ke halaman daftar
acara.
Visual:
Setiap kolom input disusun dalam satu kolom vertikal untuk memudahkan
pembacaan dan pengisian.
Teks placeholder pada setiap kolom input yang menjelaskan apa yang perlu
diisi.
Tombol Simpan dan Batal berukuran besar dan jelas, dengan warna berbeda
untuk menarik perhatian.
UX Considerations:
Validasi Real-Time: Berikan pesan error langsung jika ada kolom yang tidak
diisi dengan benar, seperti nama acara yang terlalu pendek atau tanggal yang
tidak valid.
Auto-Fill (untuk Halaman Edit Acara): Isi kolom dengan data acara yang sudah
ada sehingga pengguna bisa langsung melakukan perubahan tanpa harus
mengisi dari awal.
22

23. Konfirmasi Pop-up: Muncul setelah tombol Simpan ditekan untuk memastikan
perubahan disimpan.
3. Desain Halaman Login
Komponen Utama:
Username Field: Input untuk nama pengguna.
Password Field: Input untuk kata sandi dengan simbol atau teks yang
menyarankan keamanan, seperti ikon mata untuk melihat atau
menyembunyikan kata sandi.
Login Button: Tombol untuk masuk yang langsung mengarahkan pengguna ke
halaman utama jika kredensial benar.
Forgot Password Link (opsional): Jika aplikasi mendukung reset kata sandi.
Visual:
Desain sederhana dan fokus pada fungsionalitas.
Desain login berada di tengah halaman agar mudah terlihat oleh pengguna.
Warna yang kontras untuk tombol Login, seperti biru cerah atau hijau, agar
menonjol di halaman.
UX Considerations:
Validasi Cepat: Jika kredensial salah, tampilkan pesan error tanpa reload
halaman.
Pesan Kesalahan yang Jelas: Tampilkan pesan error yang spesifik, seperti
"Username atau Password salah" daripada hanya "Login gagal."
Aksesibilitas: Sesuaikan warna dan ukuran teks untuk memastikan mudah
diakses pengguna.
4. Desain Pencarian dan Filter Acara
Komponen Utama:
Kolom Pencarian: Ditempatkan di atas daftar acara dan memungkinkan
pencarian nama acara secara real-time.
Filter Dropdown: Pilihan untuk memfilter berdasarkan tanggal dan lokasi.
Reset Filter: Tombol untuk mengembalikan tampilan ke daftar acara lengkap
setelah pencarian atau filter diterapkan.
23

24. UX Considerations:
Pencarian Real-Time: Daftar acara diperbarui secara otomatis saat pengguna
mengetik di kolom pencarian.
Desain Filter yang Sederhana: Filter disusun dalam bentuk dropdown atau
checkbox untuk memudahkan pengguna memilih kriteria pencarian.
Indikator Hasil: Tampilkan jumlah acara yang cocok dengan filter atau
pencarian untuk memberikan umpan balik instan.
5. Desain Tombol dan Notifikasi
Tombol Aksi (Simpan, Edit, Hapus, Login)
Warna tombol yang konsisten di seluruh aplikasi untuk menciptakan
keseragaman.
Warna merah untuk tombol Hapus dan warna biru atau hijau untuk Simpan dan
Login.
Notifikasi
Popup Notifikasi: Notifikasi muncul di sudut layar setelah aksi seperti
menambah atau menghapus acara berhasil.
Desain Notifikasi yang Singkat: Notifikasi hanya berisi informasi inti, seperti
“Acara berhasil ditambahkan” atau “Acara berhasil dihapus.”
Waktu Tampil: Notifikasi muncul selama beberapa detik lalu menghilang
otomatis.
Contoh Warna dan Gaya Desain:
Palet Warna: Gunakan warna lembut seperti biru, abu-abu, atau putih untuk
latar belakang, dan warna yang lebih mencolok untuk tombol (biru tua untuk
tombol simpan, merah untuk hapus).
Tipografi: Gunakan font yang modern dan mudah dibaca seperti Arial atau
Roboto dengan ukuran teks yang cukup besar.
Ikon: Tambahkan ikon sederhana untuk setiap aksi utama (misalnya, ikon pensil
untuk edit, ikon tempat sampah untuk hapus, dan ikon tambah untuk acara
baru).
24

25. SOFTWARE TESTING Aplikasi web Sistem Manajemen Daftar Kegiatan atau
Event
1. Functional Testing
Pengujian ini berfokus pada memverifikasi apakah setiap fitur aplikasi berjalan sesuai
dengan spesifikasi fungsional. Pengujian ini melibatkan beberapa skenario, seperti:
Skenario Uji
Login:
oTest Case: Masukkan kredensial yang valid.
Expected Result: Pengguna berhasil login dan diarahkan ke
halaman utama.
oTest Case: Masukkan kredensial yang tidak valid.
Expected Result: Tampil pesan kesalahan dan pengguna tetap
berada di halaman login.
Tambah Acara:
oTest Case: Isi semua kolom dengan data valid dan klik "Simpan".
Expected Result: Acara baru ditambahkan dan terlihat di
halaman daftar acara.
oTest Case: Kosongkan satu atau lebih kolom lalu klik "Simpan".
Expected Result: Tampil pesan error yang meminta pengguna
melengkapi kolom yang kosong.
Edit Acara:
oTest Case: Edit data acara yang sudah ada dan klik "Simpan".
Expected Result: Data acara diperbarui dan terlihat perubahan di
halaman daftar acara.
Hapus Acara:
oTest Case: Klik tombol "Hapus" pada acara yang ingin dihapus.
Expected Result: Tampil konfirmasi, dan acara dihapus setelah
dikonfirmasi.
Pencarian dan Filter:
oTest Case: Masukkan kata kunci untuk mencari acara tertentu.
25

26. Expected Result: Daftar acara ditampilkan sesuai dengan kata
kunci yang dicari.
oTest Case: Terapkan filter berdasarkan tanggal atau lokasi.
Expected Result: Daftar acara hanya menampilkan hasil yang
sesuai dengan kriteria filter.
2. Usability Testing
Pengujian ini memastikan bahwa aplikasi mudah digunakan dan antarmuka pengguna
(UI) intuitif. Usability testing melibatkan umpan balik pengguna langsung untuk
mengidentifikasi potensi perbaikan pada desain UI/UX.
Skenario Uji
Kemudahan Navigasi:
oTest Case: Uji alur navigasi dari halaman login ke halaman daftar acara,
lalu ke halaman tambah/edit acara.
Expected Result: Pengguna dapat dengan mudah beralih antar
halaman tanpa kebingungan.
Kejelasan Teks dan Label:
oTest Case: Periksa apakah semua tombol, label, dan teks placeholder di
formulir jelas dan informatif.
Expected Result: Pengguna memahami fungsi setiap tombol dan
label tanpa bantuan tambahan.
Konsistensi Desain:
oTest Case: Evaluasi apakah desain (warna, font, tata letak) konsisten di
seluruh aplikasi.
Expected Result: Tampilan konsisten di setiap halaman, dan
pengalaman pengguna seragam.
3. Performance Testing
Pengujian ini mengevaluasi kinerja aplikasi dalam berbagai kondisi, terutama untuk
memastikan bahwa aplikasi tetap responsif saat menangani banyak data atau
pengguna.
Skenario Uji
Responsiveness:
26

27. oTest Case: Uji waktu respon aplikasi untuk memuat halaman utama
dengan daftar acara penuh (misalnya, lebih dari 100 acara).
Expected Result: Halaman tetap responsif dan memuat dalam
waktu yang wajar (misalnya, kurang dari 3 detik).
Load Testing:
oTest Case: Simulasikan beberapa pengguna yang mengakses aplikasi
secara bersamaan.
Expected Result: Aplikasi tetap stabil dan tidak mengalami
penurunan performa signifikan.
Stress Testing:
oTest Case: Masukkan data yang sangat besar atau tidak wajar (misalnya,
jumlah peserta lebih dari batas maksimum yang ditentukan).
Expected Result: Aplikasi menangani data ekstrem dengan
menampilkan pesan error yang sesuai atau mencegah input tidak
wajar.
4. Security Testing
Pengujian keamanan memastikan bahwa aplikasi terlindungi dari berbagai ancaman
keamanan dan melindungi data pengguna serta data acara.
Skenario Uji
SQL Injection:
oTest Case: Masukkan karakter atau skrip SQL di kolom input.
Expected Result: Aplikasi mengamankan input dengan
mencegah SQL Injection, dan input seperti itu menghasilkan
pesan error yang aman.
XSS (Cross-Site Scripting):
oTest Case: Masukkan skrip HTML atau JavaScript dalam kolom input.
Expected Result: Aplikasi menolak input skrip dan mencegah
eksekusi skrip di halaman web.
Autentikasi dan Akses:
oTest Case: Coba akses halaman atau data yang memerlukan login tanpa
login.
27

28. Expected Result: Pengguna diarahkan ke halaman login atau
menampilkan pesan “Akses Ditolak”.
oTest Case: Coba akses fitur administrasi menggunakan akun dengan hak
akses terbatas.
Expected Result: Aplikasi memblokir tindakan ini dan
menampilkan pesan error.
5. Compatibility Testing
Pengujian ini memastikan bahwa aplikasi dapat berjalan dengan baik di berbagai
perangkat dan browser.
Skenario Uji
Cross-Browser Testing:
oTest Case: Buka aplikasi di berbagai browser seperti Chrome, Firefox,
Safari, dan Edge.
Expected Result: Aplikasi berfungsi dan tampil dengan benar di
semua browser.
Device Compatibility:
oTest Case: Uji aplikasi pada perangkat desktop, tablet, dan ponsel dengan
berbagai resolusi layar.
Expected Result: Aplikasi responsif dan UI menyesuaikan dengan
perangkat yang digunakan.
6. User Acceptance Testing (UAT)
Pengujian ini dilakukan untuk memastikan aplikasi sesuai dengan kebutuhan
pengguna akhir dan memenuhi tujuan utama dari aplikasi.
Skenario Uji
Review dari Pengguna Akhir:
oTest Case: Berikan aplikasi kepada sejumlah pengguna akhir (misalnya,
admin atau staf yang akan mengelola acara) untuk melakukan tugas
sehari-hari.
Expected Result: Pengguna akhir dapat menyelesaikan semua
tugas dengan lancar dan memberikan umpan balik positif tentang
kemudahan penggunaan.
28

29. Verifikasi Proses Bisnis:
oTest Case: Verifikasi apakah setiap fitur yang diimplementasikan
mendukung proses bisnis pengelolaan acara secara keseluruhan.
Expected Result: Aplikasi mendukung semua kebutuhan
manajemen acara, termasuk pencatatan, pencarian, dan
pembaruan data acara dengan efisien.
29

30. LINK YOUTUBE
https://www.youtube.com/watch?v=0IBQwx0jfU8
https://www.youtube.com/watch?v=RxmKSIelA7s
https://www.codepolitan.com/blog/tutorial-membuat-crud-php-dengan-mysql-
59897c72d8470/
https://www.youtube.com/watch?v=BS71hKtSuU0
30