Proposal skripsi Teknik Informatika dan Sistem Informasi yang ditolak dalam seminar hampir selalu punya satu ciri yang sama: rumusan masalah, kerangka sistem, dan metode pengembangan tidak saling mengunci. Panduan ini menyusun proposal TI/SI bagian demi bagian — dari rumusan masalah sampai jadwal penelitian — lalu ditutup satu naskah proposal utuh untuk judul ilustratif yang bisa dijadikan kerangka. Semua judul, angka, dan hasil di halaman ini bersifat ilustratif untuk mencontohkan pola penulisan, bukan naskah yang boleh disalin langsung. Untuk ide topik yang lebih luas di luar contoh ini, lihat 30 judul skripsi Teknik Informatika dan Sistem Informasi 2026, yang mencakup pembelajaran mesin, NLP bahasa Indonesia, visi komputer, sistem informasi, IoT, dan keamanan siber.
Bagian 1: Judul dan Latar Belakang Masalah
Judul proposal TI/SI idealnya memuat tiga unsur: masalah yang diangkat, teknologi/metode yang dipakai, dan objek penerapannya. Contoh judul ilustratif: “Sistem Klasifikasi Ulasan Produk Bahasa Indonesia Menggunakan IndoBERT untuk Analisis Sentimen pada Platform E-Commerce.” Ketiga unsur itu terlihat jelas: masalah (analisis sentimen ulasan), teknologi (IndoBERT), objek (platform e-commerce). Judul yang hanya menyebut teknologi tanpa objek penerapan — misalnya “Penerapan IndoBERT untuk Analisis Sentimen” saja — biasanya diminta dipersempit oleh pembimbing karena terlalu umum.
Latar belakang menjelaskan kesenjangan yang mendorong penelitian, disusun dari isu umum ke isu spesifik: paragraf pertama tentang pertumbuhan e-commerce dan pentingnya umpan balik pelanggan, paragraf kedua tentang keterbatasan alat analisis sentimen berbahasa Inggris untuk teks bahasa Indonesia yang mengandung kata tidak baku dan campuran bahasa daerah, paragraf ketiga menyempit ke celah spesifik yang akan diisi penelitian ini. Paragraf penutup latar belakang berisi pernyataan singkat tentang kontribusi yang ditawarkan — bukan mengulang rumusan masalah, tapi menyatakan nilai tambahnya secara ringkas.
Bagian 2: Rumusan Masalah dan Batasan Masalah
Rumusan masalah proposal TI biasanya berbentuk pertanyaan yang bisa dijawab dengan metrik terukur, bukan pertanyaan terbuka. Contoh ilustratif:
- Bagaimana merancang model klasifikasi sentimen berbasis IndoBERT untuk ulasan produk bahasa Indonesia?
- Seberapa akurat model yang dirancang dibandingkan model baseline (mis. Naive Bayes atau SVM) pada dataset ulasan yang sama?
Batasan masalah membatasi ruang lingkup secara eksplisit — misalnya jumlah kategori sentimen yang diklasifikasi (positif/negatif/netral), sumber data yang dipakai, dan platform yang menjadi objek uji — supaya cakupan proyek tidak melebar saat implementasi. Batasan yang lazim dilupakan pemula: menyebut versi model, ukuran dataset minimum, dan periode data yang dipakai, karena ketiganya sering ditanyakan penguji saat sidang proposal untuk menilai apakah cakupan penelitian realistis dikerjakan dalam satu semester.
Bagian 3: Tinjauan Pustaka dan Penelitian Terdahulu
Bagian ini merangkum penelitian sejenis dalam tabel perbandingan singkat, bukan uraian panjang per sumber. Contoh format tabel ilustratif:
| Penelitian | Metode | Dataset | Celah yang Ditutup Penelitian Ini |
|---|---|---|---|
| Studi A (ilustratif) | Naive Bayes | Ulasan marketplace umum | Akurasi rendah pada kata tidak baku |
| Studi B (ilustratif) | SVM + TF-IDF | Ulasan produk elektronik | Tidak menangani campuran bahasa daerah |
| Penelitian ini | Fine-tuning IndoBERT | Ulasan e-commerce lokal | Representasi konteks lebih baik untuk teks informal |
Tinjauan pustaka proposal cukup ringkas — satu sampai dua halaman — karena versi lengkapnya baru disusun penuh di Bab II skripsi setelah proposal disetujui. Fokusnya menunjukkan posisi penelitian relatif terhadap studi sejenis, bukan meringkas semua literatur yang ada tentang topik tersebut.
Bagian 4: Kerangka Sistem yang Diusulkan
Kerangka sistem menggambarkan alur data dari input sampai output secara ringkas, biasanya dengan diagram blok atau use case diagram tingkat tinggi — bukan diagram rinci seperti class diagram, yang baru dilengkapi setelah proposal disetujui dan masuk ke Bab III skripsi penuh. Untuk contoh ilustratif di atas, kerangka sistem memuat empat blok: pengumpulan data ulasan (scraping atau dataset publik), praproses teks (tokenisasi, normalisasi kata tidak baku), fine-tuning model IndoBERT, dan evaluasi hasil klasifikasi. Setiap blok idealnya disertai satu kalimat penjelas input dan output-nya, supaya penguji bisa menelusuri alur data tanpa membaca kode program.
Bagian 5: Metode Pengembangan
Metode pengembangan yang dipilih harus dijustifikasi, bukan sekadar disebut. Empat pilihan yang paling umum di proposal TI/SI:
| Metode | Paling cocok bila… |
|---|---|
| Waterfall | Kebutuhan sistem sudah jelas sejak awal dan tidak diperkirakan berubah |
| Prototyping | Sistem butuh validasi tampilan/antarmuka berulang dengan calon pengguna |
| RAD (Rapid Application Development) | Proyek berjangka pendek dengan modul yang bisa dipakai ulang |
| Scrum/Agile | Kebutuhan sistem masih mungkin berubah selama pengerjaan |
Penjelasan lengkap tujuh komponen Bab III beserta pengujian black-box, white-box, dan ISO/IEC 25010 ada di cara menulis Bab III skripsi Teknik Informatika dan Sistem Informasi — proposal ini hanya memuat versi ringkas metode yang dipilih beserta alasan pemilihannya; versi rincinya (tahapan detail, diagram lengkap) baru disusun di bab tersebut setelah proposal disetujui pembimbing.
Bagian 6: Sumber Dataset dan Rencana Pengujian
Untuk skripsi berbasis machine learning atau NLP, proposal sebaiknya sudah menyebut sumber dataset yang direncanakan — dataset publik di platform seperti Kaggle atau repositori GitHub akademik, atau data yang dikumpulkan sendiri lewat scraping. Bila memakai scraping, sebutkan juga batasan etisnya: hanya mengambil data yang publik dan tidak melanggar syarat layanan (terms of service) platform sumber, dan tidak menyertakan data pribadi yang bisa mengidentifikasi individu tanpa persetujuan. Ketersediaan dataset yang realistis di tahap proposal mencegah kemunduran jadwal besar-besaran saat masuk tahap implementasi.
Metrik evaluasi yang akan dipakai disebutkan beserta alasannya di bagian ini, tanpa hasil (karena penelitian belum dilakukan). Untuk sistem klasifikasi, metrik yang lazim disebut adalah akurasi, presisi, recall, dan F1-score, dibandingkan terhadap model baseline. Perbandingan menyeluruh antarmetrik evaluasi model ada di confusion matrix vs metrik lain untuk evaluasi model skripsi Teknik Informatika, dan pembahasan jumlah responden untuk pengujian usability sistem (bukan pengujian model) ada di populasi dan sampel untuk skripsi Teknik Informatika bila proyek Anda melibatkan uji pengguna, bukan hanya evaluasi model machine learning.
Bagian 7: Jadwal Penelitian
Jadwal penelitian dipecah per tahap dengan perkiraan durasi mingguan. Contoh ilustratif dalam tabel Gantt sederhana untuk proyek delapan minggu:
| Tahap | Minggu 1–2 | Minggu 3–4 | Minggu 5–6 | Minggu 7–8 |
|---|---|---|---|---|
| Pengumpulan & praproses data | ✓ | |||
| Fine-tuning model | ✓ | ✓ | ||
| Evaluasi & pengujian | ✓ | |||
| Penulisan laporan | ✓ |
Sisakan waktu cadangan minimal dua minggu sebelum tenggat sidang untuk revisi tak terduga dari pembimbing — jadwal yang terlalu ketat tanpa buffer adalah alasan paling sering keterlambatan sidang di proyek TI, karena fine-tuning model dan debugging sering memakan waktu lebih lama dari perkiraan awal.
Naskah Proposal Utuh (Ilustratif)
Menyatukan ketujuh bagian di atas, berikut kerangka naskah proposal yang bisa diadaptasi (judul dan angka bersifat ilustratif):
Judul: Sistem Klasifikasi Ulasan Produk Bahasa Indonesia Menggunakan IndoBERT untuk Analisis Sentimen pada Platform E-Commerce.
Latar Belakang: alat analisis sentimen berbasis bahasa Inggris kurang akurat untuk teks bahasa Indonesia yang mengandung kata tidak baku dan campuran bahasa daerah, sehingga platform e-commerce lokal masih kesulitan memantau sentimen ulasan pelanggan secara otomatis.
Rumusan Masalah: (1) bagaimana merancang model klasifikasi sentimen berbasis IndoBERT untuk ulasan bahasa Indonesia; (2) seberapa akurat model tersebut dibandingkan baseline Naive Bayes/SVM pada dataset yang sama.
Tujuan Penelitian: (1) merancang model klasifikasi sentimen berbasis IndoBERT untuk ulasan produk bahasa Indonesia; (2) mengukur dan membandingkan akurasi model tersebut terhadap baseline Naive Bayes/SVM.
Manfaat Penelitian: secara teoretis, menambah referensi penerapan model bahasa berbasis transformer untuk teks informal bahasa Indonesia; secara praktis, membantu pelaku usaha e-commerce lokal memantau sentimen pelanggan tanpa proses manual.
Metode Pengembangan: prototyping, karena antarmuka dashboard hasil klasifikasi perlu divalidasi berulang dengan calon pengguna (admin toko daring) sebelum versi final.
Rencana Pengujian: akurasi, presisi, recall, dan F1-score model IndoBERT dibandingkan model baseline pada data uji yang sama, ditambah uji usability dashboard dengan sejumlah kecil pengguna.
Kesalahan yang Sering Membuat Proposal TI Ditolak Penguji
- Rumusan masalah dan metrik evaluasi tidak sinkron — rumusan masalah menanyakan akurasi, tapi rencana pengujian hanya menyebut kecepatan pemrosesan, tanpa metrik akurasi sama sekali.
- Kerangka sistem tidak menjawab rumusan masalah — diagram blok yang ditampilkan justru menggambarkan sistem yang berbeda cakupannya dari yang disebut di rumusan masalah dan batasan masalah.
- Metode pengembangan disebut tanpa alasan — menulis “metode yang digunakan adalah Waterfall” tanpa menjelaskan mengapa Waterfall lebih cocok dibanding Scrum atau prototyping untuk proyek tersebut.
- Jadwal tidak realistis — alokasi waktu fine-tuning model hanya satu minggu padahal proses pelatihan dan tuning parameter pada dataset besar biasanya butuh beberapa kali iterasi.
- Baseline pembanding tidak disebut — model yang diusulkan diklaim “lebih baik” tanpa menyebut model baseline yang dipakai sebagai pembanding di rencana pengujian.
- Sumber dataset belum jelas saat seminar — mahasiswa menjawab “masih dicari” ketika ditanya dari mana data akan diperoleh, tanda cakupan penelitian belum benar-benar dipikirkan matang.
Checklist Sebelum Seminar Proposal
- Rumusan masalah bisa dijawab dengan metrik terukur, bukan pertanyaan terbuka.
- Kerangka sistem menunjukkan alur data dari input sampai output secara jelas dan konsisten dengan rumusan masalah.
- Metode pengembangan yang dipilih dijustifikasi, bukan sekadar disebut namanya.
- Metrik evaluasi yang direncanakan konsisten dengan jenis sistem (klasifikasi, prediksi, atau sistem interaktif) dan menyebut baseline pembanding.
- Sumber dataset sudah dipastikan tersedia dan batasan etisnya (scraping, data pribadi) sudah dipikirkan.
- Jadwal penelitian punya waktu cadangan sebelum tenggat sidang.
- Batasan masalah membatasi cakupan proyek secara eksplisit, bukan tersirat.
Panduan lintas jurusan tentang struktur proposal dan enam alasan paling sering ditolak dosen pembimbing ada di proposal skripsi ditolak terus? — kombinasikan dengan bagian TI-spesifik di atas. Menjaga rumusan masalah, kerangka sistem, dan metode pengembangan tetap saling mengunci lewat berulang kali revisi memang memakan waktu. Tesify membantu menyusun kerangka tiap bagian proposal dan menjaga konsistensi rumusan masalah sampai rencana pengujian, sementara Anda tetap menjadi penulis dan penanggung jawab penuh atas isi proposal.
Pertanyaan yang Sering Diajukan
Apa beda proposal skripsi dan skripsi itu sendiri?
Proposal adalah rencana penelitian yang diseminarkan sebelum penelitian dimulai, berisi Bab I sampai Bab III (pendahuluan, tinjauan pustaka, metode). Skripsi adalah laporan lengkap setelah penelitian selesai, menambahkan Bab IV hasil dan Bab V penutup di atas proposal yang sudah disetujui.
Berapa halaman ideal proposal skripsi Teknik Informatika?
Tidak ada standar nasional; kisaran umum yang diterima banyak program studi adalah 20 sampai 35 halaman untuk Bab I sampai III, di luar lampiran. Selalu cek buku pedoman skripsi fakultas Anda karena batas ini bisa berbeda antarkampus.
Metode pengembangan apa yang paling sering dipakai skripsi TI?
Waterfall paling umum untuk proyek dengan kebutuhan yang sudah jelas sejak awal, prototyping untuk sistem yang butuh validasi tampilan dengan pengguna, RAD untuk proyek berjangka pendek dengan modul siap pakai, dan Scrum atau agile untuk proyek dengan kebutuhan yang masih berubah. Pemilihannya harus dijustifikasi, bukan sekadar mengikuti tren.
Apakah proposal skripsi TI wajib memakai UML?
Tidak wajib di tahap proposal, tapi sangat membantu. Use case diagram di tahap proposal sudah cukup untuk menunjukkan cakupan sistem yang diusulkan; diagram yang lebih rinci seperti class diagram dan activity diagram biasanya baru dilengkapi di Bab III skripsi, bukan di proposal.
Bagaimana menyusun jadwal penelitian proposal skripsi TI yang realistis?
Pecah menjadi tahap analisis kebutuhan, perancangan, implementasi/coding, pengujian, dan penulisan laporan, masing-masing dengan perkiraan durasi mingguan dalam tabel Gantt sederhana. Sisakan waktu cadangan minimal dua minggu sebelum tenggat sidang untuk revisi tak terduga dari pembimbing.
Bolehkah topik proposal berubah setelah seminar proposal?
Perubahan kecil pada judul atau metode implementasi umumnya masih diperbolehkan dengan persetujuan pembimbing, tapi perubahan rumusan masalah secara mendasar biasanya mengharuskan seminar proposal ulang. Kebijakan ini berbeda antarfakultas, jadi konfirmasi langsung ke koordinator skripsi program studi.
Dari mana mahasiswa TI biasanya mendapat dataset gratis?
Sumber yang paling umum adalah Kaggle Datasets, repositori akademik seperti UCI Machine Learning Repository, dan portal data pemerintah seperti Satu Data Indonesia untuk data non-teks. Bila dataset dikumpulkan sendiri lewat scraping, pastikan tidak melanggar syarat layanan platform sumber dan tidak menyertakan data pribadi tanpa persetujuan.