PANDUAN PENULISAN BUKU TA

Berikut ada panduan penulisan buku TA
nyomot dari blognya dosenku :-)
mudah2an bermanfaat...

Panduan Menyusun / Revisi Buku TA

Pendahuluan
Latar belakang berisi hal yang melatar belakangi TA ini ditulis. Isinya adalah masalah, lalu diselesaikan seseorang (sebut nomor referensinya), diceritakan keberhasilannya dan masalah yang muncul. Kemudian masalah tsb lalu diselesaikan orang lain lagi, dst, hingga masalah yg terakhir yg harus diselesaikan (masalah TA ini). Ditutup dg kalimat ”oleh karena itu dalam TA ini……” atau ” TA ini membahas tentang….” dan sejenisnya.

Permasalahan: Topik permasalahan dapat berupa pertanyaan agar lebih mudah. Bila di TA tersebut ada 3 modul besar yang akan ditangani, maka selayaknya jumlah masalah adalah 3, dimana jawaban tiap permasalahan tersebut adalah tiap modul tersebut
Tujuan: Isinya persis dengan judul TA, namun dilengkapi hingga menjadi kalimat yang utuh.

Metodologi: Seringkali mhs satu dg yg lain menulis hal yang sama, misalnya dimulai dg pengumpulan data, hingga penyusunan buku TA. Padahal metodologi ini justru sangat penting, sebab menguraikan urut-urutan kegiatan, dimulai dari mempelajari sesuatu (sebut semua hal yg dipelajari), kemudian (misalnya) pengumpulan data yang didownload atau diukur dari tempat tertentu. Ini membutuhkan penjelasan detil, apa benda tsb, dari mana, bgm karakteristiknya, dsb. Untuk Disain perangkat lunak atau Disain usulan penelitian hendaknya menguraikan garis besar yang dilaluinya. Sedangkan uji coba, hendaknya menyebutkan skenario uji coba secara global, lalu cara evaluasinya bgm, yang diukur sbg tingkat keberhasilan itu apanya. Panjang sub bab Metodologi ini harusnya minimal 2 halaman. Teori-teori tentu saja tidak perlu dimasukkan, namun kegiatan apa saja selama TA harus terdapat di sana. Tujuannya agar di masa depan, bila ada orang lain yang ingin meniti jalan yang sama, maka harus bisa dipastikan akan memperoleh hasil yang sama pula, sebagaimana resep makanan yang siapapun pemasaknya, maka rasa makanan yang dihasilkan harusnya sama lezatnya.


Dasar Teori
Beberapa topik dasar yang mendukung judul TA ini harus ditulis di sana. Misalkan Segementasi citra dengan neural network berbasis graph dan algoritma genetika. Judul tersebut berarti membutuhkan dasar teori ttg 1. citra dan segmentasi, 2. NN, 3. Graph, dan 4. GA.
Teori ini diambil dari berbagai buku dan paper yang terkait
Sebaiknya pengambilan dari paper utama tidak secara total, sebab dikhawatirkan topik utama dalam TA tersebut justru masuk di sini, padahal seharusnya di bab 3. Jadi Bab2 ini menceritakan teori yang DASAR saja plus pekerjaan orang lain, sedangkan Bab 3 nanti itu yang pekerjaan kita sendiri.d. Karena merefer ke buku atau paper, maka jangan lupa banyak2 memberi tanda kurung siku berisi nomor referensinya.
Disain
Pada bagian ini perlu diuraikan lebih dahulu disain secara keseluruhan. Cara yang paling umum adalah dengan membuat Data Flow Diagram, sebab pergerakan data dari user ke berbagai process hingga menjadi output tergambar jelas. Bila menemui process, hendaknya dijelaskan algoritmanya, boleh dengan Flow chart (bila tidak terlalu ruwet) atau dengan Pseudo Code (penjelasan tahap per tahap).
Disain sistem secara keseluruhan perlu menjadi sub bab khusus, termasuk disain interfacenya.

Implementasi
Pada prinsipnya semua yang terkait dengan implementasi, baik perangkat lunak maupun perangkat keras harus ditulis di sini. Bahasa pemrograman apa saja yang turut membangunnya.
Code dapat juga ditampilkan terutama code yang menjadi inti TA tersebut, beserta berbagai parameter yang harus diset.
Uji Coba dan evaluasi
Diawali dengan menceritakan data, yakni karakteristik, jumlah, dan pembagiannya bila menggunakan training set dan testing set.
Skenario uji coba perlu dijelaskan secara global. Tiap skenario uji coba memiliki tujuan tertentu. Misalkan untuk menentukan parameter alpha, maka dibutuhkan eksperimen mengubah nilai2 alpha sambil mengukur akurasi output. Dalam hal ini tujuan menjadi jelas, dan yang diukurpun jelas.
Penentuan nilai parameter seringkali menggunakan ”magic number”. Angka ini sering muncul dg alasan paper yang diacu menggunakan angka tersebut. Alasan lain bahwa angka tersebut dipilih secara insting belaka. Hal ini sebisa mungkin dihindari, sebab bila nilai tsb memiliki range ckp panjang, maka tidak ada yang bisa menjamin bahwa angka magic tersebut yang paling optimal. Uji coba dg berbagai input yang ekstrim dapat pula ditempuh dan dilaporkan hasinya (misal diisi 0 atau negatif atau 1 juta).
Evaluasi boleh saja dijadikan satu bab dg uji coba, namun tetap saja harus tertulis jelas, apakah evaluasi dari tiap uji coba tersebut. Misalkan dg mengukur akurasinya, kecepatannya, kompleksitasnya, dan lain-lain. Demikian pula bila evaluasi itu harus ditulis secara subbjective (misal: bagus, besar, dll) dan tidak objective (misal: 0.4, 70 %, dll).

Kesimpulan dan saran
Semua yang tertulis di sub bab permasalahan, hendapknya dijawab di kesimpulan ini. Misal ada 3 masalah, maka kesimpulannya minimal harus menjawab ketiga masalah tersebut.
Kesimpulan lainnya adalah apa saja yang berhasil ditemukan baik terutama yang menarik perhatian, misalnya tidak terlalu berpengaruhnya sebuah parameter yang tadinya dianggap penting, fenomena khusus selama uji coba, dll.
Saran tidak harus ruwet, sebab setiap pengerjaan TA memiliki angan-angan untuk mencoba metode lain untuk menggantikan salah satu modul yang dirasa kurang robust. Hal ini adalah sebuah saran pengembangan yang dpt dituliskan.
Panjang Tulisan
Pada umumnya jumlah minimal adalah 60 halaman, tapi janganlah merasa bahwa disuruh menulis banyak itu menyiksa, tapi bahkan sebaliknya. Menuliskan semua pengalaman sejak awal hingga akhir itu adalah penghargaan kita terhadap usaha kita sendiri. Kasarnya, bila teksnya tipis, kesannya sedikit sekali perkerjaan mhs tersebut, padahal kenyataannya dia belajar siang malam, banting tulang, bahkan kadang sampai stress, sumpek, sakit, atau marah-marah, dll. Ini semua perjuangan yang harus dihargai. Jadi kalau buku TAnya tebal berarti menuliskan semua tindakan kita secara komplit dan itu akan menjadi dokumentasi seumur hidup (selepas dari masa kuliah) yang akan dibaca orang dan dianggap mewakili fisik penulisnya. Kalau jelek atau acak-acakan, berarti karakter penulisnya kira-kira tak jauh dari itu.
Penulisan atau pemuatan rumus, data, atau hasil uji coba yang luar biasa panjangnya, sebaiknya dihindari. Secara singkat (hanya yang sangat relevan) dapat ditulis di bab 2, 3, atau 4, namun secara lengkap dapat ditulis sebagai lampiran. Tidak lupa juga tulislah user guide (petunjuk penggunaan sistem secara jelas).

Gambar dan Tabel
Gambar 3.1 yang tertulis di bawah sebuah gambar menunjukkan Label atau address gambar tersebut. Dg demikian gambar tsb tdk harus diletakkan persis di bawah teks yang membahasnya. Boleh saja diletakkan sebelum atau jauh setelah teks yg membahasnya dg mempertimbangkan estetika atau kemudahan printing.
Karena merasa diharuskan agar gambar diletakkan setelah teks yg membahasnya, maka seringkali terdapat ruang kosong yg cukup lebar di bagian bawah kertas, karena gambarnya berukuran besar. Hal ini tdk boleh terjadi, sehingga ruang kosong tersebut dapat diisi oeh teks lain yg mengikutinya. Adapun gambar dpt dikirim ke halaman lain yang mampu memuatnya.
Semua gambar dan tabel harus pernah diceritakan di dalam teks.
Seringkali tertulis ”sebagaimana pada gambar berikut ini : ”. Teks ini salah, sebab gambar telah memiliki pointer, sehingga ckp ditulis ”sebagaimana Gambar 3.1”, tanpa kata ”berikut ini”, sebab bisa jadi posisi gambar tersebut tidak mengikuti teks yang dimaksud.
Seringkali ada kesalahan ”gambar 3.1” atau ”tabel 4.1”, seharusnya g dan t menggunakan huruf kapital, sebab keduanya adalah pointer.
Gambar dan tabel juga merupakan sarana yang efektif untuk menunjukkan hasil uji coba. Namun demikian, pemuatan grafik seringkali tidak disertai penjelasan yang memadai, seolah-olah para pembaca dipersilahkan memaknai sendiri apa yang terdapat di dalam grafik tersebut. Demikian pula pada tabel, padahal di dalam tabel tersebut, banyak angka-angka yang tidak terlalu relevan dan ada sejumlah angka yang sangat penting diketahui pembaca. Hal ini tidak mungkin tercapai bila penulis tidak memberikan penjelasan yang cukup. Jadi jangan biarkan orang memaknai gambar / grafik / tabel kita dengan pemahaman mereka sendiri, namun kitalah yang menuntun mereka, bagian-bagian mana yang harus diberi perhatian khusus.

Teks

Italic-kan semua kata asing.
Setiap notasi dalam rumus atau persamaan harus pernah dijelaskan artinya.
Huruf diawal kalimat harus kapital, sedangkan di tengah kalimat tidak. Saat penulisan rumus, terdapat kata “dimana”, namun kata ini menjadi “Dimana”, sebab berada di awal kalimat. Seharusnya setelah rumus terdapat koma, kemudian “dimana” menggunakan “d” kecil. Bila rumus tersebut memang berupa akhir kalimat, maka diberi tanda titik.

DATA FLOW DIAGRAM

Diagram Konteks Sistem Penilaian Pegawai (SPP)

Bagan Sistem

Investigate and Define Problems
Adapun problem yang ada didalam SPP (Sistem Penilaian Pegawai), antara lain:
1. SPP menampilkan semua surat tugas untuk Kabag
2. SPP dapat mendeliver tugas-tugas kepada subbagian yang berkaitan
3. SPP dapat membantu kasubbag untuk memberikan tugas kepada staff
4. SPP dapat menghitung waktu pengerjaan tugas staff berdasarkan waktu mulai dan waktu selesai
5. SPP dapat memberikan laporan kepada kasubbag dan subbag untuk review tugas tersebut

Adapun requirement yang ada didalam SPP (Sistem Penilaian Pegawai), antara lain:
1. SPP dapat menghitung poin staff
2. SPP dapat menghitung perolehan nilai tambahan bagi staff yang bersangkutan

Problem (masalah), Requirement (Kebutuhan) Sistem

PROBLEM
Adapun permasalahan yang ditangani oleh Sistem Penilaian Pegawai (SPP), antara lain:
1. Bagaimana SPP bisa menampilkan semua surat tugas untuk Kabag
2. Bagaimana SPP bisa mendeliver tugas-tugas kepada subbagian yang berkaitan
3. Bagaimana SPP bisa membantu kasubag untuk memberikan tugas kepada staff
4. Bagaimana SPP bisa dapat manghitung waktu pengerjaan tugas staff berdasarkan

waktu mulai dan waktu selesai
5. Bagaimana SPP bisa menghitung poin staff
6. Bagaimana SPP bisa menghitung perolehan nilai tambahan bagi staff yang

bersangkutan
7. Bagaimana SPP bisa memberikan laporan kepada kasubag dan subbagian untuk

review tugas tersebut
8. Bagaimana Admin Bagian dan Admin Umum mengelola data administrasi SPP (Sistem

Penilaian Pegawai)


PROBLEM
Adapun permasalahan yang ditangani oleh Sistem Penilaian Pegawai (SPP), antara lain:
1. Bagaimana SPP bisa menampilkan semua surat tugas untuk Kabag
2. Bagaimana SPP bisa mendeliver tugas-tugas kepada subbagian yang berkaitan
3. Bagaimana SPP bisa membantu kasubag untuk memberikan tugas kepada staff
4. Bagaimana SPP bisa dapat manghitung waktu pengerjaan tugas staff berdasarkan

waktu mulai dan waktu selesai
5. Bagaimana SPP bisa menghitung poin staff
6. Bagaimana SPP bisa menghitung perolehan nilai tambahan bagi staff yang

bersangkutan
7. Bagaimana SPP bisa memberikan laporan kepada kasubag dan subbagian untuk

review tugas tersebut
8. Bagaimana Admin Bagian dan Admin Umum mengelola data administrasi SPP (Sistem

Penilaian Pegawai)

Requirement (Kebutuhan) Sistem
Fungsi Produk

Fungsi produk perangkat lunak Sistem Penilaian Pegawai (SPP) yang akan dikembangkan berdasarkan user sebagai berikut:
1. Admin umum
2. User
Kabag
Kasubag
Staff
Admin bagian

Karakteristik Pengguna

Pengguna (user) perangkat lunak Sistem Penilaian Pegawai (SPP) tersebut adalah Admin dan user (Kabag, Subbagian, Kasubag, Staff) yang mempunyai karakteristik sebagai berikut:

1. Admin
Mengelola sistem (web) setiap departemen
2. User
- Kabag
Menerima laporan surat tugas yang akan disampaikan kepada bawahannya
Review dokumen pengerjaan yang dibuat/dikerjakan bawahannya
- Kasubag
Menerima laporan tugas yang akan disampaikan kepada bawahannya
Review dokumen pengerjaan yang dibuat/dikerjakan bawahannya
- Staff
Mengisi/mengerjakan tugas
Menerima perhitungan poin
- Admin bagian
Mengelola sistem perbagian
Membantu tugas kabag

Batasan

Batasan –batasan dalam pengembangan perangkat lunak Sistem Penilaian Pegawai (SPP) adalah sebagai berikut:
1. Sistem dibuat menggunakan Bahasa Pemrograman PHP dan Postgre sebagai pengolah data
2. Sistem dibuat berbasis web agar bisa diakses dimana saja dan kapan saja.

Lingkungan Operasi

Sistem Penilaian Pegawai (SPP) akan bisa berjalan dengan spesifikasi sebagai berikut:
1. Sistem Operasi : Windows XP
2. DBMS : Postgre
3. Bahasa pemrograman : PHP 5.0
4. Case Tool : Power Designer 6.5.
5. Dokumentasi : Microsoft Office 2003, Microsoft visio 2003

Data Requirement

Adapun data yang dikelola sistem, antara kain:
1. Data Staff
2. Data Kasubag
3. Data Subbagian
4. Data Kabag
5. Data Laporan Tugas
6. Data Tambahan Nilai
7. Data Poin
8. Data Administrasi