BAB III skripsi Teknik Informatika dan Sistem Informasi bukan bab metode penelitian pada umumnya, melainkan bab yang menjelaskan bagaimana sistem dibangun dan bagaimana Anda membuktikan sistem itu berjalan. Isinya, dalam urutan yang hampir selalu diminta penguji: jenis dan alur penelitian, metode pengembangan perangkat lunak beserta alasannya, teknik pengumpulan dan analisis kebutuhan, perancangan dengan UML atau DFD, spesifikasi implementasi, rencana pengujian, serta jadwal dan alat. Panduan ini menuntun Anda menulis kedelapan bagian itu langkah demi langkah, lengkap dengan contoh kalimat yang bisa langsung diadaptasi.
Satu peringatan: pedoman tiap program studi berbeda. Sebagian prodi memberi judul BAB III “Metodologi Penelitian”, sebagian lain “Analisis dan Perancangan Sistem” dan memindahkan pengujian ke BAB IV. Cocokkan urutan di bawah ini dengan buku pedoman fakultas Anda.
Langkah 1: Tetapkan jenis penelitian dan gambarkan alurnya dalam satu diagram
Kalimat pertama BAB III harus menjawab pertanyaan yang pasti muncul di sidang: “Ini penelitian apa?” Untuk skripsi rancang bangun, jawabannya adalah penelitian terapan (applied research) dengan pendekatan rekayasa perangkat lunak, atau, bila pedoman prodi Anda memakai istilah itu, research and development pada produk perangkat lunak. Skripsi yang mengukur sesuatu (misalnya membandingkan akurasi dua algoritme klasifikasi) termasuk penelitian eksperimen dan memerlukan struktur berbeda; artikel cara membaca rumusan masalah untuk menentukan metode membantu Anda memastikan jenis mana yang sedang Anda kerjakan.
Setelah jenis penelitian ditetapkan, buat diagram alur penelitian: satu bagan vertikal dari identifikasi masalah, studi literatur, pengumpulan data, analisis kebutuhan, perancangan, implementasi, pengujian, sampai penarikan kesimpulan. Diagram ini berbeda dari diagram tahapan metode pengembangan; alur penelitian memuat seluruh skripsi, sedangkan metode pengembangan hanya memuat bagian pembuatan sistem.
Contoh kalimat: “Penelitian ini merupakan penelitian terapan yang menghasilkan produk perangkat lunak berupa sistem informasi inventaris berbasis web. Alur penelitian terdiri atas tujuh tahap sebagaimana ditunjukkan pada Gambar 3.1, dimulai dari identifikasi masalah di Koperasi X hingga penarikan kesimpulan.”
Langkah 2: Pilih metode pengembangan perangkat lunak dan tulis alasannya, bukan sekadar definisinya
Bagian ini adalah yang paling sering disalin dari skripsi lain, dan justru karena itu penguji mengujinya. Definisi Waterfall dari buku teks tidak bernilai apa-apa bila Anda tidak bisa menjelaskan mengapa metode itu dipilih untuk sistem Anda. Empat metode yang lazim di skripsi Indonesia, beserta situasi yang cocok untuk masing-masing:
| Metode | Tahapan (menurut sumber aslinya) | Cocok bila | Risiko di sidang |
|---|---|---|---|
| Waterfall | Communication, planning, modeling, construction, deployment (Pressman & Maxim, Software Engineering: A Practitioner’s Approach, edisi ke-9, 2019); atau requirements definition, system and software design, implementation and unit testing, integration and system testing, operation and maintenance (Sommerville, edisi ke-10, 2015) | Kebutuhan sudah jelas dan stabil sejak awal, pengguna satu instansi, waktu pengerjaan terjadwal | Ditanya “kalau kebutuhan berubah di tengah, bagaimana?” Jawaban harus siap |
| Prototyping | Komunikasi, perancangan cepat, pembuatan prototipe, evaluasi oleh pengguna, perbaikan, berulang sampai disepakati | Pengguna belum bisa merumuskan kebutuhan; antarmuka menjadi inti sistem | Harus melampirkan bukti evaluasi tiap iterasi (notulen, tangkapan layar versi) |
| RAD (Rapid Application Development) | Requirements planning, user design, construction, cutover (James Martin, 1991) | Sistem berukuran kecil sampai menengah, pengembang satu orang, waktu 60–90 hari | Tahap user design menuntut keterlibatan pengguna yang terdokumentasi |
| Scrum | Product backlog, sprint planning, sprint 1–4 minggu, daily scrum, sprint review, sprint retrospective (The Scrum Guide, Schwaber & Sutherland, versi 2020) | Kebutuhan berkembang, ada pemilik produk yang aktif | Scrum untuk pengembang tunggal sering dianggap tidak sahih; jelaskan peran yang Anda rangkap |
Setelah memilih, tulis tiga hal: nama metode dan sumber rujukannya, tahapan yang benar-benar Anda jalankan (bukan semua tahapan di buku), dan keluaran setiap tahap dalam skripsi Anda. Keluaran inilah yang membuat bagian ini bisa diperiksa: tahap analisis menghasilkan tabel kebutuhan, tahap desain menghasilkan diagram, tahap implementasi menghasilkan kode dan antarmuka, tahap pengujian menghasilkan tabel hasil uji.
Contoh kalimat: “Metode pengembangan yang digunakan adalah Waterfall sebagaimana dijelaskan Pressman dan Maxim (2019), karena kebutuhan sistem telah ditetapkan secara tertulis oleh pihak koperasi sebelum penelitian dimulai dan tidak diperkirakan berubah selama masa pengembangan. Tahap deployment dibatasi pada pemasangan di server lokal koperasi tanpa tahap pemeliharaan.”
Langkah 3: Tulis analisis kebutuhan sebagai data yang dapat ditelusuri
Kebutuhan sistem adalah data penelitian Anda, jadi sebutkan dari mana kebutuhan diperoleh: wawancara dengan siapa dan kapan, observasi proses apa, dokumen apa yang ditelaah.
Untuk sistem informasi, kerangka analisis yang paling sering diterima adalah PIECES (Whitten dan Bentley, Systems Analysis and Design Methods): masalah sistem berjalan dipetakan ke enam kategori, yaitu Performance, Information, Economics, Control, Efficiency, dan Service. Tabel PIECES yang terisi dengan temuan nyata jauh lebih meyakinkan daripada paragraf panjang tentang “sistem masih manual”.
Kemudian pisahkan kebutuhan fungsional (apa yang dilakukan sistem) dan kebutuhan nonfungsional (seberapa baik sistem melakukannya: waktu respons, keamanan, kompatibilitas peramban). Beri kode setiap butir agar bisa dirujuk pada tabel pengujian di Langkah 6.
| Kode | Kebutuhan fungsional | Sumber | Prioritas |
|---|---|---|---|
| KF-01 | Sistem menyimpan data barang masuk dengan nomor faktur, tanggal, pemasok, dan jumlah | Wawancara bendahara, 12 Maret 2026 | Wajib |
| KF-02 | Sistem menampilkan peringatan bila stok di bawah batas minimum | Observasi gudang | Wajib |
| KF-03 | Sistem mengekspor laporan bulanan ke format PDF | Dokumen laporan manual 2025 | Diinginkan |
Contoh kalimat: “Kebutuhan sistem dikumpulkan melalui wawancara semi-terstruktur dengan dua pegawai bagian gudang pada 10–12 Maret 2026, observasi proses pencatatan selama tiga hari kerja, dan telaah lima laporan stok bulanan tahun 2025. Hasil analisis dirangkum dalam tabel PIECES (Tabel 3.2) dan diturunkan menjadi 14 kebutuhan fungsional serta 5 kebutuhan nonfungsional (Tabel 3.3 dan 3.4).”
Langkah 4: Rancang sistem dengan satu paradigma pemodelan, jangan mencampur
Kesalahan yang paling mudah ditangkap penguji Teknik Informatika adalah diagram yang saling bertentangan: DFD dan class diagram dipakai bersamaan, atau use case diagram memuat aktor yang tidak muncul di sequence diagram mana pun. Pilih satu paradigma:
- Berorientasi objek → gunakan UML (spesifikasi resmi Object Management Group, UML versi 2.5.1, 2017). Minimal empat diagram: use case, activity, sequence, dan class diagram. Tambahkan deployment diagram bila arsitektur melibatkan lebih dari satu server.
- Terstruktur → gunakan DFD berjenjang (diagram konteks, level 0, level 1) dan ERD untuk basis data, ditambah kamus data. Paradigma ini masih diterima di banyak prodi Sistem Informasi, tetapi pastikan pedoman prodi Anda tidak mewajibkan UML.
Setiap diagram harus dijelaskan dalam paragraf yang menyebutkan elemennya secara eksplisit: nama aktor, jumlah use case, kelas beserta atribut kuncinya. Diagram tanpa narasi dianggap tidak dianalisis. Untuk perancangan basis data, sertakan struktur tabel (nama kolom, tipe data, panjang, kunci) dalam tabel, bukan hanya gambar ERD.
Sertakan juga rancangan antarmuka (wireframe) halaman utama saja; halaman lengkap masuk lampiran. Kerangka teori yang Anda tulis di BAB II seharusnya sudah menyebut paradigma dan notasi yang dipakai; bila belum, lihat kembali contoh kerangka teori untuk teknik dan ilmu komputer agar BAB II dan BAB III saling mengunci.
Contoh kalimat: “Perancangan sistem menggunakan pendekatan berorientasi objek dengan notasi UML 2.5. Use case diagram (Gambar 3.4) memuat tiga aktor, yaitu Admin, Petugas Gudang, dan Manajer, dengan sebelas use case. Setiap use case dirinci dalam activity diagram dan sequence diagram, sedangkan struktur data direpresentasikan dalam class diagram yang terdiri atas tujuh kelas.”
Langkah 5: Tulis spesifikasi implementasi dengan versi yang tepat
Penguji yang membuka bagian ini ingin tahu apakah sistem Anda bisa direproduksi. Sebutkan bahasa pemrograman dan versinya, kerangka kerja, sistem manajemen basis data, pustaka utama, peramban yang didukung, dan lingkungan pengembangan serta penerapan. Versi penting: “PHP” tidak cukup, “PHP 8.3 dengan Laravel 11” cukup. Bila memakai layanan pihak ketiga (API peta, gerbang pembayaran), sebutkan batas paket gratisnya, karena penguji sering menanyakan keberlanjutan sistem.
Tambahkan alasan pemilihan per komponen, dikaitkan dengan kebutuhan nonfungsional: misalnya PostgreSQL dipilih karena KNF-02 mensyaratkan transaksi yang konsisten pada pencatatan stok bersamaan.
Contoh kalimat: “Sistem diimplementasikan menggunakan bahasa Python 3.12 dengan kerangka kerja Django 5.0, basis data PostgreSQL 16, dan antarmuka berbasis Bootstrap 5. Pengembangan dilakukan pada komputer dengan Windows 11, sedangkan penerapan dilakukan pada server Ubuntu 24.04 milik instansi. Pemilihan Django didasarkan pada kebutuhan KNF-03 mengenai autentikasi berlapis yang tersedia bawaan pada kerangka kerja tersebut.”
Langkah 6: Rancang pengujian sebelum menulis kode, dan sambungkan ke kode kebutuhan
Inilah bagian yang membedakan skripsi Teknik Informatika dari sekadar proyek pemrograman. Rencana pengujian ditulis di BAB III; hasilnya dilaporkan di BAB IV. Tiga lapis pengujian yang lazim diterima:
- Pengujian fungsional dengan black-box. Setiap kebutuhan fungsional (KF-01 dan seterusnya) diturunkan menjadi minimal satu skenario uji dengan masukan, hasil yang diharapkan, dan kolom hasil aktual yang diisi di BAB IV. Gunakan teknik equivalence partitioning dan boundary value analysis agar skenario tidak hanya “masukan benar”: uji juga masukan kosong, nilai negatif, dan panjang teks melebihi batas kolom.
- Pengujian struktural dengan white-box untuk modul inti, terutama pada skripsi Teknik Informatika yang menonjolkan algoritme. Teknik basis path testing menghitung kompleksitas siklomatik V(G) = E − N + 2 (McCabe, 1976) dan menuntut jumlah jalur uji sebanyak nilai itu. Cukup satu atau dua modul; jangan mengklaim seluruh sistem diuji white-box.
- Pengujian penerimaan pengguna (UAT) dan, bila diperlukan, pengujian kegunaan dengan System Usability Scale. SUS (Brooke, 1996) terdiri atas sepuluh pernyataan skala 1–5; skor dihitung dengan mengurangi 1 dari butir ganjil, mengurangkan butir genap dari 5, menjumlahkan, lalu mengalikan 2,5 sehingga rentangnya 0–100; skor 68 adalah rata-rata yang lazim dipakai sebagai pembanding. Bila Anda memakai SUS, jumlah responden dan cara memilihnya harus ditulis di BAB III, dengan mengikuti aturan yang sama seperti penentuan jumlah sampel skripsi kuantitatif.
Bila pedoman prodi meminta pengujian mutu perangkat lunak, rujuk model mutu ISO/IEC 25010:2023, yang memuat sembilan karakteristik: functional suitability, performance efficiency, compatibility, interaction capability, reliability, security, maintainability, flexibility, dan safety. Pilih dua atau tiga karakteristik yang relevan dan jelaskan cara mengukurnya; mengklaim menguji kesembilan karakteristik dalam satu skripsi S1 akan dipertanyakan.
| Kode uji | Kebutuhan | Skenario | Masukan | Hasil yang diharapkan |
|---|---|---|---|---|
| BB-01 | KF-01 | Simpan barang masuk dengan data lengkap | Faktur F-2026-031, 40 unit | Data tersimpan, stok bertambah 40 |
| BB-02 | KF-01 | Simpan barang masuk dengan jumlah negatif | −5 unit | Pesan kesalahan, data tidak tersimpan |
| BB-03 | KF-02 | Stok menyentuh batas minimum | Stok 10, batas 10 | Peringatan muncul di dasbor |
Contoh kalimat: “Pengujian dilakukan dalam tiga tahap: pengujian black-box terhadap 14 kebutuhan fungsional dengan 31 skenario uji (Tabel 3.8), pengujian white-box dengan teknik basis path pada modul perhitungan stok minimum, dan pengujian penerimaan pengguna oleh tiga pegawai koperasi menggunakan kuesioner System Usability Scale.”
Langkah 7: Bila skripsi Anda memuat algoritme atau model, tambahkan subbab evaluasi
Skripsi Teknik Informatika yang membangun sistem dengan komponen klasifikasi, rekomendasi, atau prediksi memerlukan satu subbab tambahan: rancangan evaluasi model. Sebutkan asal dan ukuran dataset, pembagian data latih dan uji (misalnya 80:20 atau validasi silang k-fold dengan k = 5 atau 10), praproses yang dilakukan, dan metrik evaluasi: akurasi, presisi, recall, F1-score, beserta confusion matrix untuk klasifikasi; MAE atau RMSE untuk regresi.
Contoh kalimat: “Model klasifikasi dievaluasi menggunakan validasi silang 10-fold pada 1.200 data ulasan berlabel. Kinerja diukur dengan akurasi, presisi, recall, dan F1-score; F1-score dijadikan metrik utama karena distribusi kelas tidak seimbang (72% positif, 28% negatif).”
Langkah 8: Tutup dengan alat bantu dan jadwal yang realistis
Bagian penutup BAB III memuat daftar perangkat lunak pendukung dan jadwal penelitian. Perangkat lunak pemodelan yang lazim dipakai dan tersedia gratis untuk mahasiswa antara lain draw.io (diagrams.net) dan StarUML untuk diagram; Visual Paradigm menyediakan edisi komunitas dengan tanda air. Jadwal ditampilkan sebagai tabel bulanan (bagan Gantt sederhana) yang sesuai dengan tahapan metode pengembangan di Langkah 2, sehingga penguji melihat konsistensi antara metode dan waktu.
Daftar periksa BAB III sebelum bimbingan
- Jenis penelitian disebutkan pada paragraf pertama, dan diagram alur penelitian berbeda dari diagram metode pengembangan.
- Metode pengembangan disertai sumber rujukan, tahapan yang benar-benar dijalankan, dan keluaran tiap tahap.
- Setiap kebutuhan fungsional memiliki kode, sumber, dan prioritas.
- Semua diagram memakai satu paradigma dan dijelaskan dalam narasi yang menyebut elemennya.
- Spesifikasi implementasi menyebut versi dan alasan pemilihan.
- Setiap skenario uji merujuk kode kebutuhan; kolom hasil aktual masih kosong.
- Jadwal sesuai dengan tahapan metode pengembangan.
Sebelum menghadap pembimbing, ada baiknya membaca bank pertanyaan penguji per bab; pertanyaan tentang BAB III skripsi TI hampir selalu berkisar pada alasan pemilihan metode dan kesesuaian diagram.
Menyusun BAB III lebih cepat tanpa kehilangan kendali atas sistem Anda
Bagian tersulit BAB III skripsi Teknik Informatika bukan diagramnya, melainkan narasi yang menghubungkan kebutuhan, rancangan, dan pengujian menjadi satu argumen. Tesify membantu Anda menyusun kerangka BAB III dari daftar kebutuhan fungsional yang Anda masukkan, menghasilkan draf paragraf penjelasan untuk setiap diagram, dan merapikan tabel skenario uji agar kodenya konsisten dengan tabel kebutuhan. Anda tetap merancang dan mengodekan sistemnya sendiri; Tesify mempercepat penulisannya. Mulai susun BAB III skripsi TI Anda di Tesify, gratis untuk bab pertama.
Untuk daftar pustaka, fitur daftar pustaka otomatis Tesify menyusun rujukan Pressman, Sommerville, atau spesifikasi OMG dalam format APA atau gaya selingkung prodi Anda hanya dari judul atau DOI, sehingga edisi dan tahun yang Anda kutip di BAB III tidak berbeda dengan yang tercantum di daftar pustaka. Bila proposal Anda masih di tahap seminar, struktur proposal skripsi yang lolos seminar menjelaskan bagian BAB III mana yang wajib sudah ada sebelum sempro.
Pertanyaan yang Sering Diajukan
Apakah skripsi Teknik Informatika wajib memakai metode Waterfall?
Tidak. Waterfall paling sering dipakai karena tahapannya mudah didokumentasikan, tetapi prototyping, RAD, dan Scrum sama-sama diterima selama alasan pemilihannya dijelaskan dan keluaran tiap tahap ditunjukkan. Yang tidak diterima adalah menyebut metode tanpa menjalankannya.
Berapa diagram UML minimal untuk skripsi Sistem Informasi?
Umumnya empat: use case diagram, activity diagram, sequence diagram, dan class diagram. Beberapa prodi menambahkan deployment diagram atau state machine diagram untuk sistem dengan status objek yang kompleks. Periksa pedoman prodi, karena sebagian masih menerima DFD dan ERD sebagai pengganti.
Bolehkah memakai DFD dan UML sekaligus?
Sebaiknya tidak. DFD berasal dari paradigma terstruktur, UML dari paradigma berorientasi objek; mencampurnya membuat rancangan sulit dipertanggungjawabkan. Kekecualian yang lazim adalah ERD untuk rancangan basis data relasional, yang sering tetap dipakai berdampingan dengan class diagram.
Apakah pengujian ditulis di BAB III atau BAB IV?
Rencana pengujian (jenis, teknik, skenario, kriteria lulus) ditulis di BAB III. Hasil pengujian (kolom hasil aktual, persentase skenario yang lulus, skor SUS) ditulis di BAB IV. Sebagian prodi menggabungkan keduanya di BAB IV; ikuti pedoman prodi.
Berapa responden yang dibutuhkan untuk pengujian SUS?
Tidak ada angka wajib. SUS dirancang untuk sampel kecil dan sering dipakai dengan 5–20 responden; yang penting adalah responden benar-benar calon pengguna sistem, bukan teman sekelas. Tulis jumlah dan kriteria pemilihannya di BAB III.
Apa bedanya black-box dan white-box testing dalam skripsi?
Black-box menguji fungsi sistem dari sisi pengguna tanpa melihat kode, sehingga skenarionya diturunkan dari kebutuhan fungsional. White-box menguji struktur kode, misalnya dengan menghitung kompleksitas siklomatik dan menguji setiap jalur independen. Skripsi Sistem Informasi biasanya cukup black-box; skripsi Teknik Informatika yang menonjolkan algoritme sebaiknya menambahkan white-box pada modul inti.
Apakah harus memakai ISO/IEC 25010?
Tidak wajib. ISO/IEC 25010:2023 berguna bila prodi meminta pengujian mutu perangkat lunak yang berstandar; pilih dua atau tiga karakteristik yang relevan dengan sistem Anda dan jelaskan alat ukurnya. Menguji kesembilan karakteristik dalam skripsi S1 tidak realistis.
Bagaimana bila kebutuhan pengguna berubah setelah BAB III disetujui?
Catat perubahan itu sebagai revisi kebutuhan dengan tanggal dan alasannya, lalu perbarui tabel kebutuhan dan skenario uji yang terdampak. Perubahan yang terdokumentasi justru memperkuat argumen bahwa Anda menjalankan metode secara nyata, bukan menempelkannya.