Last but Not Least Part -> Kesimpulan!

Kita seringkali menyepelekan bagian ini (*setidaknya itu yang kami pikirkan selama beberapa momen ke belakang saat membuat sebuah laporan, sampai akhirnya kami menemukan sentilan dalam proses pengerjaan Tugas Akhir ini). Mengapa? Karena biasanya fokus lebih ditujukan pada bagaimana konten utama, misal Implementasi agar menarik pembaca untuk memberitahu tampilan aplikasi yang ada. Namun ini tidak 100% berlaku untuk para Penguji. Alasannya simpel, karena mereka bisa jadi lebih paham mengenai apa yang akan kita implementasi. Selain itu, karena hal yang mereka ingin eksplor adalah bagaimana akhir dari TA yang kita kerjakan, apa yang sudah berhasil terimplementasi, dan apakah kita sadar dengan kekurangan dalam aplikasi kita (karena jika kita sadar, permasalahannya bisa jadi bukan di pemahaman kita, tapi pada manajemen waktu kita selama proses pengerjaan).

Beberapa dari kita terbiasa menuliskan judul bagian ini dengan 'KESIMPULAN dan SARAN'. Hentikan itu! Meskipun memang di dalamnya terdapat dua komponen tersebut, tapi standar yang berlaku (setidaknya di JTK), tuliskan saja apa yang menjadi inti, 'KESIMPULAN', biarkan 'SARAN' menjadi bagian pelengkap dari simpulan yang ada.

1. KESIMPULAN
   Kami sudah beberapa kali melakukan perubahan konteks kalimat dalam bagian ini. Lebih banyak disebabkan oleh ketidak-yakinan dengan apa yang HARUSNYA dituliskan disini. Tapi setelah melewati beberapa kali konsultasi dengan pembimbing, beberapa hal yang kami yakini perlu menjadi bagian dari KESIMPULAN adalah:
• Ringkas konsep utama dari sistem/aplikasi kita ke dalam beberapa kalimat. Tapi jangan pernah memperlihatkan kebiasaan COPY-PASTE yakni dengan meng-copy bagian dari bab2 di atas dan mem-paste nya ke KESIMPULAN. Yakini pembaca bahwa kita paham inti dari konsep aplikasi kita, ringkas dengan bahasa ilmiah.
•  Sampaikan secara KUANTITATIF, pencapaian tugas akhir kita. Jangan mengira2 dengan menggunakan kata 'sangat', 'lebih baik', dan lain2 tanpa ada data kuantitatif menyertainya. Misal, "Nilai tertinggi yang dicapai hampir mendekati 1, yaitu 0,92 yang menunjukkan bahwa tingkat relevansi ayat dengan kata kunci sangat tinggi." Jangan biarkan para Penguji melihat kelemahan kita dalam berkata2, hahaha.
  JUGA INGAT, jangan menyertakan kalimat2 seperti "... yang telah kami capai...", atau yang menyertakan keterangan pelaku. Itu menunjukkan kalau kita sedang CURHAT. Sekali lagi sampaikan dengan menggunakan bahasa ilmiah alias secara OBJEKTIF.
2. SARAN
   Bagian ini sangat penting untuk memberi harapan pengembangan atau perbaikan sistem yang telah kita buat. Sasaran yang memungkinkan biasanya adalah untuk para generasi penerus (*adik kelas, dst...). Karena bisa jadi aplikasi yang kita buat memang sudah sempurna, namun karena dibangun di atas J2SE, seiring perkembangan zaman, platform yang pada zaman kita merupakan yang paling WAH bisa saja tergeser, bahkan menjadi punah di zaman adik2 kelas kita kelak. Itu mengapa, bagian SARAN ini penting untuk memberitahu adik2 kita mengenai possibilities pengembangan aplikasi ke teknologi yang lebih baik. Misal: dalam kasus Sistem Temu Balik yang identik dengan pencarian dan rekomendasi, kami memberi salah satu saran seperti "Pengguna dapat memberikan  feedback  (misal berupa rating/skala kepuasan) terhadap hasil rekomendasi agar sistem mampu memberikan rekomendasi tidak hanya berdasarkan input."

Begitu yang dapat kami sampaikan. Pasti banyak kekurangan. Jika ada pengalaman yang dapat dibagi, tulis saja komentar di bawah. Akan sangat menyenangkan bisa berbagi dengan adik2 kita agar tidak mengulangi kesalahan yang sama. ^^

Pengujian???

Hal pertama yang harus diperhatikan pada bagian ini adalah menentukan Metodologi (ciee, bahasanya...) Pengujian apa yang akan digunakan. Dua contoh yang kami ketahui adalah Black Box dan White Box Testing. Secara singkat, Black Box Testing adalah testing yang dilakukan tanpa mementingkan proses yang dijalankan, sementara White Box adalah sebaliknya (gimana tuh? ngerti lah ya...). Kami menggunakan Black Box Testing, karena pada bagian Pengujian kami hanya ingin memperlihatkan bagaimana kesesuian antara input dan outputnya.

Selain itu, beberapa bagian yang -mungkin- penting ada dalam Bab ini adalah:

Perencanaan Pengujian

Pada bagian ini dilakukan perincian mengenai :

1. Pelaku Pengujian
2. Skenario Pengujian
   Pada bagian ini dijelaskan lagi per-poin bagian pengujian. Misal, dalam aplikasi kami, dibuat pembagian sbb:

• Preprocessing, untuk memastikan kata kunci yang akan digunakan sesuai dengan matriks yang ada (Case Folding dan Tokenizing, Filtering, Stemming);
• SVD, untuk memastikan perhitungan matriks term dan document sesuai;
• TF-IDF, untuk melakukan perhitungan bobot antara dokumen dan term;
• Perhitungan Cosine Similarity antara Query dengan Dokumen, untuk memastikan hasil pencarian sesuai dengan query yang dimasukkan.

Terlepas dari format bab Pengujian yang standar, kami ingin menegaskan bahwa pengujian ini bertujuan agar Implementasi yang sudah dilakukan teruji kebenarannya, dengan kata lain, meyakinkan pembaca (atau dalam hal ini yang terpenting adalah para Penguji TA kita) bahwa tiap komponen/fungsi/method yang membentuk sistem sudah menghasilkan output yang sesuai (ketika memang SALAH, muncul sebagai sesuatu yang SALAH, begitu juga sebaliknya, bukan berdasarkan kira2).
Yah, sekian dari pengalaman kami menggeluti bab Pengujian ini.. Semoga bermanfaat... ^^

Come to The Implementation

Menuju sidang nih, kudu cepet2 implementasi aplikasi. Satu hal yang mau saya bagi di sini adalah,,, meskipun sesi analisis dan desain HARUSnya sudah berakhir, namun kenyataannya tidak bisa se-ideal itu. Karena, ketika seminar 3, kita menyadari banyak sekali hal yang masih kurang, bisa itu lewat teguran penguji, melihat referensi TA temen2 lainnya, maupun dari pencerahan yang tiba2 datang begitu saja. Tapi ga perlu khawatir, selama kita masih menyadarinya sekarang, ga ada yang terlambat, mumpung belum sidang kan...
Di Implementasi (khususnya untuk si laporan) kita akan banyak sekali merujuk ke Bab Analisis dan Perancangan karena apa yang akan kita implementasi adalah apa2 yang sudah kita analisis dan kita rancang. Itu adalah HARUS! Jangan ngalor ngidul, okeh. Karena kelompok kami banyak sekali mendapat teguran atas kelalaian kami yang tak memperhatikan dengan teliti kedua bab tersebut dan para dosen penguji akan sangat memperhatikan hal2 tersebut.Yuk kita tilik satu persatu komponen Implementasi (ini versi pemahaman kami loh...)

1. Batasan Implementasi
   Ini adalah bab yang menjelaskan sampai mana kita akan mengimplementasi sistem yang sudah kita analisis dan rancang. Karena pada kenyataannya rata2 kita tak bisa mengimplementasi 100% sesuai dengan harapan kita. Ya, itu boleh2 saja, asalkan jelas kita beritakan di laporan.
2. Deployment Diagram + Penjelasan
   Ini adalah diagram yang akan menjelaskan di atas apa kita membangun sistem kita, dan di atas apa sistem kita akan berjalan, secara hardware maupun software. Misal, OS nya apa, package library nya apa, toolsnya apa, dst.
3. Implementasi Modul
   Dalam Bab Perancangan sudah kita rancang kira2 modul apa saja yang kita butuhkan. Nah, di sini kita akan secara transparan memberi tahu modul apa saja yang ingin diimplementasi, requirement apa saja yang terpenuhi olehnya, dan status keberadaannya dalam sistem (ada/tidak terimplementasi).
4. Implementasi Requirement
   Nah loh, apa pula ini??? Awalnya kami juga bingung, karena dosen penguji mengharuskan kami membuat suatu tabel yang dapat menginformasikan keterkaitan tujuan, analisis, dan requirement yang ada. Namun terlepas dari apa judulnya begini kurang lebih yang kami buat.
   
5. Implementasi Data
   Kalo yang ini, kita perlu memberi informasi status apakah tabel2 yang sudah dirancang tersebut diimplementasi atau tidak.
6. Implementasi UI
   Untuk membuktikan bahwa kita sudah mengimplementasi suatu sistem aplikasi, tentu perlu ada bukti kan? Nah, di sini perlu kita tampilkan seperti apa tayangan sekilas mengenai aplikasi kita. Tak perlu semua kemungkinan, hanya beberapa yang sekiranya menjadi andalan dan perlu/penting untuk disampaikan. Karena demo aplikasi pun nanti akan dilakukan.

 Itu sekilas dari apa yang harus kita perhatikan dari segi LAPORAN. Namun dalam implementasi, tentunya yang paling penting untuk diperhatikan adalah HOW TO DO IT? Ya, ini tak mudah, karena kita bahkan harus mulai melakukannya saat masa analisis, karena kita perlu mempelajari terlebih dahulu sistem yang akan kita kembangkan. Hal terpenting yang kami rasakan adalah:

• Perlu kembali me-refresh/mengenal pengetahuan teknis dari (sintaks2, how to use, dll) dari tools yang akan kita gunakan.
• Perlu membuat kasus2 kecil, terkait dengan modul2 yang akan kita gunakan. Jangan langsung berpikir HOW TO FINISH OUR PROGRAM, tapi pikirkan HOW TO SOLVE OUR PROBLEM. Jadi kan kita bagi2 sistem kita ke dalam beberapa modul, nah kita test masing2 modul tersebut dengan percobaaan2 kecil.
• Pembagian tugas per anggota harus jelas. Minimal meskipun tugas perorangnya tidak spesifik, tapi harus jelas pertanggungjawaban masing2nya. Misal, yang bertanggungjawab terhadap integrasi laporan, integrasi code, database, dll.
• Ketika dirasa harapan pencapaian sistem tidak bisa 100%, rancang kembali strategi untuk 'menurunkan' idealisme namun poin tujuan di awal tetap dapat dicapai.

Intinya sih, semuanya harus terstruktur, bila perlu gunakan cara SVN, supaya jelas versioning nya. Jaga harmonisasi kelompok, jangan biarkan egoisme meruntuhkan keutuhan kelompok kita. Semangat implementasi !!! ^^

Terlalu lama ya...? Now, Let's Designing!

Maaf ya, sekian lama kami melaksanakan TA, belum melaporkan progress lagi, hehehe. Kami sudah sampai di tahap pra-Seminar 3. Di Seminar 3 ini, kami dituntut untuk menghasilkan dokumen sampai ke perancangan dan sudah bisa  men-demo-kan aplikasi yang akan dibuat, sehingga Dosen Penguji sudah bisa melihat kemungkinan realisasi aplikasi yang telah direncanakan.
Dalam dokumen Bab Perancangan, yang biasanya dibahas adalah :

1. Rancangan Database yang biasanya direpresentasikan oleh ER (Entity-Relationship) Diagram, CDM (Conceptual Data Model), lalu PDM (Physical Data Model). Adapun dari ERD, kita harus menjelaskan masing-masing tabel yang akan kita gunakan pada sistem aplikasi kita.
2. Model Perilaku Sistem yang direpresentasikan oleh use case diagram + skenario nya. Dan yang jangan dilupakan juga adalah penjelasan aktor yang tertera pada use case.
3. Masih berlanjut dari poin 2, lalu masuk ke Sequence Diagram yang akan lebih menjelaskan alur pekerjaan tiap use case yang ada. Tiap komponen Sequence Diagram akan mewakili kemungkinan class-class apa saja yang akan kita gunakan.
4. Seperti yang diungkapkan di atas, setelah tergambar dari sequence diagram, maka buat Package Diagram dan Class Diagram nya. Package Diagram merupakan penggambaran pengelompokan class agar lebih terstruktur, misal komponen class yang mengurusi database, kalkulasi, dll dipisah dalam package yang berbeda. Sedangkan class diagram sendiri adalah untuk menggambarkan class-class yang akan kita gunakan, juga keterkaitannya dengan class lain (tergambar juga dalam sequence diagram).
5. Dalam class, pasti berisi modul-modul yang menunjang fungsionalitas dari class tersebut, sehingga dibutuhkan Tabel Deskripsi Modul. Jika modul yang digunakan sangat banyak, misal dalam tiap class bisa mencapai 10 modul, maka pilih saja yang utama dan sekiranya penting untuk diketahui pembaca laporan, misal jika kita berdomainkan 'Sistem Temu Balik Informasi', maka sertakan modul yang utamanya, seperti misal searchByInput, cosineSimilarity, SVD, LSACalculation, dll.
6. Dalam modul juga, pasti kita akan bertemu dengan variabel-variabel atau record-record yang akan menjadi parameter dan diproses dalam modul yang kita buat, nah maka dari itu dibutuhkan Perancangan Struktur Data. Di sini akan dijelaskan mengenai nama variabel yang kita gunakan, deskripsinya dan bagaimana struktur datanya.
7. Bagian paling penting bagi pembaca adalah Rancangan User Interface, sehingga terlihat bagaimana hasil tampilan sistem aplikasi yang akan kita buat. Ini bisa dibuat dengan menggunakan salah satu tools mock-up (*my fav ^^) yaitu Balsamiq Mockups. Tapi, selain gambar UI nya, juga harus ada penjelasan mengenai masing-masing komponen yang ada di situ, misal jika ada tombol A, jelaskan apa guna tombol tersebut, bagaimana respon sistem setelah itu, juga modul-modul yang terkait.

Yah, sekian penjelasan yang akan kami lakukan pada sesi Perancangan ini, semoga membantu... ^^

Goes to Seminar 2 - AnalysisDone-Oriented

Jangan pernah menyepelekan kata2 analisis. Ini yang sering menjadi batu sandungan ketika kita akan melanjutkan ke tahap berikutnya. Perancangan yang baik adalah yang sesuai dengan hasil analisis yang telah dilakukan, lantas bagaimana cara melakukan analisis yang baik dan benar?

Haha, gaya banget ya pernyataan di atas... :P
Berasa pakar gimana,,,gitu...
Engga ko, tenang aja, kami mau cari aman. Tiap kata di postingan ini hanya berdasarkan pengalaman saja alias ga ada referensi shahih. Tapi walau begitu, InsyaAllah akan bermanfaat ko terutama buat anak2 JTK POLBAN yang akan melaksanakan Tugas Akhir nya. Dont be too long! Check it out yo...

Setahu kami, komponen penting yang perlu ada dalam Bab Analisis adalah:

• Analisis terhadap sistem serupa / yang sudah pernah ada. Kalo udah pernah ada, kenapa perlu kita buat lagi? Buat apa dianalisis? Namanya juga manusia yang buat, semahir apapun, pasti ada aja kekurangannya, dan mungkin aja kita adalah salah satu yang tahu dan paham akan kekurangan tersebut dan mampu untuk memperbaikinya. Dan lagi, menurut salah satu pembimbing kami, Pak Jonner, "Ya, usahakan kalian tidak membuat aplikasi dari awal/yang sifatnya inovasi total." Tahu kenapa? Bukannya tidak boleh, ya, kalo waktunya memang memungkinkan, silakan saja. Karena menurut Dosen Senior kami, Pak Ridwan, "Ga usah bikin yang aneh2 lah. Saya yakin, kalian itu mampu, tapi waktunya kan cuma sebentar." Jadi inti yang saya tangkap adalah tak perlu 100% mengikuti idealisme dulu, perhatikan kemampuan dan waktu yang tersedia. Kalaupun kita mampu, perhatikan apakah teman2 kelompok kita juga mampu? *Ko jadi kesini ya? Tapi ketangkep kan ya, maksudnya gimana...
  
  Balik lagi deh, jadi yang disorot dari sistem yang sudah ada itu adalah bagaimana perilakunya (misal digambarkan dalam Use Case Diagram atau dideskripsikan via Use Case Skenario). Lalu buat evaluasinya, sehingga terlihat dimana peran sistem yang akan kita buat kelak.
  Jika terdapat aplikasi serupa lebih dari satu, lakukan perbandingan terhadap aplikasi2 tersebut. Tentukan parameter2 apa yang kira2 mampu menunjukkan perbedaan antara aplikasi2 tersebut. Misal parameter yang kami buat adalah sebagai berikut.

• Analisis hal-hal yang berkaitan dengan aplikasi. Misal, karena tugas akhir kami berhubungan dengan sistem temu balik informasi (*pencarian) ayat Alquran, maka kami perlu menganalisis bagaimana input yang sesuai, bagaimana proses preprocessing dan stemming dilakukan, dan lain2.
• Analisis requirement. Ini adalah bagian krusial dalam analisis karena akan menjembatani kita ke proses perancangan. Maksud analisis requirement adalah berdasarkan analisis yang telah kita lakukan di atas (terutama dari hasil analisis sistem yang telah ada/telah berjalan), bagaimana requirement 'ideal' yang perlu kita perhatikan dalam perancangan sistem kita kelak. Perlu diperhatikan, bahwa karena 'ideal' itulah, kemungkinan pada akhirnya kita tidak mengimplementasi seluruhnya adalah mungkin saja. Namun ke-ideal-an tersebut harus tetap dituliskan dalam rangka memberitahu pembaca bahwa kita memahami domain yang sedang kita garap.
  Pada bagian ini, kita akan bergelut dengan komponen SRS yaitu Use Case diagram juga skenario (ayo, perhatikan jelas2 saat dosen APPL sedang mengajar), juga tidak lupa menyertakan DEFINISI AKTOR sistem yang akan kita buat. Misal dalam sistem kami, Pengguna -> Aktor yang menggunakan aplikasi untuk mencari terjemahan ayat Alquran berdasarkan kata kunci yang di-inputkan, menelusuri ayat-ayat Alquran, memilih ayat sebagai ayat favorit.
  Selain itu juga perlu dibuat Requirement Fungsional dan Non-Fungsional, yang singkatnya, Fungsional itu berhubungan dengan analisis yang sudah kita buat dan metoda yang akan kita gunakan, sedangkan Non-Fungsional merupakan kebutuhan pendukung untuk melengkapi fungsi yang ada pada sistem.
• Bussiness Rules. Apaan tuh??? Maksudnya adalah aturan2 yang harus dipenuhi untuk dapat menjalankan proses yang berkaitan dengan sistem kita. Misal, "Sistem harus memberikan rekomendasi ayat berdasarkan 5 rating tertinggi" dan harus disertakan itu berkaitan dengan requirement yang mana.

Cukup sekian ya, sedikit arahan dalam membuat Bab Analisis. Ingat, konten bab ini akan sangat menentukan apakah kita memahami domain TA kita atau tidak. Maka persiapkan otak untuk menggali lebih dalam sebenarnya bagaimana sistem yang akan kita buat? Selamat menganalisis...

Diskusi sambil Jalan2 ke Kampus Seberang

Kami sudah mencari beberapa penerangan (sebelum akhirnya ke pembimbing) mengenai konsep topik kami, tapi belum menemukan yang KLOP. Apa mungkin karena terus bergumul di daerah Ciwaruga, sehingga tak dapat inspirasi baru...???

Akhirnya kami putuskan untuk berjalan2 ke kampus orang, yang sudah cukup diketahui medannya karena salah satu dari kami pernah berkuliah di sana. Harapan kami sih, kami bisa mendapatkan inspirasi baru dan mencoba suasana baru. Kami pun berencana berkunjung ke perpustakaan pusat ITB yang katanya sih terbuka untuk umum.

Setelah sampai di sana, karena sedang dilakukan renovasi di beberapa bagian perpustakaan, sehingga membuat kami kurang nyaman berlama-lama diskusi di sana. Tapi untuk mengobati rasa penasaran kami, akhirnya kami putuskan untuk berdiam beberapa saat di sana untuk mencari kalau-kalau ada referensi yang bisa membantu kami. Tapi, karena begitu banyaknya buku di sana, dan terlalu beragam, kami sepertinya tak bisa menemukan buku yang kami harapkan. Ya, jadi kami buka laptop saja untuk memperbaiki BAB 1 kami yang agak ‘mengarang’ itu.

Entah karena lapar, otak kami berputar cukup kencang sampai sulit mengeluarkan kata-kata yang tepat untuk kami tumpahkan dalam sub BAB latar belakang. Huft... Walaupun akhirnya sampai pukul 13.00an kami mendapatkan beberapa kata sih... hehehe...

Setelah itu kami putuskan untuk istirahat shalat dan makan siang dulu, sampai akhirnya pukul 14.00an pun datang.

Hayoh, Labtek V nya yang mana?

Karena kami gemas ingin mendapatkan apa yang kami cari, akhirnya kami bertekad untuk ke perpustakaan STEI yang entah ada dimana... Saya pun bertanya kepada teman saya yang berada di STEI, dan katanya “ada di LABTEK V lt.3... Masuk aja, baca2 sih kayanya boleh, tapi gatau kalo bawa pulang mah...”. Alhamdulillah, ya,,, seengganya kami dapat akses ke tempat ajaib itu... (lebay)

Saat masuk, ternyata perpus itu juga cukup terbuka untuk umum, karena ada dari Unpar pun datang ke sana. Kami langsung bergegas menyerbu komputer yang berwallpaperkan tulisan “Kumpulan TA Informatika”. Kami cari dengan kata kunci semantic, text mining, recommender system, rekomendasi, dll. Ada sebuah TA yang menarik hati kami bertiga yaitu : “Sistem Temu Balik Informasi pada Teks Terjemahan Alquran Berbahasa Indonesia dengan Clustering dan Latent Semantic Indexing” karya Jamal Saepul Aziz. Waaahhh...

Saat kami mencari jurnal TA nya, kami langsung membaca isinya dan ternyata BINGO ! Cukup sesuai dengan yang kami butuhkan ! Hanya saja, karena TA nya bersifat penelitian, tidak terdapat aplikasi yang nyatanya. Di sana terdapat kata kunci :

1. Temu Balik Informasi / Information Retrieval
2. Model Ruang Vektor / Vector Space Model
3. Latent Semantic Indexing
4. Clustering
5. Zekr
6. Cluster Based Retrieval
7. Static Clustering
8. Post Retrieval Clustering
9. Singular Value Decomposition
10. Aproksimasi Low Rank

Zzzzz.... sebenarnya kami juga belum begitu mengerti, tapi setidaknya kami bisa memulai dari kata-kata kunci ini untuk kami pelajari dan sesuaikan dengan sistem yang akan kami buat.

Selain itu kami juga mendapatkan beberapa sumber referensi yang dapat kami gunakan untuk pembuatan sistem kami yaitu:

1. Thomas K. Landauer, Peter W. Foltz and Darrel Laham. An Introduction to Latent Semantic Analysis.
2. E. Garcia. “The Classic Vector Model. http://www.miislita.com/term-vector/term-vector-3.html.
3. Christopher D. Manning, Prabhakar Raghavan and Hinrich Schutze. Introduction to Information Retrieval.
4. Adomavicius, Gediminas and Alexander Tuzhilin. Toward the Next Generation of Recommender Systems : A Survey of the State-of-the-Art and Possible Extensions.

Selain konsep-konsep di atas, kami juga menemukan beberapa informasi mengenai Alquran itu sendiri, diantaranya ruku’, manzil, dan hal-hal terkait lainnya.

Kami berharap, apa yang kami temukan hari ini, dapat menjadi bekal bermanfaat untuk ke depannya, amin...

Diskusi Perdana Kami

Sebenarnya kami sudah mulai merencanakan TA ini sejak semester 5 kemarin, hanya saja nampaknya kami baru benar-benar sadar bahwa kami melaksanakan TA yang tidak lama ini di semester 6. Pada hari Selasa, 21 Februari 2012 kemarin di samping Ruang Belajar Direktorat, demi untuk mengheningkan cipta dari keriuhan yang ada, kami berdiskusi mengenai :

1. Domain TA
2. Calon Dosen Pembimbing
3. Perencanaan Pengerjaan TA (Plan A+B) juga target milestone

Pembahasan :

1. Untuk domain, sebenarnya kami juga sudah sedikit terbayang (lha wong sudah presentasi di proyek 5), namun ternyata latar belakang, dkk (BAB 1 dan 2) yang harusnya sudah jelas, malah jadi nampak tak jelas. Lho? Iya, karena kata penguji waktu itu, terkesan mengada-ada.
   Kami menuliskan seolah domain "Pencarian Tafsir Ayat Al-Quran ..." itu karena 'adanya permasalahan yang harus dpecahkan'. Gaya banget kan? Padahal, sebenarnya bisa hanya berupa 'keinginan pembuatan inovasi, berdasarkan keingintahuan, dan memberi kemudahan akses Al-Quran dengan adanya rekomendasi ayat'.
   Judul yang kami canangkan sekarang pun "Pencarian Ayat Al-Quran untuk (...) berdasarkan (...)" - masih perlu bimbingan. Adapun kami tidak jadi berupa tafsir, hanya berupa terjemah ayat Al-Quran.
   Lantas jika ditanya, "Apa bedanya dengan aplikasi Al-Quran Digital?", kami akan menjawab, kami akan memberi rekomendasi ayat yang lebih sesuai dengan input dari user. Dan "Siapa user itu?", kami jawab, umum, siapapun bisa.
2. Dosen pembimbing yang kami butuhkan adalah yang relatif "cerewet" dan memahami topik+domain kami. Jadi pilihan kami adalah :
• JN - paham topik kami, sudah menjadi pembimbing di proyek 5
• JO - paham topik+domain kami
• UT - paham banyak hal (DB), punya waktu untuk lebih 'cerewet'
• IA - wali kelas, bisa diajak diskusi mengenai domain
• IW - biasa membimbing TA dengan tema keislaman
3. Rencana pengerjaan kami, karena +- 2 pekan lagi seminar 1, maka kami baru merencanakan:
• Rabu 22022012 -> pembahasan hasil presentasi kemarin
• Kamis 23022012 -> perbaikan laporan

Sekian diskusi kami. Semangat TA !!!