Data Flow Diagram (DFD)

 

1. Konsep Dasar DFD

a. Pengertian DFD

DFD (Data Flow Diagram) adalah diagram yang digunakan untuk menggambarkan aliran data dalam sebuah sistem secara logis.
- Fungsi utamanya:

• Memvisualisasikan bagaimana data masuk, diproses, dan disimpan dalam sistem.

• Membantu dalam analisis kebutuhan dan desain awal sistem informasi.

• Memudahkan komunikasi antara tim pengembang dan stakeholder.

b. Perbedaan DFD vs UML Activity Diagram

Data Flow Diagram (DFD) dan UML Activity Diagram sama-sama digunakan dalam tahap analisis dan desain sistem, tetapi keduanya memiliki fokus dan tujuan yang berbeda. DFD digunakan untuk memodelkan bagaimana data mengalir di dalam sistem. Fokus utamanya adalah pada alur data dari satu proses ke proses lainnya, serta bagaimana data disimpan dan diterima dari entitas luar. Sementara itu, UML Activity Diagram lebih menekankan pada alur aktivitas atau urutan proses bisnis yang terjadi dalam sistem, mirip seperti flowchart. Activity Diagram menampilkan logika alur kerja secara detail, termasuk keputusan (branching), paralelisme, dan urutan aktivitas yang dilakukan oleh sistem atau pengguna. Dengan kata lain, DFD lebih cocok digunakan untuk mendesain arsitektur data dan sistem informasi, sedangkan Activity Diagram digunakan untuk menggambarkan bagaimana proses atau kegiatan terjadi secara kronologis dalam sistem.

c. Simbol-Simbol Utama DFD

1. External Entity (Entitas Eksternal)
   -Sumber atau tujuan data di luar sistem.
   -Contoh: Pelanggan, Admin, Supplier

2. Process (Proses)
   -Mengubah input menjadi output.
   -Contoh: Proses Pemesanan, Verifikasi Pembayaran

3. Data Store (Penyimpanan Data)
   -Tempat menyimpan data sementara atau permanen.
   -Contoh: Database Pelanggan, Riwayat Transaksi

4. Data Flow (Alur Data)
   - Menunjukkan arah dan jenis data yang mengalir.
   -Contoh: "Form Pemesanan", "Data Pembayaran"

2. Langkah Teknis Pembuatan DFD

a. Identifikasi Entitas Eksternal

Langkah awal adalah menentukan siapa saja yang berinteraksi dengan sistem.
Contoh Entitas:

• Pelanggan (mengirim pesanan)

• Admin (mengelola data)

• Supplier (menyediakan barang)

b. Tentukan Proses Utama dalam Sistem

Identifikasi proses yang terjadi dalam sistem.
Contoh Proses:

• Proses Pemesanan

• Proses Pembayaran

• Verifikasi Stok

• Pengiriman Barang

c. Buat Context Diagram (DFD Level 0)

• Digambarkan sebagai 1 kotak besar (sistem secara keseluruhan).

• Menunjukkan hubungan antara entitas eksternal dan sistem.

Contoh: [Pelanggan] ---> (Sistem Pemesanan Online) ---> [Admin]

Kotak sistem punya panah data dari dan ke entitas luar, tanpa detail proses internal.

d. Pecah Context Diagram ke dalam DFD Level 1

• Kotak sistem dipecah menjadi beberapa proses utama.

• Tambahkan data store dan detail alur data antar proses.

Contoh:

1.0 Terima Pesanan
2.0 Verifikasi Pembayaran
3.0 Update Stok Barang
4.0 Proses Pengiriman

Data Store:

• D1: Database Pelanggan

• D2: Transaksi

e. Buat DFD Level 2 (Opsional)

Jika ada proses kompleks, dipecah lagi lebih rinci.

Contoh:

• Proses 2.0 “Verifikasi Pembayaran” → bisa dipecah jadi:

  • 2.1 Cek Bukti Pembayaran

  • 2.2 Konfirmasi Validasi

  • 2.3 Update Status Pembayaran

3. Alat yang Bisa Digunakan

Terdapat berbagai alat bantu yang dapat digunakan untuk membuat Data Flow Diagram (DFD), baik secara online maupun offline. Salah satu alat yang paling populer adalah Draw.io, sebuah aplikasi web gratis yang menyediakan banyak bentuk dan template DFD yang mudah digunakan langsung di browser. Selain itu, Microsoft Visio merupakan alat profesional yang banyak digunakan di lingkungan korporat untuk membuat diagram teknis dan bisnis, termasuk DFD, meskipun bersifat berbayar. Alternatif lainnya adalah Lucidchart, platform berbasis cloud yang mendukung kolaborasi tim secara real-time dan memiliki fitur untuk membuat berbagai jenis diagram, termasuk DFD dan UML. Bagi pengguna yang juga ingin menggambar diagram UML secara lebih teknis, StarUML adalah pilihan yang bagus. StarUML merupakan aplikasi desktop yang mendukung berbagai jenis diagram dan cocok untuk perancangan sistem perangkat lunak secara mendalam. Pemilihan alat tergantung pada kebutuhan pengguna, apakah untuk penggunaan cepat dan praktis atau untuk desain sistem yang kompleks dan teknis.

Menjelaskan Prinsip Perancangan Perangkat Lunak

 

1) Prinsip Modularitas & Reusability

A. Modularitas

• Sistem dibagi menjadi modul kecil → fokus pada satu fungsi tertentu.

• Memudahkan pengujian, debugging, dan pengembangan paralel.

B. Reusability

• Kode atau modul dapat digunakan kembali dalam proyek lain → hemat waktu dan biaya.

C. DRY (Don't Repeat Yourself)

• Hindari duplikasi kode.

• Solusinya: pakai fungsi, kelas, atau modul yang reusable.

D. KISS (Keep It Simple, Stupid)

• Jaga kode tetap sederhana.

• Kode sederhana = lebih mudah dipahami dan lebih sedikit bug.

2) Prinsip SOLID dalam OOP

Prinsip dasar untuk menciptakan desain OOP yang fleksibel dan maintainable:

A. S - Single Responsibility Principle

• Setiap kelas hanya punya satu tanggung jawab.

• Contoh: Kelas Buku hanya menyimpan info buku, bukan mengatur peminjaman.

B. O - Open/Closed Principle

• Kode harus terbuka untuk ekstensi, tapi tertutup untuk modifikasi.

• Tambah fitur tanpa ubah kode lama → pakai inheritance atau interface.

C. L - Liskov Substitution Principle

• Subclass harus bisa menggantikan superclass tanpa ubah hasil program.

• Jangan pakai subclass yang melanggar perilaku dasar induknya.

D. I - Interface Segregation Principle

• Interface harus spesifik, tidak terlalu umum.

• Misal: jangan gabungkan metode terbang() ke Kendaraan, karena mobil tidak bisa terbang.

E. D - Dependency Inversion Principle

• Kelas tidak boleh bergantung langsung ke kelas lain, tapi ke abstraksi (interface).

• Contoh: OrderService bergantung pada interface PaymentService, bukan kelas spesifik seperti PaypalService.

3) Kohesi dan Coupling

A. High Cohesion

• Modul hanya fokus pada satu fungsi → lebih mudah dipahami & dikelola.

B. Low Coupling

• Modul tidak terlalu tergantung pada modul lain → lebih fleksibel dan aman saat diubah.

C. Dependency Injection

• Cara menyuntikkan dependensi dari luar, bukan dibuat langsung dalam kelas.

• Contoh: Constructor Injection, Setter Injection, Interface Injection.

• Manfaat: mengurangi coupling dan meningkatkan fleksibilitas serta testability.

4. Memvisualisasikan Diagram untuk Perancangan Perangkat Lunak

1) Use Case Diagram

A. Notasi:

• Aktor: Digambarkan dengan gambar orang (User, Admin, dll).

• Use Case: Digambarkan dengan oval (Login, Registrasi, Dll).

• Relasi:

  • <<include>>: Proses wajib terjadi (contoh: Login <<include>> Validasi).

  • <<extend>>: Proses tambahan bersifat opsional (contoh: Promo <<extend>> Pembayaran).

B. Contoh Studi Kasus: Sistem e-Commerce

• Aktor: Konsumen, Member, Admin.

• Use Case: Login, Registrasi, Browse Produk, Isi Keranjang, Kelola Produk.

2) Entity-Relationship Diagram (ERD)

A. Relasi:

• 1:1 → Satu ke satu.

• 1:M → Satu ke banyak. Contoh: 1 User bisa punya banyak Aplikasi.

• M:N → Banyak ke banyak. Contoh: 1 Aplikasi bisa punya banyak Kategori dan sebaliknya.

B. Normalisasi Database

• 1NF: Semua kolom berisi data atomic.

• 2NF: Semua atribut tergantung pada primary key.

• 3NF: Tidak ada ketergantungan antar atribut non-key.

3) Class Diagram

Diagram ini menjelaskan struktur kelas dan hubungannya.

A. Jenis Relasi antar kelas:

• Association: Hubungan biasa antara dua kelas.

• Aggregation: Hubungan "memiliki" tapi objek bisa berdiri sendiri.

• Composition: Hubungan "memiliki" yang kuat. Jika induknya hilang, anaknya ikut hilang.

• Inheritance: Pewarisan atribut dan method dari superclass.

B. Contoh Studi Kasus: Sistem Manajemen Mahasiswa

• Mahasiswa → punya KRS, Nilai, dll.

• Dosen → punya Jadwal.

4) Diagram Lainnya

A. Activity Diagram (Workflow Proses)

• Menunjukkan alur proses sistem dari awal hingga akhir.

• Contoh: Proses pengisian KRS → Validasi Dosen Wali → Pencetakan oleh Staff.

B. Sequence Diagram (Interaksi Antar Objek)

• Menjelaskan urutan pesan yang dikirim antar objek.

• Contoh: User membuka aplikasi → pilih instrumen → sistem load → tampilkan.

Memahami Kebutuhan Perangkat Lunak dan Teknik Analisa Kebutuhan Perangkat Lunak

 

1. Jenis-Jenis Kebutuhan Perangkat Lunak

• Kebutuhan Fungsional
  Menjelaskan apa saja yang harus dilakukan oleh sistem. Contohnya seperti fitur login, fitur pencarian, atau fitur checkout pada aplikasi e-commerce.
  ➤ Ini adalah “fungsi utama” yang harus tersedia agar sistem bisa digunakan.

• Kebutuhan Non-Fungsional
  Berhubungan dengan kualitas sistem, seperti kecepatan, keamanan, dan kemudahan penggunaan.
  ➤ Contoh: Aplikasi harus bisa diakses dalam waktu kurang dari 3 detik.

• Kebutuhan Domain
  Merujuk pada aturan khusus di suatu bidang. Misalnya aplikasi rumah sakit harus sesuai dengan SOP medis.
  ➤ Ini penting agar sistem sesuai dengan standar industri tertentu.

2. Teknik Analisis Kebutuhan Perangkat Lunak

• Wawancara
  Bertanya langsung kepada pengguna atau pemilik sistem untuk tahu kebutuhan mereka.

• Kuesioner
  Menggunakan daftar pertanyaan tertulis yang dibagikan ke banyak responden untuk mengumpulkan opini.

• Observasi
  Mengamati langsung aktivitas pengguna untuk mengetahui kebutuhan yang mungkin tidak mereka sadari.

• Studi Dokumen
  Menganalisis dokumen atau catatan sistem lama agar dapat memahami proses kerja yang sudah ada.

• Prototyping
  Membuat versi awal sistem untuk mendapatkan masukan dari pengguna sebelum sistem dikembangkan secara penuh.

• JAD (Joint Application Development)
  Diskusi intensif antara pengguna, pengembang, dan stakeholder dalam satu sesi untuk merumuskan kebutuhan sistem.

3. Proses Analisis Kebutuhan

1. Identifikasi Pemangku Kepentingan
   Siapa saja yang akan menggunakan atau terlibat dengan sistem, misalnya pengguna akhir, manajer, developer.

2. Pengumpulan Kebutuhan
   Dilakukan dengan teknik wawancara, observasi, prototipe, dll.

3. Analisis & Spesifikasi
   Menyusun kebutuhan yang terkumpul secara rinci dan sistematis dalam bentuk dokumen SRS (Software Requirement Specification).

4. Validasi Kebutuhan
   Memastikan semua kebutuhan yang dicatat sudah sesuai dengan harapan pengguna.

4. Pengelolaan Kebutuhan

• Dokumentasi Kebutuhan:
  Semua kebutuhan harus dicatat secara jelas dan lengkap.

• Validasi:
  Memastikan bahwa kebutuhan benar-benar dibutuhkan dan tidak ada yang salah tafsir.

• Prioritas Kebutuhan:
  Menentukan fitur mana yang harus dikerjakan dulu.

• Manajemen Perubahan:
  Jika ada perubahan di tengah jalan, harus dikelola agar tidak merusak sistem yang sudah dirancang.

5. Perancangan Perangkat Lunak (Software Design)

• Konsep:
  Merancang adalah proses mengubah kebutuhan menjadi bentuk rancangan teknis.

• Tujuan:
  Agar pengembangan sistem jadi lebih terstruktur, efisien, dan minim kesalahan.

• Pendekatan:
  Bisa dilakukan dengan metode Top-Down (dari keseluruhan ke detail) atau Bottom-Up (dari detail ke keseluruhan).

• Jenis Perancangan:

  • Arsitektural: Struktur utama sistem, misalnya model MVC atau 3-layer.

  • Tingkat Menengah: Desain modul-modul dan hubungannya.

  • Tingkat Rendah: Detil implementasi seperti algoritma dan flowchart.

Kesimpulan

Kebutuhan perangkat lunak adalah pondasi utama dalam pengembangan sistem. Tanpa analisis kebutuhan yang baik, sistem bisa salah sasaran. Oleh karena itu, penting untuk menggunakan teknik dan proses analisa yang tepat, serta membuat rancangan yang matang sebelum implementasi dimulai.

Memahami Siklus Hidup Pengembangan Perangkat Lunak (SDLC)

 

1. Model Waterfall

Pengertian: Model Waterfall adalah model pengembangan perangkat lunak secara berurutan (linear), seperti air terjun, dari tahap awal sampai akhir.

Tahapan:

• Analisis Kebutuhan

• Desain Sistem

• Implementasi (Coding)

• Pengujian (Testing)

• Pemeliharaan (Maintenance)

Kelebihan:

• Mudah dipahami dan digunakan.

• Struktur proses jelas dan terurut.

• Cocok untuk proyek dengan kebutuhan tetap.

Kekurangan:

• Tidak fleksibel jika terjadi perubahan kebutuhan.

• Tidak bisa kembali ke tahap sebelumnya.

• Kurang cocok untuk proyek kompleks dan jangka panjang.

2. Model Iteratif dan Spiral

A. Model Iteratif

Pengertian: Model ini mengembangkan sistem dalam bentuk versi sederhana (iterasi awal), lalu terus ditingkatkan melalui perulangan berdasarkan feedback.

Kelebihan:

• Lebih fleksibel terhadap perubahan.

• Feedback bisa diterapkan cepat.

• Risiko dapat diatasi lebih awal.

Kekurangan:

• Bisa menghabiskan waktu dan biaya.

• Membutuhkan perencanaan yang hati-hati.

B. Model Spiral

Pengertian: Model spiral menggabungkan pendekatan waterfall dan iteratif dengan fokus pada analisis risiko pada setiap siklusnya.

Tahapan:

1. Perencanaan

2. Analisis Risiko

3. Engineering (Desain dan Implementasi)

4. Evaluasi

Kelebihan:

• Risiko bisa diidentifikasi lebih awal.

• Cocok untuk proyek besar dan kompleks.

• Fleksibel dalam perubahan.

Kekurangan:

• Kompleks dan mahal.

• Butuh pengalaman dan keahlian risiko.

3. Metodologi Agile

Pengertian: Metode pengembangan perangkat lunak secara iteratif dan inkremental yang menekankan kolaborasi tim, feedback cepat, dan fleksibilitas terhadap perubahan.

A. Scrum

• Dibagi dalam sprint (2-4 minggu).

• Peran: Product Owner, Scrum Master, Development Team.

• Menggunakan backlog dan burndown chart.

B. Kanban

• Visualisasi kerja dengan papan.

• Fokus pada aliran kerja yang efisien.

• Tidak ada iterasi tetap.

C. Extreme Programming (XP)

• Fokus pada kualitas kode.

• Praktik: pair programming, test-driven development, continuous integration.

Kelebihan Agile:

• Adaptif terhadap perubahan.

• Rilis cepat dan berkelanjutan.

• Komunikasi tim intensif.

Kekurangan Agile:

• Butuh keterlibatan tinggi dari pengguna.

• Tidak cocok untuk proyek dengan dokumentasi kaku.

4. Perbandingan Model SDLC

Dalam pengembangan perangkat lunak, berbagai model SDLC digunakan sesuai kebutuhan. Waterfall bersifat linear dan cocok untuk proyek dengan kebutuhan tetap, namun sulit beradaptasi terhadap perubahan. Model Iteratif dan Spiral lebih fleksibel, memungkinkan pengembangan bertahap dan analisis risiko, cocok untuk proyek besar dan kompleks. Agile seperti Scrum dan Kanban lebih adaptif, berfokus pada kolaborasi tim dan iterasi cepat, cocok untuk proyek yang sering berubah. Pemilihan model tergantung pada kompleksitas, perubahan kebutuhan, dan sumber daya proyek.

Aspek	Waterfall	Iteratif	Spiral	Agile
Pendekatan	Linear	Inkremental	Iteratif + Risiko	Iteratif/Inkremental
Fleksibilitas	Rendah	Sedang	Tinggi	Sangat tinggi
Cocok untuk	Kebutuhan jelas	Proyek menengah	Proyek besar	Proyek berubah-ubah
Dokumentasi	Lengkap	Sedang	Lengkap	Minimal
Keterlibatan Klien	Awal saja	Periodik	Berkelanjutan	Konsisten