Laporan Requirement Analysis

Saat ini seringkali kita mendapatkan perkuliahan diluar jadwal yang seharusnya entah untuk pengganti kelas karena minggu lalu perkuliahan tidak ada atau menarik perkuliahan lebih cepat karena alasan sesuatu. 

Untuk mencari kelas kosong yang akan digunakan nantinya, biasanya dosen menyuruh mahasiswanya untuk mencari kelas kosong tersebut, dan juga biasanya para mahasiswa cukup  malas untuk mencari ruangan kelas kosong tersebut dikarenakan beberapa hal ini :

  1. Jadwal perkuliahan di fakultas terlalu banyak dan tulisannya kecil – kecil sehingga cukup sulit untuk diteliti.
  2. Jadwal dibagi – bagi perjurusan saja, sehingga pada saat kita ingin mengecek suatu kelas, kita harus mengeceknya di setiap jurusan apakah kelas ini digunakan atau tidak.
  3. Terkadang yang ingin menggunakan kelas kosong tersebut lebih dari 1 kelas, sehingga dapat terjadi bentrok pada penggunaanya, pada akhirnya harus ada yang mengalah dan mencari kelas lain.
  4. Seringkali ada perkuliahan yang ditiadakan atau berakhir lebih cepat dari jadwal seharusnya, sehingga kelas yang digunakan untuk perkuliahan tersebut tidak terpakai dan statusnya tidak diketahui oleh orang lain.

Oleh karena itu kami ingin membangun sebuah aplikasi berbasis web service untuk menjawab masalah – masalah yang sering dikeluhkan oleh para mahasiswa pencari kelas tersebut. Untuk saat ini kami akan mengujikannya di lingkungan FPMIPA – C saja sebagai uji coba.

Untuk membangun sistem ini kami melakukan survey dengan penyebaran google form untuk mendapatkan requirement yang sesuai dengan permasalahan yang dihadapi para mahasiswa, dan dari hasil survey tersebut dapat disimpulkan bahwa :

  1. Banyak yang menginginkan sistem ini untuk membantu para mahasiswa dalam pencarian ruangan kelas kosong, entah untuk perkuliahan, praktikum, organisasi, dsb.
  2. Sistem dapat memfilter pencarian kelas berdasarkan jurusan, mata kuliah, ruangan kelas, hari, jam, dll.
  3. Selain informasi mengenai ruangan kelas, para mahasiswa juga ingin mengetahui jadwal penggunaan laboratorium sehingga pengaturan jadwal praktikum dapat lebih mudah dan tidak bentrok dengan praktikum lain.
  4. Ada status pemakaian kelas, sehingga semua orang dapat mengetahui status kelas tersebut apakah sedang terpakai atau tidak.

Untuk dokumentasi hasil survey dapat dilihat di :

https://docs.google.com/spreadsheets/d/1zD5uqtrNGGQ1fvXyKfG7SruVvMY5gtDhJH7GzNy9ZeA/edit?usp=sharing

Metode SCRUM pada Pendekatan Rekayasa Perangkat Lunak

SCRUM adalah salah satu metode rekayasa perangkat lunak dengan menggunakan prinsip-prinsip pendekatan AGILE, yang bertumpu pada kekuatan kolaborasi tim, incremental product dan proses iterasi untuk mewujudkan hasil akhir.

Di dalam setiap iterasi scrum, semua anggota tim saling berkolaborasi untuk menyelesaikan setiap incremental product yang telah direncanakan dan disepakati bersama. Dalam proses, setiap iterasi juga akan melakukan kegiatan analisis, merencanakan desain dan selanjutnya program siap untuk dikembangkan. Setelah program selesai, program juga akan diuji melalui proses testing yang telah direncanakan oleh tim, sehingga akhirnya program tersebut menjadi sebuah incremental product yang siap untuk di-deploy dan di-integrasi-kan dengan semua program yang telah dibuat sebelumnya.

Semua kegiatan diatas akan dilakukan oleh tim dengan konsep self-organizing, artinya semua anggota tim akan bekerja sama untuk mengelola kerja mereka sesuai dengan kesepakatan mereka. Anggota tim akan merencanakan tugas secara bersama dan melakukannya secara bersama sebagai sebuah kolaborasi tim.

Komponen utama di dalam SCRUM Framework adalah :

  • The Tree Roles: Scrum Master, Scrum Product Owner & Scrum Development Team
  • Backlog yang di prioritaskan yang berisi kebutuhan customer (end Users)
  • Sprints
  • Scrum Events: Sprint Planning Meeting (WHAT-Meeting, HOW-Meeting), Daily Scrum Meeting, Sprint Review Meeting, Sprint Retrospective Meeting

Komponen utama tersebut selanjutnya akan di jelaskan dibawah :

The Tree roles juga di namakan sebagai Scrum Teams yang idealnya hanya berukuran 7 +/- 2 Orang saja.

  • The Scrum Product Owner: Mewakili suara customer dan bertanggung jawab untuk memaksimal kan nilai produk dan hasil kerja Tim Pengembang. Dan yang menciptakan “APA” yang harus dimiliki oleh aplikasi.
  • The Scrum Master: Menjadi Pembicara, negosiator dan fasilitatior adalah tugas utama dari Scrum Master seperti layaknya seorang project manager.
  • The Scrum Development Team: Sekumpulan individu yang bekerja secara bersama untuk menyelesaikan product increment yang telah disepakati.

Product Backlog (PB): Sederhananya dapat di definisikan sebagai sebuah daftar semua hal yang perlu dilakukan dalam proyek. Pemilik dari Product Backlog adalah Scrum Product Owner. PO bertanggung-jawab terhadap Product Backlog, termasuk isinya, ketersediaannya, dan urutannya.

Product Backlog Item (PBI) Adalah list dari ‘user story’ untuk menggambarkan fungsi atau feature apa saja yang harus tersedia di dalam aplikasi. Product Owner akan membuat user story untuk selanjutnya dibawa dalam sebuah diskusi bersama untuk melihat lebih detail terkait dengan skala prioritas dan acceptance criteria. Item Product Backlog dapat diperbarui kapanpun juga oleh Product Owner–atau siapapun atas arahan Product Owner–kapanpun ia mau.

User Story contains mengandung : Peran (Story), Fitur (acceptance criteria) & Nilai (Effort/Priority)

Beberapa contoh user story pada Product Backlog Item

  • Jika user mencoba 3 kali password secara salah, maka user akan di lock.
  • Menghasilkan report nilai semester mahasiswa.
  • Report alokasi ruangan kelas dan mampu memberikan alert sehingga jadwal kuliah tidak konflik dengan jumlah ruangan yang ada.

Seluruh Story Form akan didiskusikan untuk selanjutkan diurutkan sebagai Product Backlog Item, sekaligus sebagai urutan incremental product pada setiap iterasi atau sprint.

Ada empat elemen wajib dalam setiap PBI; description, order, estimation, & business value. Elemen lain bisa saja ditambah jika dirasa perlu.

Sprint: merupakan jantung dari SCRUM, yaitu unit pekerjaan yang diperlukan untuk memenuhi kebutuhan yang ditetapkan dalam backlog sesuai dengan waktu yang ditetapkan dalam time-box (normalnya 2-4 minggu) di mana sebuah Inkremen yang “Selesai”, berfungsi, berpotensi untuk dirilis dikembangkan. Sehingga setiap Sprint juga bisa di katakan sebuah Project. Selama proses ini berlangsung backlog tidak ada penambahan. Sprint yang baru, langsung dimulai setelah Sprint yang sebelumnya berakhir.

Sprint dapat dibatalkan sebelum batasan waktu Sprint selesai. Hanya Product Owner yang dapat membatalkan Sprint, walaupun keputusan yang dia buat mungkin saja dipengaruhi oleh para stakeholder, Scrum Development Team, ataupun Scrum Master.

Pada saat Sprint:

  • Tidak boleh ada perubahan yang dapat membahayakan tercapainya Sprint Goal
  • Kualitas dari Sprint Goal tidak boleh menurun
  • Scope dapat diklarifikasikan dan dinegosiasikan ulang diantara Product Owner dan Tim Pengembang seiring dengan bertambahnya pengetahuan.
scrum3
scrum4

Aktifitas Sprint sendiri terdiri dari Sprint Planning, Daily Scrum, pengembangan, Sprint Review dan Sprint Retrospective.

Sprint Planning : Dilakukan di awal Sprint, tim berdiskusi dengan Product Owner mengenai Product Backlog item yang dimasukkan ke dalam Sprint. Planning dilakukan berdasarkan fitur bukan aktifitas.

Sprint Planning harus dapat menjawab pertanyaan-pertanyaan berikut:

  • Apa goal dari Sprint?
  • Apa yang dapat dihantarkan di dalam Inkremen sebagai hasil dari Sprint yang sedang berjalan?
  • Apa yang perlu dilakukan untuk dapat menghantarkan Inkremen tersebut?

Sprint Goal adalah sekumpulan tujuan yang akan dicapai dalam satu Sprint sepanjang pengimplementasian Product Backlog. Jika pengembangan berjalan seperti yang diharapkan maka diakhir iterasi akan ada potongan produk yang “done” yang disebut Increment.

“Done” yang dimaksud adalah memenuhi kriteria “Definition of Done” (DoD). DoD umumnya berupa daftar checklist yang bisa berbeda-beda di tiap organisasi. Jika tidak ada arahan dari organisasi, DoD ditentukan sendiri oleh para developer. Di DoD terlihat kualitas dari software yang dihasilkan dan siap digunakan.

scrum5

Daily Scrum Meeting / Daily Stand-up Meeting: Merupakan meeting dengan durasi pendek yang di lakukan secara harian, idealnya sebelum pekerjaan dimulai. Setiap anggota tim yang bekerja pada penyelesaian sprint harus turut berpartisipasi. Dalam pertemuan ini, setiap anggota tim harus secara singkat memberikan jawaban dari tiga pertanyaan berikut :

  • Kemajuan apa yang telah ia capai sejak daily scrum meeting terakhir ?
  • Apa yang ingin ia capai dalam Scrum meeting berikutnya ?
  • Hambatan apa yang ia dapatkan dalam menyelesaikan tugasnya ?
scrum6

Meeting ini didesain untuk dilakukan secara singkat, jika ada sesuatu yang detail, anggota tim bisa berdiskusi lebih detail diluar meeting ini dengan orang-orang terkait. Sehingga pertemuan ini adalah kunci dari proses peninjauan dan pengadaptasian.

Sprint Review Meeting: Diadakan di akhir Sprint untuk meninjau Inkremen dan merubah Product Backlog bila diperlukan. Pada saat Sprint Review, Tim Scrum dan stakeholder berkolaborasi untuk membahas apa yang telah dikerjakan dalam Sprint yang baru usai.

Jika sebuah user story telah dinyatakan gagal di dalam sebuah iterasi, tim bisa saja memutuskan untuk menunda terlebih dahulu user-story ini, untuk selanjutnya akan ditinjau kembali pada iterasi mendatang untuk menyelesaikan user-story yang masih belum yang belum berhasil.

Sprint Retrospective: Ini adalah meeting untuk melakukan instropeksi dengan melihat kembali perjalanan selama sprint berlangsung. Diskusi lebih berfokus kepada upaya untuk membangun sebuah timyang efektif dan optimal guna menyelesaikan sprint-sprint berikutnya. Mungkin perlu perbaikan dalam pola komunikasi antar tim, atau terdapat sebuah proses yang mungkin bisa dihilangkan karena justru menyulitkan tim tetapi efek terharap hasil akhir tidak sesuai dengan effort yang dikeluarkan atau banyak hal lainnya.

scrum7