UJIAN AKHIR SEMESTER GASAL 2020-2021

FAKULTAS TEKNOLOGI INFORMASI

IKPIA PERBANAS JAKARTA/BEKASI*

Mata Ujian : Rekayasa Sistem Informasi

Kode / SKS : TII2005-1N3A / 3 SKS
Program Studi : Sistem Informasi Program Kelas Intensif
Hari / Tanggal : Senin / 19 Oktober 2020
Waktu : 18.30-21.00
Dosen/ No. Reg. : Dr. Hadi Syahrial / 14027
Sifat Ujian : Buka buku

PERHATIAN
1. Seluruh lembar soal ujian dikembalikan kepada Pengawas Ujian.
2. Jawablah soal ujian pada kertas lembar jawaban yang disediakan, atau yang ditentukan.
3. Soal Ujian Terdiri dari 5 nomor.

1. Buatlah sebuah diagram misuse case pada sebuah studi kasus pengembangan Sistem
Informasi (disesuaikan dengan tugas proyek SI).

2. Buatlah Data Flow Diagram (DFD) proses-proses pada sebuah studi kasus pengembangan
Sistem Informasi (disesuaikan dengan tugas proyek SI).

3. Sebutkan dan jelaskan langkah-langkah dalam Business-Oriented Requirement Engineering

(BORE).

4. Jelaskan tujuan melakukan Software Testing dan jelaskan tipe-tipe Acceptance Testing
berikut:
- User Acceptance Testing,
- Operational Acceptance Testing,
- Contractual and Regulatory Acceptance Testing

5. Sebutkan dan jelaskan perbedaan antara Code Review dan Penetration Test.

Verifikasi Soal

Dosen Penyusun Soal Dosen Koordinator

Hadi Syahrial

1
Nama : Abdul Majid Azhar Hamidan
NIM : 1913070023

Jawaban Ujian Akhir Semester

Mata Kuliah Rekayasa Sistem Informasi
1. Buatlah sebuah diagram misuse case pada sebuah studi kasus pengembangan Sistem
Informasi (disesuaikan dengan tugas proyek SI).

Jawaban :

2. Buatlah Data Flow Diagram (DFD) proses-proses pada sebuah studi kasus pengembangan
Sistem Informasi (disesuaikan dengan tugas proyek SI).

Jawaban :
3. Sebutkan dan jelaskan langkah-langkah dalam Business-Oriented Requirement Engineering
(BORE).

Jawaban :

1) As Is Business Process Modelling

Tujuan dari langkah pertama adalah membangun model As-Is, yaitu diagram yang
menunjukkan detail-detail peran yang ada saat ini serta hubungannya. Diagram As-Is
membantu untuk memahami proses bisnis pada organisasi. Untuk membuat diagram
ini, perlu mengumpulkan informasi dalam jumlah yang besar. Hal tersebut dapat
dilakukan melalui metode pengumpulan data yang disebutkan di atas. Kemudian,
meneliti informasi yang diperoleh untuk menentukan dengan tepat peran, hubungan,
dan entitas lain dalam sistem ini sangat diperlukan. Output dari langkah ini adalah
diagram As-Is. Diagram ini harus divalidasi oleh pemangku kepentingan untuk
memastikan bahwa itu benar-benar dapat beradaptasi dengan keadaan saat ini
organisasi. Terkadang, perlu dilakukan beberapa revisi untuk menghasilkan diagram
yang bersifat final.

2) Business Process Improvement

Tujuan dari langkah kedua adalah untuk meningkatkan proses bisnis yang sudah ada
melalui otomatisasi. Proses bisnis terdiri dari beberapa sub-proses. Biaya dan manfaat
penerapan sistem informasi untuk setiap sub-proses harus dihitung berdasarkan beban
kerja dan domain fasilitas untuk menerapkannya. Sub-proses yang hemat biaya
diprioritaskan untuk otomatisasi. Di langkah ini, mengadakan workshop akan
 bermanfaat, karena itu membantu mengumpulkan ide dan mencapai kesepakatan
dengan cepat. Output dari langkah ini adalah draf model To-Be, yang menunjukkan
tujuan umum otomatisasi. Tujuan ideal dari otomasi adalah melakukan semua tugas
secara otomatis, tetapi sebenarnya hampir tidak mungkin di semua proses bisnis.
Beberapa isu seperti disiplin manusia, variabilitas lingkungan, hukum tanggung jawab,
tingkat otoritas, batasan sistem, dan trade-off antara biaya dan manfaat adalah yang
utama hambatan untuk tujuan ini.

3) Functional Requirements Elicitation

Langkah ketiga adalah mendapatkan persyaratan fungsional. Mengadakan workshop
masih merupakan cara yang baik untuk memutuskan requirement. Dalam langkah ini,
model final To-Be models dibangun untuk proses dan diagram use case digambar.
Tidak ada cara yang efektif untuk menggunakan algoritma untuk melakukan
pemerolehan persyaratan fungsional, dan itu sangat tergantung pada pengalaman
desainernya.

4. Jelaskan tujuan melakukan Software Testing dan jelaskan tipe-tipe Acceptance Testing
berikut:
- User Acceptance Testing,
- Operational Acceptance Testing,
- Contractual and Regulatory Acceptance Testing

Jawaban :

Tujuan utama dari pengujian perangkat lunak yaitu untuk memastikan bahwa software yang
dihasilkan sesuai dengan kebutuhan (requirement) yang sebelumnya ditentukan. Sedangkan
manfaatnya adalah sebagai berikut :

1. Menemukan kesalahan (fault) sebanyak mungkin dari perangkat lunak yang diuji
2. Membuat perangkat lunak yang diuji, setelah perbaikan dilakukan, menjadi perangkat
lunak yang berkualitas
3. Melakukan pengujian secara efektif dan efisien
4. Mengumpulkan kesalahan yang terjadi dan menggunakannya untuk tindakan preventif

Tipe-tipe Acceptance Testing

• User Acceptance Testing

Pengujian penerimaan pengguna (UAT) adalah fase terakhir dari proses pengujian
perangkat lunak. Selama UAT, pengguna perangkat lunak yang sebenarnya menguji
perangkat lunak tersebut untuk memastikannya dapat menangani tugas-tugas yang
diperlukan dalam skenario dunia nyata, sesuai dengan spesifikasi. UAT adalah salah satu
prosedur proyek perangkat lunak terakhir dan penting yang harus dilakukan sebelum
perangkat lunak yang baru dikembangkan diluncurkan ke pasar.

Tujuan Pengujian Penerimaan Pengguna adalah untuk menilai apakah sistem dapat
mendukung bisnis sehari-hari dan skenario pengguna dan memastikan sistem memadai
dan benar untuk penggunaan bisnis.

• Operational Acceptance Testing

Digunakan untuk melakukan kesiapan operasional (sebelum rilis) suatu produk, layanan,
atau sistem sebagai bagian dari sistem manajemen mutu. OAT adalah jenis pengujian
perangkat lunak non-fungsional yang umum, digunakan terutama dalam pengembangan
perangkat lunak dan proyek peme liharaan perangkat lunak. Jenis pengujian ini berfokus
 pada kesiapan operasional sistem yang akan didukung, dan / atau menjadi bagian dari
lingkungan produksi. Oleh karena itu, ini juga dikenal sebagai pengujian kesiapan
operasional (ORT) atau kesiapan operasi dan pengujian jaminan (OR&A). Pengujian
fungsional dalam OAT terbatas pada pengujian yang diperlukan untuk memverifikasi
aspek non-fungsional dari sistem.

• Contractual and Regulatory Acceptance Testing

Contractual Acceptance Testing berarti bahwa perangkat lunak yang dikembangkan diuji
terhadap kriteria dan spesifikasi tertentu yang telah ditentukan sebelumnya dan disepakati
dalam kontrak. Tim proyek menentukan kriteria dan spesifikasi yang relevan untuk
diterima pada saat yang sama ketika tim menyetujui kontrak itu sendiri.

Regulation Acceptance Testing, juga dikenal sebagai Compliance Acceptance Testing,

memeriksa apakah perangkat lunak sesuai dengan peraturan. Ini termasuk peraturan
pemerintah dan hukum.

5. Sebutkan dan jelaskan perbedaan antara Code Review dan Penetration Test.

Code Review Penetration Test

Definisi Code Review adalah
pemeriksaan kode sumber
aplikasi untuk menemukan
kesalahan yang terlewatkan
dalam tahap pengembangan
awal. Penguji meluncurkan code
analyzer yang memindai baris
demi baris kode suatu aplikasi.
Setelah penganalisis, yang
ditempatkan di lingkungan
pengujian, menemukan
kerentanan, pentester secara
manual memeriksanya untuk
menghilangkan false positives.
Penetration test adalah prosedur di
mana pentester meretas aplikasi
web untuk mengungkap kerentanan
di aplikasi. Prosesnya lebih
memakan waktu daripada code
review karena ini mencakup
beberapa tahapan. Pertama,
pentester melakukan pengintaian
terhadap aplikasi target melalui
serangkaian tes pengguna dan
menjalankan pemindai web untuk
menemukan titik masuk. Setelah itu,
dia mengeksploitasi kerentanan
yang mencoba meningkatkan hak
istimewa ke tingkat administratif.

Perkiraan Jumlah waktu yang dihabiskan Tergantung pada kompleksitas

Jumlah Waktu penguji untuk tinjauan kode aplikasi web, prosedur dapat
yang sumber bervariasi dengan memakan waktu 20 hingga 400 jam.
Dihabiskan bahasa pemrograman dan
ukuran aplikasi. Misalnya, 1000
baris kode mungkin
memerlukan 0,5 - 2 jam untuk
dianalisis.

Kerentanan Encryption Errors. Ini termasuk Search engine indexing. Mesin

yang diuji algoritma enkripsi yang lemah, pencari lokal dari aplikasi dapat
serta algoritma enkripsi yang mengungkapkan data sensitif
kuat dengan implementasi yang pentester, seperti salinan paspor
lemah (misalnya, penyimpanan atau SIM.
kunci yang tidak aman).
Vulnerabilities caused by
All Cases of SQL Injections, misconfiguration. Ini adalah kasus
 kerentanan XSS (skrip lintas
situs).
Buffer overflows (lebih banyak
data dimasukkan ke buffer
daripada yang bisa ditangani).
Race Conditions (melakukan
dua operasi atau lebih pada
waktu yang sama).
Lainnya Code review memungkinkan
pentester menemukan
kerentanan pada level root
(untuk mendeteksi kesalahan
dalam fungsi atau modul yang
digunakan di beberapa halaman
web).
Code review memeriksa kualitas Penetration Testing, pada gilirannya,
kode aplikasi web.
ketika layanan dan dokumen
internal tersedia melalui internet,
penggunaan kredensial default
seperti "admin" dan "pengguna".
Weak authentication, misalnya,
sandi lemah atau CAPTCHA,
penggunaan ulang sandi.
Logical errors in the role-based
access, ketika informasi tertentu
tersedia untuk lebih banyak
pengguna.
Penetration Testing memungkinkan
melihat halaman web yang rentan,
tapi tidak mampu sampai tingkat
root
mengungkapkan masalah dengan
logika aplikasi web.