ETS RK D 2022

Evaluasi Tengah Semester 

Soal

1. Jelaskan macam-macam kebutuhan yang harus digali di dalam membuat perangkat lunak

2. Sesuai gambaran video buatlah BRD Pegadaian Digital

3. Buatlah video youtube untuk mempresentasikan jawaban anda

4. Jawaban ditulis disertai embedded video youtube di blog masing-masing dan buat koment pada posting berikut 

Jawaban

1. Tipe-tipe kebutuhan yang perlu digali dalam pengembangan perangkat lunak adalah:

a. Business Requirement (Kebutuhan Bisnis)

Adalah informasi dari kebutuhan yang harus dipenuhi sistem untuk memberikan solusi dan mencapai luaran yang diingin dalam sebuah bisnis. Informasi ini dapat mencakup peluang bisnis, tujuan bisnis, metrik sukses, dll.

b. User Requirement (Kebutuhan Pengguna)

Adalah sekumpulan tugas yang harus bisa dilakukan oleh suatu kelas pengguna di dalam sistem. Tugas ini dilakukan pengguna tersebut untuk mencapai suatu tujuan atau luaran yang diharapkan dari sistem. Kebutuhan ini biasanya direpresentasikan dengan use case, skenario, atau user story.

c. Functional Requirement (Kebutuhan Fungsional)

Adalah aksi atau fitur apa saja yang terdapat dalam suatu sistem. Aksi dan fitur tersebut harus dapat mendukung tugas dan tujuan berdasarkan kebutuhan pengguna dan bisnis. 

d. Non-Functional Requirement (Kebutuhan Non-Fungsional)

Adalah sekumpulan informasi tentang karakteristik, seperti batasan dan kualitas, yang terdapat pada sistem. Batasan disini adalah batasan dalam design ataupun implementasi sistem, seperti harus menggunakan teknologi tertentu. Sedangkan kualitas adalah karakteristik berhubungan dengan tingkat kepuasan stakeholder ketika menggunakan sistem, seperti kecepatan, keandalan, skalabilitas, dll. 

2. BRD yang telah kami buat adalah seperti berikut:

3. Video presentasi kami dapat dilihat di:

Tugas 6 RK D 2022

Pada tugas kali ini, kelompok kami membuat Business Requirements Document untuk aplikasi Uber. Berikut dokumen yang telah kami kerjakan:

Tugas 5 RK D 2022

Pada tugas kali. ini saya kan melakukan analisis kebutuhan untuk suatu aplikasi, yaitu Uber.

Deskripsi Aplikasi

Uber adalah aplikasi memungkinkan penumpang untuk mencari tumpangan juga pengemudi untuk memberikan tarif jasanya dan mendapatkan bayaran. Dengan kata lain, Uber adalah perusahaan ridesharing yang memperkerjakan pengemudi independen. Selain jasa transportasi,  Uber juga menghubungkan restaurant, grosir, dan pedagang lain dengan pengemudi. Sehingga, Uber juga bisa menyediakan jasa antar untuk makanan dan barang. 

Perusahaan ini sendiri didirikan oleh Travis Kalanick dan Garrett Camp pada tahun 2009, dan berkantor pusat di San Francisco. Saat ini, Uber melayani di lebih dari 70 negara dan 10000 kota. Uber memiliki sekitar 118 juta pengguna bulanan aktif di seluruh dunia dan dalam sehari memiliki rata-rata 19 juta perjalanan.

Kebutuhan Bisnis

Kebutuhan bisnis dari aplikasi Uber adalah:

1. Menyediakan layanan antar jemput untuk penumpang maupun barang.
2. Menciptakan lapangan pekerjaan untuk orang-orang yang memiliki kendaraan.
3. Menyediakan hal-hal yang dapat memudahkan proses transaksi antara pengemudi dan pengguna layanan. 

Kebutuhan Pengguna

Untuk pengemudi, kebutuhannya adalah:

1. Menerima pesanan dari penumpang
2. Melihat informasi terkait pesanan, seperti info penumpang, lokasi penjemputan, dan tujuan.
3. Mendapatkan rute perjalanan.
4. Melakukan komunikasi dengan penumpang.
5. Membatalkan pesanan penumpang.
6. Memberi penilaian untuk penumpang.
7. Menerima bayaran penumpang

Untuk pengguna jasa/penumpang, kebutuhannya adalah:

1. Menemukan pengemudi dan memesan tumpangan
2. Melihat informasi terkait pesanan, seperti biaya
3. Melihat informasi pengemudi
4. Melakukan komunikasi dengan pengemudi
5. Membatalkan tumpangan
6. Memberi penilaian untuk pengemudi
7. Membayar tumpangan

Kebutuhan Fungsional

Kebutuhan fungsional untuk aplikasi ini adalah:

1. Dapat mengetahui dan menampilkan lokasi dari pengguna aplikasi.
2. Dapat mencari driver berdasarkan lokasi penjemputan saat membuat pesanan.
3. Dapat menentukan rute perjalanan.
4. Dapat menghitung biaya berdasarkan rute perjalanan.
5. Dapat memberikan notifikasi pada pengguna.
6. Dapat menyimpan transaksi pengguna.
7. Dapat menyimpan penilaian pengguna.
8. Dapat menyalurkan uang pembayaran dari penumpang ke pengemudi.

Kebutuhan Non Fungsional

Kebutuhan non fungsional dari aplikasi ini adalah:

1. Sistem terus tersedia 24/7 tanpa henti.
2. Aplikasi tersedia untuk sistem operasi Android 5.0 ke atas dan Ios 13.7 ke atas.
3. Semua akun pengguna diamankan dengan password dan setiap transaksi memerlukan pin.
4. Rata-rata waktu respons aplikasi tidak boleh melebihi 500ms.
5. Error rate aplikasi tidak boleh melebihi 0.1%.

Tugas 4 RK D 2022

Di tugas kali ini, saya akan mencoba melakukan langkah pertama dalam rekayasa kebutuhan, yaitu Requirement Elicitation, untuk aplikasi di bidang pertanian. Di post ini, saya akan menggunakan aplikasi Pak Tani Digital sebagai studi kasus

Tentang Pak Tani Digital

Pak Tani Digital adalah sebuah startup sosial yang berusaha menghubungkan para petani dengan berbagai pemangku bidang kepentingan lainnya dalam satu perangkat aplikasi digital. Banyaknya permasalahan off-farming yang petani temui, mulai dari rendahnya harga komoditi, posisi tawar petani yang rendah, minimnya akses petani ke supplier, minimnya akses informasi pertanian, minimnya akses transportasi dan kondisi petani yang jauh dari teknologi, menyebabkan kesejahteraan petani di Indonesia masih rendah. Sehingga aplikasi ini dirancang untuk membantu petani belajar digital marketing, memasarkan hasil pertanian melalui marketplace, dan menemukan konsumen.

Selain itu startup ini juga berkomitmen menjadi platform media pertanian yang edukatif dan informatif di Indonesia, sehingga mendorong agar lebih banyak lagi generasi muda mencintai sektor pertanian. Pak Tani Digital juga berupaya untuk mengedukasi petani secara langsung, berkolaborasi dengan pemerintah, juga turun ke kampus-kampus pertanian di Indonesia dalam rangka sosialisasi digital farming di Indonesia.

Elisitasi Kebutuhan

Elisitasi kebutuhan adalah sekumpulan aktivitas yang ditujukan untuk menemukan kebutuhan suatu sistem melalui komunikasi dengan pelanggan, pengguna sistem dan pihak lain yang memiliki kepentingan dalam pengembangan sistem. Dengan begitu, pengembang dapat mencari tahu tentang layanan apa yang harus disediakan oleh sistem, kinerja sistem yang diperlukan, kendala perangkat keras, dan sebagainya.

Teknik Elisitasi

Untuk melakukan elisitasi ini, ada banyak teknik yang dapat digunakan. Contoh teknik-tekniknya adalah wawancara, observasi, focus group, kuesioner, dan masih banyak lagi. Dalam post ini, saya akan menggunakan teknik wawancara, Berikut adalah beberapa pertanyaan yang dapat digunakan dalam proses wawancara:

• Permasalahan apa yang ingin diselesaikan dengan aplikasi ini?
• Apakah sudah ada solusi lain untuk permasalahan tersebut?
• Apa yang membedakan aplikasi ini dengan solusi yang sudah ada?
• Siapa saja yang akan menggunakan aplikasi ini?
• Fitur apa saja yang diharapkan ada dalam aplikasi ini?
• Bagaimana fitur-fitur tersebut bekerja?
• Kapan saja fitur-fitur digunakan?
• Siapa saja yang dapat menggunakan fitur-fitur tersebut?
• Apa hasil akhir yang diharapkan?

Dari pertanyaan-pertanyaan tersebut, kita dapat melakukan:

Identifikasi Stakeholder

Stakeholder dalam aplikasi ini adalah:

1. Petani

Petani sebagai fokus dari aplikasi ini harus dapat terpenuhi kebutuhannya.

2. Konsumen Hasil Tani

Konsumen akan membeli produk pertanian yang ditawarkan petani.

3. Supplier Pertanian

Supplier akan menjual produk-produk pertanian kepada petani.

4. Transporter

Transporter akan menawarkan jasa mereka untuk petani.

5. Penyelenggara Sistem

Aplikasi ini diselenggarakan oleh Hagatekno Mediata yang dapat membuat segala keputusan terkait keberlangsungan sistem.

6. Pengembang dan Pengelola Sistem

Aplikasi ini akan dikembangkan dan dikelola oleh beberapa role, antara lain:

• UI/UX Designer
• Administrator
• Project Manager
• Business and System Analyst
• Frontend Developer
• Backend Developer
• Quality Control and Assurance
• Documentation Writer

7. Pihak Eksternal atau Pendukung Lainnya

Selain pihak-pihak utama tadi, sistem juga didukung oleh pihak lain, antara lain:

• Penyelenggara sistem pembayaran
• Investor
• Pemerintah pusat dan daerah

Identifikasi Tujuan

Tujuan dari aplikasi ini adalah

• Mendukung petani masuk ke dalam ekosistem digital
• Mempertemukan supplier, konsumen, juga transporter dengan petani
• Memudahkan transaksi jual-beli di bidang pertanian
• Menyediakan informasi dan edukasi di bidang pertanian

Identifikasi Kebutuhan

Beberapa kebutuhan yang terdapat di aplikasi ini adalah:

• Dapat menampilkan berbagai produk pertanian baik dari petani maupun supplier
• Dapat menampilkan jasa transportasi yang tersedia
• Dapat menampilkan harga pasar berbagai produk pertanian di berbagai daerah
• Dapat melakukan lelang untuk hasil pertanian
• Dapat menyediakan sistem pembayaran bagi pengguna
• Dapat menyimpan riwayat pesanan dan transaksi pengguna
• Dapat memberikan statistik penjualan/penghasilan bagi petani, supplier, maupun transporter
• Dapat menampilkan informasi-informasi di bidang pertanian

Tugas 3 RK D 2022

Pada tugas ini, saya akan menganalisis Maneuvering Characteristics Augmentation System (MCAS) yang terdapat pada pesawat Boeing 737 MAX. 

Deskripsi MCAS

MCAS adalah sebuah program stabilisasi penerbangan yang dikembangkan oleh Boeing. MCAS ini awalnya digunakan untuk pesawat militer Boeing KC-46 Pegasus, tapi terkenal karena menyebabkan dua kecelakaan penerbangan pesawat Boeing 737 MAX, Lion Air Flight 610 dan Ethiopian Airlines Flight 302, yang membunuh 346 orang. MCAS sendiri digunakan pada 737 MAX untuk meniru perilaku terbang pesawat generasi sebelumnya, Boeing 737 NG, sehingga dapat mengurangi training untuk pilot yang sudah pernah menerbangkan pesawat tersebut.

MCAS diimplementasikan pada 737 MAX untuk mengatasi naiknya hidung pesawat yang disebabkan karena efek aerodinamis mesinnya yang lebih berat dan besar daripada mesin pada pesawat generasi sebelumnya. Apabila hidung pesawat naik terlalu tinggi dan angle of attack-nya menjadi terlalu besar, maka akan menyebabkan pesawat mengalami stall dan jatuh. Karena itu jika terdeteksi angle of attack yang telalu besar, MCAS akan menurunkan hidung pesawat dengan cara mengatur roda penyesuaian (trim) agar horizontal stabilizer (sayap kecil di ekor pesawat) berputar, membuat hidung pesawat turun.

Selain angle of attack yang terlalu besar, MCAS juga akan aktif dalam beberapa kondisi lain, yaitu:

• Autopilot off
• Flap (sirip tambahan di sayap) tidak menjulur keluar
• Berbelok terlalu tajam (miring)

MCAS akan terus menggerakkan horizontal stabilizer ke atas sebesar 0,27 derajat per detik. Sudut terbesar yang bisa dibuat adalah 2,5 derajat yang membutuhkan waktu 9,26 detik. Sistem ini baru akan non-aktif saat angle of attack mengecil, atau pilot meng-override (mengambil alih kendali) dengan cara manual trim.

Identifikasi Kebutuhan Pada MCAS

Beberapa kebutuhan fungsional untuk MCAS adalah:

• Mampu menurunkan hidung pesawat untuk mencegah stall
• Mampu aktif secara otomatis jika mendeteksi kondisi tertentu
• Mampu dinonaktifkan dan di-override oleh pilot dengan menggunakan manual trim

Sementara kebutuhan non-fungsionalnya adalah:

• Operasi MCAS haruslah stabil dengan critical failure time yang minim
• Fitur dan control MCAS harus dapat dipahami dengan mudah oleh pilot dan dokumentasinya jelas
• MCAS selalu tersedia selama penerbangan pesawat
• MCAS harus sesuai dengan regulasi dari Federal Aviation Administration (FAA)

Permasalahan Pada MCAS

Beberapa permasalahan yang ada pada MCAS adalah:

Tidak ada dokumentasi

Boeing secara sengaja menyembunyikan adanya fitur MCAS untuk mengurangi training pilot. Karena itu, MCAS tidak disebutkan dalam dokumentasi 737 MAX dan pilot maupun teknisi pesawat tidak mengetahui adanya MCAS. Tidak adanya training pilot ini juga menyebabkan ketika terjadi kesalahan pada sistem, pilot tidak dapat mengatasinya dengan tepat.

Desain sistem buruk

Ada beberapa masalah desain pada MCAS. Yang pertama, MCAS hanya dipicu oleh satu sensor AOA tanpa adanya redundansi, padahal pesawat tersebut mempunyai dua sensor. Masalah kedua, meskipun seharusnya MCAS hanya aktif pada situasi yang ekstrem, tapi desainnya menyebabkan MCAS dapat terus aktif meskipun ada kesalahan pada sensor. Sehingga meskipun pilot sudah berusaha menaikkan hidung pesawat, MCAS akan aktif kembali.

Masalah berikutnya, sistem diberikan otoritas yang berlebihan. MCAS dapat menggerakkan horizontal tail dengan kekuatan yang cukup untuk meniadakan perintah menaikkan hidung pesawat oleh pilot. Dan terakhir, Boeing mengasumsikan pilot akan sadar apabila ada kesalahan sistem dan dapat bereaksi dengan waktu yang cukup untuk mematikan sistem. Tapi karena tidak adanya dokumentasi dan pelatihan seperti yang sudah disebutkan sebelumnya, masalah-masalah sebelumnya hanya menimbulkan "single points of failure" pada design sistem.

Kurangnya testing

Analisis dan testing MCAS didelegasikan oleh FAA ke Boeing sendiri. Tetapi beberapa perwakilan resmi FAA yang melakukan penilaian keamanan sistem menyatakan adanya tekanan dari manajer untuk membatasi testing yang dilakukan dan mempersingkat analisis. Sehingga hasil analisis yang diserahkan pada FAA tidak mencantumkan perubahan pada MCAS dan melewatkan kekurangan sistemnya. Beberapa engineer pesawat juga mempertanyakan masalah desain yang ada selama testing, seperti single angle-of-attack sensor failure dan kurangnya waktu reaksi pilot yang diasumsikan, tetapi hal-hal tersebut diabaikan.

Referensi

• https://www.youtube.com/watch?v=wXMO0bhPhCw
• https://en.wikipedia.org/wiki/Maneuvering_Characteristics_Augmentation_System
• https://aviatren.com/2018/11/16/mengenal-mcas-fitur-otomatis-di-737-max-yang-baru-diungkap-boeing-setelah-kecelakaan-lion-air-jt610/
• https://www.seattletimes.com/business/boeing-aerospace/what-led-to-boeings-737-max-crisis-a-qa/

Tugas 2 RK D 2022

Pada tugas ini, saya akan menganalisis sebuah SKPL untuk mendapatkan input-inputnya yang digunakan dalam proses rekayasa kebutuhan. SKPL yang saya gunakan adalah sebagai berikut:

Dari SKPL tersebut, didapatkan input berikut:

1. Existing System Information

Existing System Information adalah penjelasan tentang sistem yang digunakan saat ini dan informasi tentang fungsionalitas yang akan diganti. Di SKPL ini sendiri, sistem yang akan dikembangkan adalah sistem survei untuk pengadilan agama. Sistem survei yang ada sebelumnya masih bersifat konvensional. Responden akan menjawab survei di kertas, kemudian petugas akan mengumpulkan jawaban responden untuk diolah menjadi laporan. Sehingga sangat mungkin terjadi kesalahan saat meng-inputkan data jawaban responden dan proses inputnya sendiri cukup memakan waktu. Karena itu akan dikembangkan apliaksi berbasis website yang akan digunakan responden dan petugas dalam proses penyaluran aspirasi dan penilaian terhadap jasa yang diberikan.

2. Stakeholder Needs

Stakeholder Needs adalah apa yang dibutuhkan oleh semua stakeholder yang harus dipenuhi aplikasi ini. Di aplikasi ini sendiri terdapat 2 stakeholder, yaitu responden dan petugas. Kebutuhannya masing-masing stakeholder adalah:

    1. Responden

        Responden harus dapat mengakses dan menjawab survei kepuasan dengan mudah. Responden juga harus dapat memastikan bahwa jawaban survei dan masukkan mereka telah tersimpan.

    2. Petugas

       Petugas harus bisa memasukkan pertanyaan survei dan nilai harapannya. Petugas juga dapat melihat dan mengelola jawaban survei responden yang telah tersimpan, Selain itu, Petugas dapat membuat dan melihat laporan dan statistik baik tentang jawaban responden maupun data responden sendiri. 

3. Organisational Standards

Organisational Standards adalah standar yang diterapkan suatu organisasi dalam proses pengembangan apliaksi, kualitas aplikasi, dan lain-lain. Beberapa standar yang diterapkan untuk aplikasi survei ini, antara lain:

    - Aplikasi dikembangkan menggunakan PHP

    - DBMS yang digunakan adalah SQL Server 2017

    - Tampilan antarmuka aplikasi terlihat sederhana

    - Aplikasi dapat dijalankan di berbagai sistem operasi menggunakan browser

    - Aplikasi berjalan di server lokal Pengadilan Agama Kediri sehingga hanya bisa diakses di tempat

    - Aplikasi menggunakan Bahasa Indonesia

4. Regulations

Regulations adalah regulasi atau aturan eksternal yang harus diterapkan pada sistem. Contoh aturan yang diterapkan di aplikasi ini, antara lain:

  - Penyusunan survei kepuasan harus sesuai dengan Peraturan Menteri Pendayagunaan Aparatur Negara dan Reformasi Birokrasi

    - Aplikasi menjamin keamanan data personal responden

    - Aplikasi tidak mendiskriminasi responden berdasarkan SARA

5. Domain Information

Domain Information adalah informasi umum tentang domain dari sistem. Pada aplikasi ini, domain sistemnya adalah survei kepuasan. Survei kepuasan ini nantinya akan berisi pertanyaan tentang data diri responden juga penilaian responden terhadap pelayanan jasa Pengadilan Agama Kediri. Jawaban responden dan juga nilai harapan yang dimasukkan petugas kemudian akan diolah menjadi laporan untuk menunjukkan kinerja dari Pengadilan Agama Kediri.

Tugas 1 RK D 2022

 Aplikasi Parkir Non Tunai

1. Deskripsikan aplikasi Parkir 

Aplikasi Parkir Non Tunai ini adalah sekumpulan perangkat Internet of Things (IoT) yang akan memudahkan manajemen dan pengelolaan parkir kendaraan, termasuk pembayaran parkir oleh pengguna. Perangkat ini menggunakan karcis untuk mencatat data parkir yang nantinya akan digunakan di akhir untuk menentukan biaya parkir. Pengguna lahan parkir kemudian dapat membayar biaya tersebut secara non-tunai.

Ketika ada pengguna yang ingin parkir, pengguna akan diarahkan untuk menekan tombol di perangkat yang ada di pintu masuk lahan parkir. Perangkat tersebut akan memberikan karcis yang berisi data parkir pengguna seperti kendaraan dan waktu parkir. Palang kemudian akan terbuka sehingga pengguna bisa masuk lahan parkir. 

Ketika pengguna ingin keluar dari lahan parkir, perangkat yang berada di pintu keluar akan membaca karcis yang telah diberikan di awal tadi. Dari data tersebut, perangkat dapat menentukan biaya parkir pengguna. Pengguna kemudian dapat membayar dengan cara menempelkan kartu ataupun meng-scan kode QRIS. Setelah pembayaran terkonfirmasi, palang akan terbuka sehingga pengguna bisa keluar.

Dengan adanya perangkat ini, lahan parkir tidak lagi memerlukan juru parkir sehingga dapat menekan biaya untuk perusahaan. Selain itu, mengingat kondisi Covid saat ini, interaksi antar manusia juga bisa dikurangi sehingga lebih aman. Pencatatan biaya parkir juga akan terjadi automatis sehingga akan memudahkan pembuatan laporan juga dapat mengurangi pungutan liar. 

2. Identifikasi User dan Stakeholder

User: Masyarakat umum, pengurus lahan parkir

Stakeholder: Pemilik lahan parkir 

3. Tulis/ Gambarkan kebutuhan dari masing-masing user/ stakeholder

Masyarakat:

• Dapat memasuki dan keluar lahan parkir
• Dapat membayar biaya parkir dengan mudah
• Dapat melihat kapasitas lahan parkir

Pengurus:

• Dapat menentukan biaya parkir
• Dapat melihat laporan pendapatan
• Dapat melihat laporan kendaraan yang keluar masuk

Pemilik:

• Dapat menerima pembayaran
• Dapat melihat laporan lahan parkir

4. Tentukan aspek lain yang penting supaya aplikasi berjalan lancar

• Koneksi internet perangkat
• Sumber listrik perangkat
• Kertas karcis terus-menerus diisi
• Kamera dan/atau sensor lainnya untuk mencatat data kendaraan
• Kesediaan lahan parkir
• Keamaan lahan parkir
• Server dan database untuk pencatatan