Skripsi Mini Series Part 7: Conclusion and Recommendations (Kesimpulan dan Saran)

1. What Is Chapter 7: Conclusion and Recommendations (BAB VII: Kesimpulan dan Saran)?

Chapter 7 is the shortest chapter in the thesis (skripsi), and it’s often the one students rush through. That’s a mistake: it is the last thing many readers, and every examiner (penguji) opening your document for the first time, will read closely. It has two subsections:

If you’ve followed this series’ traceability chain, Research Questions and Objectives (Tujuan) in Chapter 1: Introduction (BAB I), then Chapter 6: Results and Discussion (BAB VI: Hasil dan Pembahasan), writing the Conclusion is almost mechanical: restate each answered question as a finding.

1. Apa Itu BAB VII: Kesimpulan dan Saran?

BAB VII adalah bab terpendek dalam skripsi, dan sering ditulis terburu-buru, padahal ini adalah kesalahan, karena ini adalah hal terakhir yang dibaca dengan saksama oleh banyak pembaca (dan setiap penguji yang membuka dokumen Anda untuk pertama kali). Bab ini memiliki dua subbab:

Jika Anda mengikuti rantai traceability seri ini (Rumusan Masalah di BAB I, Tujuan di BAB I, Hasil dan Pembahasan di BAB VI), menulis Kesimpulan hampir mekanis: nyatakan ulang setiap pertanyaan terjawab sebagai temuan.

2. Why Getting the Conclusion and Recommendations Right Matters

What is it?

The Conclusion is the closing argument for the case you’ve been building since Chapter 1; the Recommendations section is your honest acknowledgement of what remains open.

Why does it matter?

• It’s the last checkpoint of your traceability chain. If a Conclusion point doesn’t map to a Research Question, either your project drifted, or you’re claiming something you never actually established.
• Examiners often read Chapter 1 and Chapter 7 back-to-back before anything else. A mismatch between the two is the fastest way to trigger hard questions at your thesis defense (sidang).
• The Recommendations section isn’t an apology. A well-written one signals scientific maturity: you know the boundary of what you proved, and you can point precisely at what comes next.
• This chapter is your dress rehearsal for the defense. The questions an examiner asks almost always boil down to “does your Conclusion really follow from your Results?” and “what would you do differently?” Writing this chapter carefully answers both in advance.

When do you use it?

Write it last, after Chapter 6 is finished and stable. Never draft the Conclusion speculatively, before you have actual results.

Where does it fit?

Chapter 7 is the final artefact examiners weigh your entire project against. Practically speaking, it also doubles as the outline for your defense presentation slides.

How do you create one?

1. List each Research Question and write one Conclusion sentence per item, each backed by a specific Chapter 6 result.
2. Write the Recommendations as concrete, actionable next steps, not vague wishes.
3. Rehearse your thesis defense using the Conclusion points as your talking points.
4. Package the project for handover: a real deliverable, not just a chapter.

2. Mengapa Menulis Kesimpulan dan Saran dengan Benar Itu Penting?

Apa itu?

Kesimpulan adalah argumen penutup dari kasus yang telah Anda bangun sejak BAB I; Saran adalah pengakuan jujur Anda tentang apa yang masih terbuka.

Mengapa penting?

• Ini adalah checkpoint terakhir rantai traceability Anda. Jika sebuah poin Kesimpulan tidak terpetakan ke item Rumusan Masalah, entah proyek Anda menyimpang, atau Anda mengklaim sesuatu yang sebenarnya belum Anda tetapkan.
• Penguji sering membaca BAB I dan BAB VII berurutan sebelum membaca yang lain. Ketidakcocokan antara keduanya adalah cara tercepat memicu pertanyaan sulit di sidang Anda.
• Saran bukan permintaan maaf. Bagian Saran yang ditulis dengan baik menandakan kematangan ilmiah: Anda tahu batas apa yang Anda buktikan, dan bisa menunjuk secara presisi apa langkah berikutnya.
• Bab ini adalah gladi resik sidang Anda. Pertanyaan yang diajukan penguji, sebagian besar, adalah “apakah Kesimpulan Anda benar-benar konsisten dengan Hasil Anda?” dan “apa yang akan Anda lakukan berbeda?” Keduanya terjawab dengan menulis bab ini secara cermat.

Kapan digunakan?

Tulis terakhir, setelah BAB VI selesai dan stabil. Jangan pernah menyusun Kesimpulan secara spekulatif sebelum Anda punya hasil sesungguhnya.

Di mana tempatnya?

BAB VII adalah artefak akhir yang menjadi ukuran penguji terhadap seluruh proyek Anda; secara praktis, ini juga menjadi kerangka slide presentasi sidang Anda.

Bagaimana membuatnya?

1. Daftar setiap item Rumusan Masalah dan tulis satu kalimat Kesimpulan per item, masing-masing didukung oleh angka BAB VI yang spesifik.
2. Tulis Saran sebagai langkah konkret dan dapat ditindaklanjuti, bukan harapan yang kabur.
3. Latih pembelaan sidang Anda menggunakan Kesimpulan sebagai poin pembicaraan.
4. Kemas proyek untuk handover: deliverable nyata, bukan hanya bab.

3. Worked Example: Conclusion and Recommendations for Our Project

7.1 Conclusion

1. Applying the Action Pattern in the Laravel-based Todo List application improved maintainability: an average cyclomatic complexity of 2.4, average coupling of 1.8, and average lines of code per method of 9, all meeting the thresholds set from the literature (Chapter 6, Section 4).
2. Applying the Action Pattern made unit tests easier to isolate: unit test coverage reached 94%, exceeding the 80% target, because each Action class could be tested without HTTP bootstrapping (Chapter 6, Section 5).

Notice that each point cites a specific location in Chapter 6 and matches a Research Question exactly, in the same order. That is not optional decoration; it is what makes the Conclusion verifiable.

7.2 Recommendations

1. For future development: apply the Action Pattern to features with more complex business logic (e.g., involving multiple models or external APIs) to test whether the maintainability gains hold at a larger scale.
2. For future research: run a direct comparative study by implementing the Fat Controller variant discussed conceptually in Chapter 4: System Analysis and Design (BAB IV), to validate the contrast observed qualitatively here, and consider additional metrics such as the Maintainability Index or the time independent developers take to complete a maintenance task.
3. For anyone using these results: apply the Action Pattern selectively, only to features that genuinely have nontrivial business logic. For very simple CRUD operations, the overhead of an extra class may not be worth the benefit, a trade-off that falls outside this study’s Scope and Limitations (Batasan Masalah) but is still worth a developer’s consideration.

Each Recommendation item is actionable: a future reader knows exactly what to do next, not just that “more research is needed.” Recommendation 2 is also where the comparative study we deliberately scoped out (Part 1’s Scope and Limitations) becomes honest, concrete future work rather than a silently dropped ambition.

3. Contoh Terapan: Kesimpulan dan Saran untuk Proyek Ini

7.1 Kesimpulan

1. Penerapan Action Pattern pada aplikasi Todo List berbasis Laravel meningkatkan maintainability: cyclomatic complexity rata-rata 2,4, coupling rata-rata 1,8, dan lines of code per method rata-rata 9, seluruhnya memenuhi ambang batas yang ditetapkan (BAB VI bagian 4).
2. Penerapan Action Pattern memudahkan pengujian unit secara terisolasi: unit test coverage mencapai 94%, melampaui target 80%, karena setiap kelas Action dapat diuji tanpa bootstrap HTTP (BAB VI bagian 5).

Perhatikan bahwa setiap poin mengutip lokasi BAB VI yang spesifik dan cocok dengan item Rumusan Masalah secara persis, dengan urutan yang sama. Ini bukan hiasan opsional; ini yang membuat Kesimpulan dapat diverifikasi.

7.2 Saran

1. Bagi pengembangan selanjutnya: terapkan Action Pattern pada fitur dengan business logic yang lebih kompleks (mis. melibatkan beberapa model atau API eksternal) untuk menguji apakah keunggulan maintainability bertahan pada skala yang lebih besar.
2. Bagi penelitian selanjutnya: lakukan studi komparatif langsung dengan mengimplementasikan varian Fat Controller yang dibahas secara konseptual di BAB IV, untuk memvalidasi kontras yang diamati secara kualitatif, dan pertimbangkan metrik tambahan seperti Maintainability Index atau waktu penyelesaian tugas maintenance oleh developer independen.
3. Bagi pengguna hasil penelitian ini: gunakan Action Pattern secara selektif pada fitur yang benar-benar memiliki business logic nontrivial; untuk operasi CRUD yang sangat sederhana, overhead kelas tambahan mungkin tidak sepadan dengan manfaatnya, sebuah trade-off yang berada di luar Batasan Masalah studi ini namun layak dipertimbangkan oleh developer.

Setiap item Saran dapat ditindaklanjuti: pembaca masa depan tahu persis apa yang harus dilakukan selanjutnya, bukan hanya bahwa “penelitian lebih lanjut diperlukan.” Saran poin 2 juga menjadi tempat studi komparatif yang sengaja dikeluarkan dari ruang lingkup (Batasan Masalah Bagian 1) menjadi pekerjaan mendatang yang jujur dan konkret, bukan ambisi yang diam-diam ditinggalkan.

4. Thesis Defense Prep: Common Examiner Questions

Rehearse answers to these; they are near-universal for a measurement-based thesis like ours.

Presentation tip: structure your defense slides around the same skeleton as this series: Research Questions, Methodology, Design, Implementation, Results, Conclusion. An examiner who has read your Chapter 1 will recognise the structure instantly, and that recognition builds confidence in your work rather than confusion.

4. Persiapan Sidang: Pertanyaan Penguji yang Umum

Latih jawaban untuk pertanyaan-pertanyaan ini, yang hampir universal untuk skripsi berbasis pengukuran seperti penelitian ini.

Tips presentasi: susun slide pembelaan Anda mengikuti kerangka yang sama seperti seri ini: Rumusan Masalah, Metodologi, Desain, Implementasi, Hasil, Kesimpulan. Penguji yang sudah membaca BAB I Anda langsung mengenali strukturnya, yang membangun kepercayaan pada pekerjaan Anda alih-alih kebingungan.

5. Packaging and Handover: the SE Angle

A thesis is a document, but a mini thesis with a working system is also a software deliverable. Package it the way you would hand off a real project:

• README: setup instructions, how to run the application, how to run the tests, and how to reproduce the metric measurements.
• .env.example: never commit real credentials; document the required environment variables instead.
• A tagged release: so examiners (or future you) can check out the exact version that was measured. This isn’t hypothetical: it’s exactly what the v0.3-final tag in Part 5’s Prototype Iteration Log points to, the same version Chapter 6 measured.
• Migration and seed data: anyone should be able to git clone the repository, run the migrations, and see a working app within minutes.

This isn’t extra work for its own sake: a project an examiner can actually run is more convincing than one they can only read about.

6. Closing the “Finish On Time” Thread (Benang Merah)

Back in Part 1, we said Scope and Limitations is your best defence against scope creep (requirements quietly expanding past what was agreed), and Part 3 gave you a 16-week timeline that already accounted for the schedule slack a single-build design frees up. At this point in the semester, it’s worth a short retrospective: did each chapter land in its planned week? If not, where did the drift start? Usually it’s either an underspecified Research Question (Part 1) or a design phase that ran long because Scope and Limitations wasn’t tight enough (Part 4). Write this reflection down: it’s the single most useful thing you can hand to a junior student starting their own thesis next semester.

The Prototype Iteration Log (Part 5, Section 5.4) is worth revisiting here too: v0.1-prototype to v0.3-final is evidence that Prototyping’s evaluate-and-refine loop kept the single-build design on schedule, since each iteration fixed a specific gap instead of triggering a restart. If your own log shows a restart rather than a refinement, that is the drift worth writing down.

5. Pengemasan dan Handover: Sudut Pandang SE

Skripsi adalah dokumen, tetapi mini-skripsi dengan sistem yang berfungsi juga merupakan perangkat lunak yang dapat diserahkan (software deliverable). Kemas seperti Anda menyerahkan proyek nyata:

• README: instruksi setup, cara menjalankan aplikasi, cara menjalankan test, cara mereproduksi pengukuran metrik.
• .env.example: jangan pernah commit kredensial nyata; dokumentasikan variabel environment yang dibutuhkan.
• Release bertag: agar penguji (atau diri Anda di masa depan) dapat checkout versi persis yang diukur secara langsung. Ini bukan hipotetis: inilah persis yang ditunjuk tag v0.3-final di Log Iterasi Prototipe Bagian 5, versi yang sama yang diukur BAB VI.
• Migration dan seed data: siapa pun seharusnya bisa git clone, menjalankan migration, dan melihat aplikasi berfungsi dalam hitungan menit.

Ini bukan pekerjaan ekstra tanpa tujuan. Proyek yang benar-benar bisa dijalankan penguji lebih meyakinkan daripada yang hanya mereka baca.

6. Menuntaskan Benang Merah “Selesai Tepat Waktu”

Bagian 1 telah menyatakan bahwa Batasan Masalah adalah pertahanan terbaik Anda melawan scope creep (fitur yang terus bertambah diam-diam di luar rencana awal), dan Bagian 3 memberi Anda linimasa 16 minggu yang sudah memperhitungkan waktu cadangan yang dihemat oleh desain satu-implementasi. Pada titik ini di semester, layak melakukan retrospektif singkat: apakah setiap BAB mendarat di minggu yang direncanakan? Jika tidak, di mana penyimpangan dimulai? Biasanya entah Rumusan Masalah yang kurang spesifik (Bagian 1) atau fase desain yang berlarut karena Batasan Masalah kurang ketat (Bagian 4). Tuliskan refleksi ini; ini adalah hal paling berguna yang bisa Anda serahkan kepada mahasiswa junior yang memulai skripsi mereka sendiri semester depan.

Log Iterasi Prototipe (Bagian 5, bagian 5.4) layak ditinjau ulang di sini juga: v0.1-prototype hingga v0.3-final adalah bukti bahwa loop evaluasi-dan-penyempurnaan Prototyping menjaga desain satu-implementasi tetap sesuai jadwal, karena setiap iterasi memperbaiki kesenjangan yang spesifik, bukan memicu mulai ulang. Jika log Anda sendiri menunjukkan mulai ulang alih-alih penyempurnaan, itulah penyimpangan yang layak dituliskan.

7. Common Mistakes in Chapter 7

7. Kesalahan Umum dalam BAB VII

8. Series Complete: Applying This to Your Own Thesis

Across seven parts, we carried one deliberately simple example, a Todo app evaluating the Laravel Action Pattern against literature thresholds, through all seven chapters of a Polinema thesis. At each step, we showed how the academic structure (Background (Latar Belakang), Research Questions, and so on through the Conclusion) reinforces software-engineering discipline (requirements, UML design, version control, testing, measurement), and how a single-build, threshold-validation design keeps that discipline achievable for a beginner in one semester.

What carries over directly is the skeleton, not the content. Swap the Todo app for your own small system, swap the Action Pattern for whatever you want to evaluate (a different design pattern, an architecture style, a tool, a library), and keep the traceability chain from Research Questions to Conclusion, the single-build design, and the discipline of designing before building and measuring before concluding. What doesn’t carry over automatically is the evidence itself: your own Literature Study (Studi Literatur) to justify a defensible threshold for your new subject, metrics chosen because they actually measure it (cyclomatic complexity fits a code-structure pattern, but not necessarily a caching strategy or a UI choice), and a Scope and Limitations section re-argued for your specific case rather than copied from this one. That discipline of redoing the groundwork, more than any specific chapter template, is what finishes a thesis on time.

8. Seri Selesai: Menerapkan Ini pada Skripsi Anda Sendiri

Sepanjang tujuh bagian, satu contoh yang sengaja dibuat sederhana, aplikasi Todo yang mengevaluasi Action Pattern Laravel terhadap ambang batas literatur, dibawa melalui ketujuh BAB skripsi Polinema, menunjukkan pada setiap langkah bagaimana struktur akademik (Latar Belakang, Rumusan Masalah, dan seterusnya hingga Kesimpulan) dan disiplin rekayasa perangkat lunak (requirements, desain UML, version control, pengujian, pengukuran) saling menguatkan, dan bagaimana desain satu-implementasi berbasis validasi-ambang-batas menjaga disiplin itu tetap dapat dicapai pemula dalam satu semester.

Yang bisa langsung dipakai ulang adalah kerangkanya, bukan isinya: ganti aplikasi Todo dengan sistem kecil Anda sendiri, ganti Action Pattern dengan apa pun yang ingin Anda evaluasi (design pattern lain, gaya arsitektur, tool, library), dan pertahankan rantai traceability dari Rumusan Masalah ke Kesimpulan, desain satu-implementasi, serta disiplin merancang sebelum membangun dan mengukur sebelum menyimpulkan. Yang tidak otomatis ikut berpindah adalah buktinya sendiri: Studi Literatur Anda sendiri untuk menjustifikasi ambang batas yang dapat dipertanggungjawabkan bagi subjek baru Anda, metrik yang dipilih karena benar-benar mengukurnya (cyclomatic complexity cocok untuk pattern struktur kode, belum tentu cocok untuk strategi caching atau pilihan UI), dan Batasan Masalah yang dijustifikasi ulang untuk kasus spesifik Anda, bukan disalin dari studi ini. Disiplin menyusun ulang landasan itulah, lebih dari template bab spesifik apa pun, yang membuat skripsi selesai tepat waktu.