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

MEMAHAMI KONSEP DAN DEFINISI PERANGKAT LUNAK SERTA REKAYASA PERANGKAT LUNAK

 A. Menjelaskan Definisi dan Ruang Lingkup RPL

Rekayasa Perangkat Lunak atau biasa disingkat dengan RPL adalah salah satu bidang profesi dan juga mata pelajaran yang mempelajari tentang pengembangan perangkat-perangkat lunak termasuk dalam hal pembuatannya, pemeliharaan hingga manajemen organisasi dan manajemen kualitasnya. Bisa dikatakan RPL ini merupakan sebuah perubahan yang terjadi pada perangkat lunak guna melakukan pengembangan, pemeliharaan, dan pembangunan kembali dengan menerapkan prinsip rekayasa sehingga memperoleh perangkat lunak yang bisa bekerja secara lebih efisien dan efektif pada user nantinya.

Rekayasa Perangkat Lunak (RPL) mencakup berbagai aspek dalam pengembangan perangkat lunak secara sistematis. Ruang lingkup utama RPL meliputi pengembangan perangkat lunak, yang mencakup perancangan, implementasi, dan pengujian menggunakan metodologi seperti Waterfall dan Agile. Selain itu, manajemen proyek perangkat lunak diperlukan untuk mengatur sumber daya, anggaran, dan jadwal pengembangan.

1. software Requirements berhubungan dengan spesifikasi kebutuhan dan persyaratan perangkat lunak

2. software desain mencakup proses penampilan arsitektur, komponen, antar muka, dan karakteristik lain dari perangkat lunak

3. software construction berhubungan dengan detail pengembangan perangkat lunak, termasuk algoritma, pengkodean, pengujian dan pencarian kesalahan

4. software testing meliputi pengujian pada keseluruhan perilaku perangkat lunak

5. software maintenance mencakup upaya-upaya perawatan ketika perangkat lunak telah dioperasikan

6. software configuration management berhubungan dengan usaha perubahan konfigurasi perangkat lunak untuk memenuhi kebutuhan tertentu

7. software engineering management berkaitan dengan pengelolaan dan pengukuran RPL, termasuk perencanaan proyek perangkat lunak

8. software engineering tools and methods mencakup kajian teoritis tentang alat bantu dan metode RPL

9. software engineering process berhubungan dengan definisi, implementasi pengukuran, pengelolaan, perubahan dan perbaikan proses RPL

10. software quality menitik beratkan pada kualitas dan daur hidup perangkat lunak

B.   Peran RPL Dalam Pengembangan Perangkat Lunak

Rekayasa Perangkat Lunak (RPL) memiliki peran krusial dalam memastikan perangkat lunak dikembangkan secara terstruktur, efisien, dan berkualitas tinggi. Salah satu peran utamanya adalah menyediakan metodologi yang sistematis dalam pengembangan perangkat lunak, mulai dari analisis kebutuhan, desain, implementasi, pengujian, hingga pemeliharaan. Dengan pendekatan ini, perangkat lunak dapat lebih mudah dikembangkan, diperbaiki, dan ditingkatkan sesuai kebutuhan pengguna.

Secara keseluruhan, peran RPL dalam pengembangan perangkat lunak adalah memastikan bahwa perangkat lunak dibangun dengan metode yang tepat, memiliki kualitas tinggi, aman, efisien, serta dapat dikelola dan dikembangkan dengan baik. Dengan penerapan RPL, perangkat lunak dapat memenuhi kebutuhan pengguna dan memberikan solusi yang efektif dalam berbagai bidang.

C. Perbedaan Antara Rekayasa Perangkat Lunak Dengan Pemrograman Biasa 

Perbedaan Antara Rekayasa Perangkat Lunak (RPL) dan Pemrograman Biasa Rekayasa Perangkat Lunak (RPL) dan pemrograman biasa sering dianggap serupa, tetapi sebenarnya memiliki perbedaan mendasar dalam pendekatan, cakupan, dan tujuan. RPL adalah pendekatan sistematis dalam pengembangan perangkat lunak, mencakup berbagai tahapan seperti analisis kebutuhan, desain, implementasi, pengujian, hingga pemeliharaan perangkat lunak. Sementara itu, pemrograman biasa lebih berfokus pada penulisan kode untuk menyelesaikan suatu tugas atau fungsi tertentu tanpa mempertimbangkan aspek manajemen proyek atau pemeliharaan jangka panjang.

Secara keseluruhan, RPL adalah pendekatan yang lebih luas dan terstruktur, mencakup seluruh siklus hidup perangkat lunak, sementara pemrograman biasa hanya berfokus pada penulisan kode tanpa strategi pengelolaan jangka panjang. Oleh karena itu, dalam proyek perangkat lunak yang lebih kompleks dan berkelanjutan, penggunaan RPL sangat diperlukan untuk memastikan kualitas dan keberlanjutan perangkat lunak.

D. Memberikan Contoh Keterkaitan RPL Dengan Ilmu Yang Lain

 

· bidang ilmu manajemen meliputi akuntansi, finansial, pemasaran, manajemen operasi, ekonomi, analisis kuantitatif, manajemen sumber daya manusia, kebijakan, dan strategi bisnis

·       bidang ilmu matematika meliputi aljabar linier, kalkulus, peluang, statistik, analisis numerik, dan matematika diskrit

·     bidang ilmu manajemen proyek meliputi semua hal yang berkaitan dengan proyek, seperti ruang lingkup proyek, anggaran, tenaga kerja, kualitas, manajemen resiko dan keandalan, perbaikan kualitas, dan metode-metode kuantitatif

·    bidang ilmu ergonomika menyangkut hubungan ( interaksi) antar manusia dengan komponen-komponen lain dalam sistem komputer

·  bidang ilmu rekayasa sistem meliputi teori sistem, analisis biaya-keuntungan, pemodelan, simulasi, proses, dan operasi bisnis

Keterkaitan Rekayasa Perangkat Lunak (RPL) dengan Ilmu Lain Rekayasa Perangkat Lunak (RPL) tidak berdiri sendiri, tetapi memiliki keterkaitan erat dengan berbagai disiplin ilmu lain. Keterkaitan ini membantu pengembangan perangkat lunak agar lebih efektif, efisien, dan sesuai dengan kebutuhan pengguna.

Salah satu ilmu yang sangat berhubungan dengan RPL adalah Ilmu Matematika. Dalam RPL, konsep matematika digunakan dalam algoritma, struktur data, analisis kompleksitas, serta enkripsi untuk keamanan perangkat lunak. Misalnya, dalam pengolahan data besar (Big Data), digunakan statistik dan probabilitas untuk menganalisis pola serta membuat prediksi berdasarkan data yang tersedia.

Selain itu, RPL juga berkaitan dengan Manajemen Proyek dan Bisnis. Dalam pengembangan perangkat lunak, aspek manajemen proyek sangat penting untuk mengatur sumber daya, biaya, dan waktu agar proyek berjalan sesuai target. Pemahaman tentang bisnis juga diperlukan dalam analisis kebutuhan pengguna dan pengembangan perangkat lunak yang sesuai dengan pasar. Contohnya, dalam pembuatan aplikasi e-commerce, diperlukan pemahaman tentang strategi pemasaran digital, transaksi online, serta perilaku konsumen.

E. Mendefinisikan Contoh-contoh Perangkat Lunak dan Kriteria Perangkat Lunak yang Baik

Contoh Perangkat Lunak dan Kriteria Perangkat Lunak yang Baik Perangkat lunak dapat dikategorikan berdasarkan fungsinya, seperti perangkat lunak sistem, perangkat lunak aplikasi, perangkat lunak berbasis web, dan perangkat lunak berbasis kecerdasan buatan (AI). Contoh perangkat lunak sistem adalah sistem operasi seperti Windows, macOS, Linux, Android, dan iOS, serta driver perangkat keras seperti NVIDIA Graphics Driver dan Realtek Audio Driver. Sementara itu, perangkat lunak aplikasi mencakup berbagai kategori seperti perkantoran (Microsoft Office, Google Docs), desain dan multimedia (Adobe Photoshop, CorelDRAW), pemrograman (Visual Studio Code, PyCharm), keuangan (QuickBooks, Wave Accounting), dan edukasi (Duolingo, Google Classroom).