Yang saya lakukan minggu ini sebenarnya lebih banyak untuk mengecek keadaan kode yang kami buat sekarang dan membenarkannya. Saya sendiri sudah melakukan beberapa refactoring yang dimana hal tersebut memperbaiki performa dari aplikasi kami. Salah satu yang paling berpengaruh adalah saat saya refactoring untuk Notification. Awalnya saya memakai kode yang mengimplementasikan infinite loop pada kode untuk terus menerus mengecek timestap dari device. Akan tetapi saya kemudian menyadari bahwa hal tersebut adalah hal yang tidak perlu. Saya cukup men-set service yang disediakan oleh Android untuk memunculkan notifikasi yang diinginkan.
Saya juga telah membuat kelas RemoteStorage yang tujuannya adalah untuk menyambungkan kelas LocalStorage kepada server aslinya di Badr. Saya sendiri sudah mennyambungkan kelas ini kepada Database Local aplikasi kami. Kemudian untuk implementasi servernya sedang dikerjakan oleh teman saya Hardi.
Kemudian untuk sumber mengenai definisi dari V&V kemarin (Verification and Validation), bisa dilihat di sini.Verifikasi adalah suatu proses pengecekan apakah program sudah memenuhi spesifikasi. sedangkan Validasi adalah proses pengecekan apakah program sudah memenuhi keinginan dari pelanggan/customer. Validasi membutuhkan teknik karena cenderung tidak mudah untuk menyocokkan keinginan pelanggan dengan asumsi developer.
Selanjutnya untuk Elicitation, Analysis, and Specification. sumbernya dapat dilihat di sini dan di sini. Elicitation adalah kegiatan yang behubungan dengan pengambilan requirement / requirement gathering dari klien/stakeholder. Teknik untuk Elicitation sendiri juga ada banyak. seperti misalkan Brainstorming, Questionaire, Mockup, Interview dan bahkan juga Prototyping. Output dari proses Elicitation adalah sebuah problem yang dimiliki user dimana problem tersebut haruslah terpecahkan oleh software yang kita buat.
Analisis adalah proses analisis dari hasil Elicitation. Dimana kita sebagai software developer mengecek apakah problem scope yang ditemukan sudah konsisten atau belum. Jika dirasa belum, maka proses kita dapat melakukan iterasi kembali ke proses Elicitation untuk mendapatkan problem scope yang baik. Problem Scope yang baik membagi masalah user dengan jelas, menjelaskan scope dari software dengan baik (misal software ini akan digunakan oleh perusahaan X saja, atau untuk semua orang, etc), dan tentunya konten dari problem scope ini haruslah konsisten. Yang jelas, proses Elicitation dan Analysis memiliki hubungan yang iteratif sehingga jika masalah yang dianalisis masih kurang, maka proses dapat kembali lagi ke Elicitation untuk mendapatkan problem scope yang lebih baik. Analisis ini akan menghasilkan sebuah solution system dimana hal tersebut adalah konsep dari software yang akan kita buat.
Kemudian di tahap Specification, developer menuliskan requirement yang dibutuhkan untuk mewujudkan solution system tersebut. Requirement itu sendiri dapat dituliskan dalam bentuk Use Case, User Story, maupun yang lainnya. Tidak ada pakem yang pasti mengenai bagaimana sebuah dokumen spesifikasi harus dituliskan. Akan tetapi penggunaan metode seperti Use Case, User story, dan SRS merupakan contoh dari bentuk dokumentasi specification yang baik.
Selanjutnya, kelompok kami juga sudah membuat dokumen untuk Functional dan Non-Functional requirement gathering. Linknya dapat diakses dari sini.
Sekian dari saya untuk minggu ini, Semoga bermanfaat!
Tidak ada komentar:
Posting Komentar