QUALITY ASSURANCE

Untuk

Aplikasi Toko Online Berbasis Mobile beserta Sistem Manajemen Data

Barang dan Transaksi Pembelian

Disusun oleh:

Abdul Rahman Saleh 1931710038

Muhammad Fauzan Tri Aji 1931710150

PROGRAM STUDI MANAJEMEN INFORMATIKA

JURUSAN TEKNOLOGI INFORMASI
POLITEKNIK NEGERI MALANG
2021

QUALITY ASSURANCE
 Daftar Isi
1. Tujuan ............................................................................................................................ 1
2. Dokumen Referensi, Definisi dan Akronim................................................................ 1
2.1. Dokumen Referensi ................................................................................................................ 1
2.2. Daftar Istilah ........................................................................................................................... 1
2.3. Akronim dan Singkatan .......................................................................................................... 1
3. Manajemen Proyek ....................................................................................................... 2
3.1. Organisasi Proyek ................................................................................................................... 2
3.2. Metodologi .............................................................................................................................. 2
3.3. Aktivitas dan Task .................................................................................................................. 2
3.4. Tugas dan Tanggung Jawab .................................................................................................... 2
4. Dokumentasi .................................................................................................................. 3
4.1. Dokumen Proyek .................................................................................................................... 3
4.1.1. Statement of Work ............................................................................................................... 3
4.1.2. Project Plan ........................................................................................................................ 3
4.1.3. Project Progress Report...................................................................................................... 4
4.1.4. Individual Progress Report ................................................................................................. 4
4.1.5. Issues Log............................................................................................................................ 4
4.1.6. Project Change Request ...................................................................................................... 4
4.1.7. Deliverable Acceptance Report .......................................................................................... 4
4.2. Functional Specification Document ........................................................................................ 5
4.3. Dokumen Desain Arsitektur.................................................................................................... 5
4.4. Rencana Validasi dan Verifikasi Software ............................................................................. 5
4.5. Laporan Validasi dan Verifikasi Software .............................................................................. 5
4.6. Rencana Manajemen Konfigurasi ........................................................................................... 6
4.7. Dokumentasi Pengguna dan Pengoperasian............................................................................ 6
5. Standar ........................................................................................................................... 6
5.1. Standar Coding........................................................................................................................ 6
5.2. Standar Penamaan Data .......................................................................................................... 7
5.3. Standar Antarmuka Pengguna ................................................................................................. 7
5.4. Standar Format Laporan Statis ................................................................................................ 9
5.5. Standar Alat Bantu Pemrograman........................................................................................... 9
5.6. Standar Dokumentasi .............................................................................................................. 9
5.7. Metriks .................................................................................................................................. 10
5.8. Standar IEEE ......................................................................................................................... 10

QUALITY ASSURANCE i
 5.9. Standar, Kebijakan dan Checklist ......................................................................................... 10
6. Tinjauan dan Audit..................................................................................................... 10
6.1. Tinjauan Deliverables ........................................................................................................... 11
6.1.1. Tinjauan Requrement Software ........................................................................................ 11
6.1.2. Tinjauan Arsitektur Sistem ............................................................................................... 11
6.1.3. Tinjauan Desain Teknis .................................................................................................... 12
6.1.4. Tinjauan Rencana Verifikasi dan Validasi Software ........................................................ 12
6.1.5. Tinjauan Rencana Manajemen Konfigurasi Software ...................................................... 12
6.1.6. Tinjauan Rencana Implementasi ....................................................................................... 12
6.1.7. Tinjauan Rencana Pemeliharaan Setelah Implementasi.................................................... 13
6.2. Tinjauan Manajemen............................................................................................................. 13
7. Testing .......................................................................................................................... 13
7.1. Testing Unit .......................................................................................................................... 13
7.2. Testing Integrasi.................................................................................................................... 14
7.3. Testing Sistem ....................................................................................................................... 14
7.4. Testing Penerimaan Pengguna .............................................................................................. 14
8. Pelaporan Masalah dan Tindakan Koreksi.............................................................. 14
9. Alat Bantu, Teknik dan Metodologi .......................................................................... 14
9.1. Alat Bantu (tools) .................................................................................................................. 14
9.2. Teknik ................................................................................................................................... 14
9.3. Metodologi ............................................................................................................................ 15
9.4. Kontrol Kode Program .......................................................................................................... 16
9.5. Kontrol Media ....................................................................................................................... 16
9.6. Keamanan ............................................................................................................................. 16
9.7. Pemulihan dari Bencana (disaster recovery) ........................................................................ 16
9.8. Kontrol Supplier.................................................................................................................... 16
9.9. Pemgumpulan Catatan, Pemeliharaan dan Retensi ............................................................... 16
10. Pelaporan Masalah dan Tindakan Koreksi.............................................................. 17
10.1. Pelatihan Pengguna Untuk pengguna dapat memahami sistem maka akan ada
pelatihan untuk pengguna , diantaranya :.......................................................................................... 17
11. Pelaporan Masalah dan Tindakan Koreksi.............................................................. 17
11.1. Penilaian Diri Proyek ........................................................................................................ 17
11.2. Rencana Penilaian dan Manajemen Risiko ....................................................................... 17
11.3. Proses Tinjauan dan Manajemen Risiko ........................................................................... 18
11.4. Alat Bantu (tools) .............................................................................................................. 19
12. Hal yang Dipelajari ..................................................................................................... 19

QUALITY ASSURANCE ii
13. Persetujuan Dokumen ................................................................................................ 20
Lampiran 1: Aktifitas dan Task ........................................................................................................ 21
Lampiran 2: Laporan Hasil Audit ..................................................................................................... 22
Lampiran 3: Lembar Persetujuan Dokumen ..................................................................................... 23

QUALITY ASSURANCE iii

 DAFTAR TABEL

Tabel 1 Daftar Istilah .............................................................................................................................. 1

Tabel 2 Akronim dan Singkatan ............................................................................................................. 1
Tabel 3 Wewenang dan Tanggungjawab ................................................................................................ 2
Tabel 4 Project Progress Report.............................................................................................................. 4
Tabel 5 Project Change Request ............................................................................................................. 4
Tabel 6 Kebutuhan Software ................................................................................................................ 11
Tabel 7 Penilaian Diri Proyek ............................................................................................................... 17
Tabel 8 Rencana Penilaian dan Manajemen Risiko .............................................................................. 17
Tabel 9 Proses Tinjauan dan Manajemen Risiko .................................................................................. 18

QUALITY ASSURANCE iv
 DAFTAR GAMBAR
Gambar 1 Organisasi Proyek .................................................................................................................. 2
Gambar 2 Arsitektur sistem .................................................................................................................. 11
Gambar 3 Metodologi QA .................................................................................................................... 15

QUALITY ASSURANCE v
1. Tujuan
Tujuan diadakannya perencanaan kualitas software sebagai strategi pembuatan proyek untuk
klien yang deliverable. perencanaan software ini bertujuan untuk memperbaharui sistem pengolahan
data secara manual menjadi terkomputerisasi dan dapat memudahkan segala proses transaksi,
memberikan pelayanan terbaik dengan menyediakan katalog untuk customer berdasarkan aplikasi
serta proses pembelian yang tidak begitu rumit, sehingga dapat menarik calon pembeli yang lebih
banyak dari sebelumnya. , proses untuk mencapai kualitas yang diinginkan proyek ini menggunakan
metode SDLC yang akan memudahkan dalam mengidentifikasi masalah dan merancang system
sesuai kebutuhan dalam menyelesaikan permasalahan tersebut.

2. Dokumen Referensi, Definisi dan Akronim

2.1. Dokumen Referensi
• Fattah, N.T. (2013). Quality Assurance.
https://id.scribd.com/document/175353099/Quality-assurance
• Pressman, R.S. (2015). Software Engineering : A Practioner’s Approach. 8th ed.
McGraw-Hill Companies.Inc, Americas, New York. ISBN : 978 1 259 253157.
• Sommerville, I. (2018). Software Engineering. Hallbergmoos/Germany: Pearson.
• https://www.altexsoft.com/whitepapers/quality-assurance-quality-control-and-testing-
the-basics-of-software-quality-management/
• https://www.educba.com/software-quality-assurance/
2.2. Daftar Istilah
Tabel 1 Daftar Istilah
No Istilah Arti
1 Repository Direktori penyimpanan file proyek pada github
2 Deliverable pemenuhan permintaan klien secara keseluruhan atau
bagian-bagian kecil dari pemenuhan proyek
3 Virtual komunikasi secara daring atau maya yang dihubungkan
oleh jaringan dengan lawan bicara

2.3. Akronim dan Singkatan

Tabel 2 Akronim dan Singkatan
No Akronim dan Singkatan Arti
1 SOP Standard Operating Procedure
2 QA Quality Assurance
3 ISVV Verifikasi dan Validasi Perangkat Lunak Independen
4 UI User Interface

QUALITY ASSURANCE 1
3. Manajemen Proyek
3.1. Organisasi Proyek

Gambar 1 Organisasi Proyek

3.2. Metodologi
Pengembangan aplikasi menggunakan pendekatan dengan Metode waterfall yang melalui
tahap-tahap berikut.
1. Analisis kebutuhan
2. Desain system
3. Koding dan unit testing
4. Pengujian system
5. Implementasi dan maintenance jika diperlukan.

3.3. Aktivitas dan Task

(Lampiran 1: aktifitas dan task)

3.4. Tugas dan Tanggung Jawab

Dalam merancang Perancangan Aplikasi Toko Online dan Manajemen Data Transaksi
Penjualan Berbasis Mobile, ada wewenang dan tanggung jawab tiap posisi dari tim sebagai
pelaksana proyek, sebagai berikut:
Tabel 3 Wewenang dan Tanggungjawab
Nama Jabatan Tugas dan Wewenang
Cetya Chairunisa Razaki Pemilik Proyek 1. Mengambil Keputusan terakhir
yang berhubungan dengan
pembangunan proyek
2. Menyetujui atau menolak
permintaan tentang proyek.

QUALITY ASSURANCE 2
 3. Menandatangani surat perjanjian
kontrak.
4. Memberikan semua instruksi
kepada Tim Pelaksana Proyek
Muhammad Fauzan Tri Programmer (Ketua) 1. Mengoordinir jalanya proyek
Aji 2. Menulis, mengupdate, menguji,
dan memelihara program
komputer atau paket perangkat
lunak untuk menangani pekerjaan
tertentu.
3. Bertanggung jawab kepada
Pemilik Proyek
Abdul Rahman Saleh Programmer 1. Menulis, mengupdate ,menguji,
dan memelihara program
komputer atau paket perangkat
lunak untuk menangani pekerjaan
tertentu
2. Bertanggung jawab kepada
Pemilik Proyek

4. Dokumentasi
4.1. Dokumen Proyek
• Dokumentasi pengembangan aplikasi berupa repository dari github yang berisi kode
program aplikasi dan catatan progress yang dikerjakan.
• Dokumentasi untuk pengguna yang akan disertakan bersama hasil aplikasi berupa User Guide
(Panduan Pengguna) yang berisikan panduan praktis pengoperasian aplikasi yang dilengkapi
dengan screenshots untuk memudahkan user dalam memahami cara pengoperasian aplikasi ini.

4.1.1. Statement of Work

Pada proyek ini pelaporan kerja yang kami laporkan secara progress commit pada
repository dari suatu platform web aplikasi yaitu github , commit dari tiap programmer
akan tercatat pada platform web aplikasi tersebut

4.1.2. Project Plan

Project Plan proyek ini meliputi pencapaian target , penilaian risiko , alokasi sumber
daya , jadwal proyek dan milestone serta tujuan dan sasaran sudah dijelaskan pada
dokumen Functional Specification Document (FSD)

QUALITY ASSURANCE 3
4.1.3. Project Progress Report
Dokumentasi Project Progress Report terdapat pada repository dari suatu platform web
aplikasi yaitu github yang kami gunakan untuk melakukan progress perancangan
proyek dari awal hingga terbentuk hasil berupa aplikasi yang nantinya akan
diimplementasikan ke klien tercatat semua pada link github disini :
Tabel 4 Project Progress Report
Bagian Aplikasi Link
Admin https://github.com/elrahmaan/laravel-admin-
onlineshop
User https://github.com/zanynn/flutter-onlineshop

4.1.4. Individual Progress Report

Individual progress report pada proyek ini tercatat commit yang dilakukan tiap
programmer ke repository dari suatu platform web aplikasi github yang kami
gunakan. Link sudah terlampir pada sub bab 4.1.3 Project Progress Report

4.1.5. Issues Log

Tidak ada issue log yang kami lampirkan

4.1.6. Project Change Request

Sesuai dengan permintaan dari klien kami pada proyek ini ada perubahan yang
diinginkan klien :
Tabel 5 Project Change Request
Permintaan klien Implementasi
Perubahan banner yang ditampilkan
Sudah Terimplementasi
pada home (user)
Penambahan sisa produk pada halaman
Sudah Terimplementasi
detail produk (user)
Penambahan logika quatitas barang
Sudah terimplementasi
yang disorder melebihi sisa stok

4.1.7. Deliverable Acceptance Report

Dari penyampaian implementasi program yang telah dilakukan membuktikan bahwa
sistem dibuat berdasarkan kebutuhan – kebutuhan dari klien dari setiap fitur yang
terdapat pada sistem berfungsi dengan baik dan sudah sesuai prosedur perancangan
sistem namun ada sedikit saran dari audit guna untuk menyempurnakan sistem yang
dibangun , saran tersebut sudah terimplementasikan pada sistem ini.

QUALITY ASSURANCE 4
4.2. Functional Specification Document
Pada Proyek ini dokumen FSD (Functional Software Document) adalah dokumen yang
dirancang untuk memberikan gambaran umum tentang bagaimana sistem toko online dan
juga dokumen tersebut memberikan garis besar langkah-demi-langkah yang mendetail tentang
fungsionalitas dan alur setiap item.

4.3. Dokumen Desain Arsitektur

Proyek ini secara teknis arsitektur admin mengakses aplikasi melalui perangkat PC/Laptop
dimana aplikasi dikembangkan melalui barisan kode program dari framework Laravel. Pembeli
mengakses aplikasi melalui perangkat Mobile smartphone(android) dimana aplikasi
dikembangkan melalui barisan kode program dari framework Flutter. Sistem melakukan
pertukaran data dengan memanfaatkan Rest API yang telah dibuat melalui operasi POST, GET,
PUT, dan DELETE yang kemudian setiap perubahan dan penyimpanan data akan disimpan
melalui database baik itu secara lokal ataupun global (jika dilakukan hosting).

4.4. Rencana Validasi dan Verifikasi Software

Proyek ini menggunakan metode ISVV adalah ( Verifikasi dan Validasi Perangkat Lunak
Independen ). ISVV ditargetkan untuk keselamatan kritis perangkat lunak sistem dan bertujuan
untuk meningkatkan kualitas produk perangkat lunak, sehingga mengurangi risiko dan biaya
selama masa operasional perangkat lunak. ISVV memberikan jaminan bahwa perangkat lunak
bekerja pada tingkat kepercayaan yang ditentukan dan dalam parameter yang dirancang dan
persyaratan yang ditentukan.
Kegiatan ISVV dilakukan oleh tim teknik independen, tidak terlibat dalam proses
pengembangan perangkat lunak, untuk menilai proses dan produk yang dihasilkan.
Independensi tim ISVV dilakukan pada tiga tingkatan yang berbeda: keuangan, manajerial dan
teknis.
ISVV jauh melampaui verifikasi "tradisional" dan teknik validasi, yang diterapkan oleh tim
pengembangan. Sementara tujuan terakhir untuk memastikan bahwa perangkat lunak bekerja
dengan baik terhadap persyaratan nominal, ISVV difokuskan pada persyaratan non-fungsional
seperti ketahanan dan keandalan, dan pada kondisi yang dapat menyebabkan perangkat lunak
gagal. Hasil dan temuan ISVV diumpankan kembali ke tim pengembangan untuk koreksi dan
peningkatan.

4.5. Laporan Validasi dan Verifikasi Software

Verifikasi dan validasi yang telah dilakukan membuktikan bahwa sistem dibuat berdasarkan
kebutuhan – kebutuhan dari klien dari setiap fitur yang terdapat pada sistem berfungsi dengan
baik dan sudah sesuai prosedur perancangan sistem.

QUALITY ASSURANCE 5
 4.6. Rencana Manajemen Konfigurasi
Dalam pelaksanaan proyek semua hal yang terkait dapat dikatakan sebagai item konfigurasi.
Semua item konfigurasi harus dikelola sebaik mungkin untuk menciptakan efisiensi dan
efektivitas dalam pembangunan perangkat lunak. Item konfigurasi dan file-file dokumentasi
akan dibuat dengan penamaan sesuai dengan standart dan berdasarkan versinya. Penentuan
versi berdasarkan urutan hasil perubahan atau evaluasi dari setiap dokumen yang telah
dibentuk. Penamaan dari item konfigurasi dan file-file dokumentasi akan disesuaikan dengan
dokumen SRS (Software Requirement Spesification).

4.7. Dokumentasi Pengguna dan Pengoperasian

Dokumentasi Pengguna dan pengoperasian yang bertujuan untuk memberikan bantuan
penggunaan dalam pemahaman system untuk sisi admin diantaranya pengoperasian dalam
CRUD kategori barang dan produk, merubah status pembelian produk dari customer, dan
memanage user admin.

5. Standar
5.1. Standar Coding
Beberapa standar pengkodean yang digunakan pada proyek ini:
1. Penggunaan global secara terbatas:
Aturan ini memberi tahu tentang jenis data mana yang dapat dideklarasikan secara global.
2. Header standar untuk modul yang berbeda:
Untuk pemahaman dan pemeliharaan kode yang lebih baik, header modul yang berbeda
harus mengikuti beberapa format dan informasi standar. Format header harus berisi hal-
hal di bawah ini yang digunakan di berbagai perusahaan:
Nama modul
• Tanggal pembuatan modul
• Penulis modul
• Riwayat modifikasi
• Sinopsis modul tentang apa yang dilakukan modul
• Fungsi berbeda yang didukung dalam modul bersama dengan parameter input
outputnya
• Variabel global diakses atau dimodifikasi oleh modul
3. Konvensi penamaan untuk variabel lokal, variabel global, konstanta dan fungsi:
Beberapa konvensi penamaan diberikan di bawah ini:
• Nama variabel yang bermakna dan dapat dipahami membantu siapa saja untuk
memahami alasan menggunakannya.
• Variabel lokal harus diberi nama menggunakan huruf huruf kapital dimulai dengan
huruf kecil (misalnya localData ) sedangkan nama variabel Global harus dimulai

QUALITY ASSURANCE 6
 dengan huruf kapital (misalnya GlobalData ). Nama konstanta harus dibentuk
dengan menggunakan huruf kapital saja (misalnya CONSDATA).
• Sebaiknya hindari penggunaan angka dalam nama variabel.
• Nama-nama fungsi harus ditulis dalam camel case dimulai dengan huruf kecil.
• Nama fungsi harus menjelaskan alasan penggunaan fungsi secara jelas dan singkat.
4. Indentasi
Indentasi yang tepat sangat penting untuk meningkatkan keterbacaan kode. Untuk membuat
kode dapat dibaca, programmer harus menggunakan spasi putih dengan benar. Beberapa
konvensi spasi diberikan di bawah ini:
• Harus ada spasi setelah memberikan koma di antara dua argumen fungsi.
• Setiap blok bersarang harus diberi indentasi dan spasi yang benar.
• Indentasi yang tepat harus ada di awal dan di akhir setiap blok dalam program.
• Semua kurung kurawal harus dimulai dari baris baru dan kode setelah akhir kurung
kurawal juga dimulai dari baris baru.
5. Nilai pengembalian kesalahan dan konvensi penanganan pengecualian:
Semua fungsi yang mengalami kondisi kesalahan harus mengembalikan 0 atau 1 untuk
menyederhanakan proses debug. Di sisi lain, pedoman pengkodean memberikan beberapa
saran umum mengenai gaya pengkodean yang harus diikuti untuk peningkatan pemahaman
dan keterbacaan kode.

5.2. Standar Penamaan Data

1. Gunakan huruf kecil dan jangan pernah pakai spasi.
2. gunakan kata benda atau nama proyek tambahkan db dibelakang, contoh kampusdb.
3. jika database terdiri dari dua suku kata gunakan garis bawah, contoh transaksi_detail.
4. Jangan gunakan kata tercadang seperti “select, create, insert” dsb

5.3. Standar Antarmuka Pengguna

Standar Antarmuka pengguna pada proyek ini meliputi :
1. Tema
Tema adalah hal-hal yang mampu memberikan kesan tertentu terhadap suatu halaman
web. Tema yang dicakup dalam standar antarmuka ini meliputi tiga komponen, antara
lain warna, visual style, dan jenis font. Prinsip utama pemilihan warna untuk halaman
web adalah mengatur warna yang kontras antara warna dasar dengan warna teks
sehingga teks mudah dibaca. Warna yang kontras adalah warna yang memiliki
perbedaan komponen brighness yang signifikan seandainya warna tersebut diukur
dengan metode HSB (Hue-Saturation-Brightness). Warna-warna yang memiliki nilai
brighness dibawah 50% akan tampak lebih gelap daripada warna-warna dengan
brighness lebih dari 50% (warna terang).

QUALITY ASSURANCE 7
Berdasarkan prinsip dasar pemilihan warna tersebut, hanya ada dua pilihan komposisi
warna, yaitu:

• Warna dasar terang, warna permukaan (foreground, teks) gelap.

• Warna dasar gelap, warna permukaan terang.
Dengan pertimbangan estetika, maka pilihan pertama lebih tepat untuk dipakai di
lingkungan akademik. Pengguna halaman web lebih mengenal pilihan kedua untuk
situs-situs hacker, para seniman, situs-situs ‘bawah tanah’, dan sebagainya.

Termasuk didalam pemilihan warna disini adalah pemilihan warna untuk link dan
menu. Link dan menu harus memiliki warna yang berbeda dengan teks normal,
sehingga pengunjung mengenali bahwa itu adalah link ataupun menu.

Visual style adalah gaya tampilan bentuk-bentuk bidang yang terdapat pada window
aplikasi atau halaman web, misalnya bentuk button, bentuk menu, logo/gambar, grid
pada tabel dan sebagainya. Tidak ada aturan khusus dalam pembuatan visual style ini,
yang penting indah, sederhana, sesuai dengan konteks halaman, dan tidak
membingungkan pengunjung halaman web. Hal yang harus diperhatikan adalah
penggunaan gambar. Penggunaan gambar sebaiknya tidak terlalu banyak atau
menggunakan file berukuran besar sehingga memakan waktu lama untuk proses
loading. Batas maksimum untuk loading adalah sepuluh detik (dengan kecepatan rata-
rata 28,8 Kbps Modem). Lebih dari itu, halaman web harus dirancang ulang.

Komponen tema yang ketiga adalah jenis font. Berdasarkan pengamatan, kebanyakan
halaman web di dunia tidak menggunakan jenis font yang ‘berekor’. Jenis font yang
berekor, misalnya times new roman, memang mudah dibaca, tapi kurang indah dilihat
pada halaman web. Tulisan berekor dalam halaman web terlihat kaku, dan pengunjung
akan merasa seperti sedang membaca dokumen resmi. Dengan alasan tersebut, standar
antarmuka yang dibuat ini menyarankan untuk tidak menggunakan font berekor. Hal
ini tentu tidak bersifat mutlak. Misalnya, untuk halaman yang memang ditujukan untuk
menghasilkan dokumen resmi, boleh digunakan jenis font times new roman. Contoh
halaman web seperti ini adalah halaman pembangkit dokumen PDF.

Jenis font yang tidak berekor sangat beragam sehingga pemilihan font membuka
peluang untuk mengembangkan imajinasi dan kreativitas perancang. Akan tetapi, satu
hal yang perlu diperhatikan yaitu keterbatasan jenis font yang tersedia pada komputer
client (browser). Pemilihan font harus memperhatikan jenis-jenis font yang dimiliki
oleh komputer client, karena jika font yang didefinisikan pada halaman web tidak
dimiliki oleh komputer client, maka browser akan mengganti font tersebut dengan font
default. Font default ini pada beberapa browser adalah jenis font yang berekor. Untuk
menghindari hal tersebut, dalam standar ini disarankan untuk menggunakan beberapa
jenis font sekaligus yang didefinisikan pada file CSS dengan urutan Verdana, Arial,

QUALITY ASSURANCE 8
 Helvetica, kemudian Tahoma. Jenis-jenis font tersebut dipilih karena salah satu atau
ketiga jenis font tersebut sudah terinstaasi secara default pada mesin dengan OS Linux
Red Hat 7.3 atau yang lebih baru, dan juga pada Windows 98/ Me/ NT/ 2000/ XP.
2. Bahasa
Bahasa memegang peranan yang penting dalam perancangan antarmuka halaman web
karena bahasa adalah media untuk saling berdialog dan berinteraksi. Pemilihan bahasa
yang kurang tepat dapat menyebabkan salah persepsi sehingga berpengaruh negatif
terhadap perilaku pengguna. Yang dimaksud pengaruh negatif disini adalah pengaruh
yang menyebabkan perilaku pengguna tidak sesuai dengan yang diharapkan oleh
aplikasi.
3. Tata Letak
Tata letak sebenarnya adalah bagian dari kreatifitas perancang. Akan tetapi, dalam
situasi tertentu, tata letak perlu distandarkan untuk memberikan lingkungan kerja yang
konsisten bagi pengguna. Dapat dibayangkan apabila pengguna menghadapi tata letak
halaman yang sangat beraneka ragam dalam satu aplikasi. Hal ini tentu akan
membingungkan, atau paling tidak, menguras lebih banyak waktu pengguna untuk
melakukan penyesuaian.

5.4. Standar Format Laporan Statis

Melaporkan kepada owner kondisi dan kemajuan proyek dari waktu ke waktu sehingga pihak
owner dapat melakukan monitoring pekerjaan yang dikerjakan oleh kontraktor. Menjadi salah
satu syarat administrasi untuk pengajuan termin kepada owner. Sebagai bahan evaluasi bagi
internal kontraktor pelaksana terhadarp progress yang telah dicapai tiap minggu atau tiap
bulannya. Menjadi indikator penting untuk mengawasi setiap aktifitas dan biaya yang sedang
dan telah dikeluarkan sesuai dengan item pekerjaan yang telah dikerjakan.

5.5. Standar Alat Bantu Pemrograman

Alat bantu pemrograman yang digunakan pada proyek ini yaitu aplikasi Bahasa pemrograman
php dan dart. php adalah bahasa skrip dengan fungsi umum yang terutama digunakan untuk
pengembangan web. Bahasa ini awalnya dibuat oleh pemrogram Denmark-Kanada Rasmus
Lerdorf pada tahun 1994. Implementasi referensi PHP sekarang diproduksi oleh The PHP
Group. Sedangkan Dart merupakan bahasa pemrograman yang dikembangkan oleh google
untukkebutuhan dalam membuat aplikasi android atau mobile, front-end, web, IoT, back-end
(CLI), dan Game.

5.6. Standar Dokumentasi

Dokumentasi adalah suatu hal yang pertama-tama harus ditentukan dan diselesaikan. Hal yang
penting agar dokumentasi dapat disusun dengan sukses adalah dilakukan dengan cara
mengintegrasikan dokumentasi ini dengan metodologi sehingga proses dokumentasi dilakukan

QUALITY ASSURANCE 9
 ketika setiap langkah development dilakukan, daripada melakukannya setelah selesai. Bentuk
dasar dari dokumentasi ini sebaiknya juga dilakukan untuk proyek-proyek yang lainnya. Pada
suatu proyek biasanya terdapat 6 proses yang saling terkait dan dinamis. Proses ini adalah:
• Pendefinisian
• Perencanaan
• Organisasi
• Pengawasan
• Penyelesaian
• Leading

5.7. Metriks
Bagaimana mengukur matrik Penanggung jawab Waktu penyelesaian Untuk setiap tahapan
dalam proyek, catat waktu atau tanggal mulai tahapan sejak awal permulaan aktivitas
dikerjakan. Pimpinan Proyek & pekerja yang bertanggung jawab pada setiap tahapan. Mulai
proyek Dihitung pada akhir bagian. Pimpinan proyek Selesai proyek Dihitung pada akhir
bagian. Pimpinan proyek Persentase milestone yang telah dicapai Berapa persen milestone
yang tercapai dari 1⁄4 waktu pelaksanaan proyek Pimpinan proyek Kesuksesan (penyelesaian)
persen Pada akhir bagian, berapa persen pekerjaan yang berakhir secara normal dibandingkan
dengan pekerjaan yang selesai tertunda atau sengaja dihentikan. Pimpinan Proyek & pekerja
yang bertanggung jawab pada setiap tahapan.

5.8. Standar IEEE

Standar yang menentukan seperangkat bentuk dokumen pengujian perangkat lunak. Setiap
tahap pengetesan bisa jadi memiliki jenis dokumen yang berbeda. Dengan adanya standar ini,
bisa ditentukan format dokumen yang akan digunakan.

5.9. Standar, Kebijakan dan Checklist

Standard Operating Procedure atau lebih dikenal dengan akronimnya, SOP. Untuk memastikan
sistem kerja berjalan sebagaimana mestinya, SOP digunakan sebagai acuan bagaimana seorang
karyawan harus menyelesaikan tugasnya langkah demi langkah. SOP merupakan salah satu
cara untuk membuat bisnis Anda dapat melayani pelanggan secara konsisten di cabang mana
pun. Untuk memastikan bahwa proyek ini telah melakukan dengan benar sesuai SOP maka
proyek ini menggunakan checklist yang merupakan salah satu cara terbaik untuk mencegah
terjadinya kesalahan operasional.

6. Tinjauan dan Audit

Tujuan diadakan proyek ini yaitu agar produk dari proyek dapat digunakan untuk meringankan
pekerjaan penjual dan pembeli, membantu penjualan dan meningkatkan profit penjualan, menangani

QUALITY ASSURANCE 10
proses penjualan dimana akan terjadi sebuah proses perhitungan total barang jika barang yang
diorder lebih dari satu barang dan juga memberikan bukti pembelian kepada customer (pembeli).

6.1. Tinjauan Deliverables

6.1.1. Tinjauan Requrement Software
1. Kebutuhan hardware yang digunakan dalam proses pengembangan aplikasi:
• Laptop / PC yang kompatibel
• Keyboard
• Mouse
• Smartphone android untuk media deploy
• Wifi/modem atau perangkat lainnya yang dapat menghubungkan koneksi
internet
2. Kebutuhan software yang digunakan dalam proses pengembangan aplikasi:
Tabel 6 Kebutuhan Software
Jenis Perangkat Lunak Yang Digunakan
Sistem Operasi Windows
Bahasa Pemrograman dart, yaml, xml
Framework Flutter
Text Editor Visual Studio Code
Database server Cloud firestore
Authentication server Firebase Authentication

6.1.2. Tinjauan Arsitektur Sistem

Gambar 2 Arsitektur sistem

Keterangan:
1. Admin mengakses aplikasi melalui perangkat PC/Laptop dimana aplikasi
dikembangkan melalui barisan kode program dari framework Laravel.
2. Pembeli mengakses aplikasi melalui perangkat Mobile smartphone(android)
dimana aplikasi dikembangkan melalui barisan kode program dari framework
Flutter.

QUALITY ASSURANCE 11
 3. Sistem melakukan pertukaran data dengan memanfaatkan Rest API yang telah
dibuat melalui operasi POST, GET, PUT, dan DELETE yang kemudian setiap
perubahan dan penyimpanan data akan disimpan melalui database baik itu secara
lokal ataupun global (jika dilakukan hosting).

6.1.3. Tinjauan Desain Teknis

Aplikasi yang akan dibangun menggunakan untuk 2 jenis pengguna yaitu admin dan
pembeli dimana masing-masing aplikasi memiliki jenis tampilan diantaranya:
1. Admin
Aplikasi berbasis website sehingga interface yang akan dibangun menggunakan
konsep web-based yang lebih relevan digunakan melalui browser pada perangkat
Laptop/PC.
2. Pembeli
Aplikasi berbasis android sehingga interface disesuaikan khusus untuk perangkat
mobile (bersistem operasi android).

6.1.4. Tinjauan Rencana Verifikasi dan Validasi Software

Pengujian Verifikasi dan validasi software menggunakan pengujian yang dilakukan
menggunakan black box testing dengan 2 teknik analisis pengujian yaitu Teknik alpha
dan Teknik beta. Hasil analisis pengujian alpha menyatakan bahwa perangkat lunak
bebas dari kesalahan sintaks dan secara fungsional mengeluarkan hasil yang sesuai
dengan yang diharapkan. Sedangkan hasil dari analisis pengujian beta menyatakan
setuju

6.1.5. Tinjauan Rencana Manajemen Konfigurasi Software

Dalam pelaksanaan proyek semua item konfigurasi dikelola dengan baik untuk
menciptakan efisiensi dan efektivitas dalam pembangunan perangkat lunak. Item
konfigurasi dan file-file dokumentasi telah dibuat dengan penamaan sesuai dengan
standart dan berdasarkan versinya. Penamaan dari item konfigurasi dan file-file
dokumentasi telah sesuai dengan dokumen SRS (Software Requirement Spesification).

6.1.6. Tinjauan Rencana Implementasi

Rencana implementasi dilakukan dengan dasar kegiatan yang telah direncanakan
dalam rencana implementasi diantaranya :

1. Pemrograman
Pemograman merupakan tahap implementasi dimana
dilakukannya pengkodean berdasarkan hasil perancangan perangkat
lunak yang telah dibuat sehingga berbentuk sistem baru yang

QUALITY ASSURANCE 12
 sedemikian rupa seperti yang telah direncanakan. Pengkodean ini
dilakukan dentan menggunakan bahasa pemograman Dart dan PHP sedangkan
database yang digunakan adalah Mysql dan Google Firestore.
2. Pengetesan Program
Sebelum program diterapkan, maka program harus bebasterlebih dahulu dari
kesalahan-kesalahan. Untuk itu program harusditest terlebih dahulu untuk
menemukan kesalahan-kesalahan yang mungkin terjadi. Program ditest untuk tiap-
tiap modul dandilanjutkan dengan pengetesan untuk semua modul yang
telahdirangkai. Pengetesan program dilakukan bersamaan pada saatpembuatan
program, yaitu dengan pengentrian, pengeditan,penghapusan data.
3. Instalasi
Sistem ini berbasis website untuk user admin dan mobile . langkah pertama untuk
user admin dalam instalasi adalah developer melakukan web hosting sesuai yang
diinginkan oleh pemilik proyek , sedangkan sisi user customer melakukan instalasi
aplikasi toko kita pada perangkat mobile.

6.1.7. Tinjauan Rencana Pemeliharaan Setelah Implementasi

Setelah semua langkah-langkah Rencana impelemasi , maka rencana pemeliharaan
setelah implementasi sebagai berikut :
1. Pengetesan penerimaan sistem. Pengetesan ini dilakukan dengan menggunakan
data sesungguhnya dalam waktu tertentu yang dilakukan oleh analis sistem
bersama-sama dengan user.
2. Perawatan Sistem. Perawatan ini dilakukan setiap bulan untuk memeriksa system
yang ada terjadi masalah atau tidak. Hal ini untuk menjaga kestabilan sistem

6.2. Tinjauan Manajemen

Peranan auditor bekerja untuk mengaudit berbagai macam laporan yang ada kaitannya pada
keuangan yang harus kompeten dan independen .Jadwal pelaksanaan akan dilakukan saat
penyampaian implemetasi yang dilakukan oleh developer. Focus audit akan mengecek
penerapan pada system ini dan akan melakukan pengawasan pelanggaran-pelanggaran yang
terjadi. Laporan hasil audit terdapat pada (Lampiran 2: Laporan Hasil Audit)

7. Testing
7.1. Testing Unit
Tingkat pengujian ini ditujukan untuk memeriksa setiap unit sistem perangkat lunak untuk
memastikan bahwa itu memenuhi persyaratan dan fungsi asli seperti yang diharapkan.
Pengujian unit dilakukan di awal proses pengembangan oleh para developer sendiri.

QUALITY ASSURANCE 13
 7.2. Testing Integrasi
Tujuan dari tingkat pengujian ini adalah untuk memverifikasi apakah sistem front-end dan
back-end bekerja dengan baik. Pengujian integrasi ini bertujuan untuk mendeteksi kelemahan
dalam interaksi antar unit dalam sebuah fitur/sistem. Dalam pengembangan ini menggunakan
Metode top-down dimana berfokus pada kombinasi tingkat tinggi terlebih dahulu dan
memeriksa yang sederhana kemudian.

7.3. Testing Sistem

Pada pengujian ini sistem perangkat lunak lengkap diuji secara keseluruhan. Tahap ini
berfungsi untuk memverifikasi kepatuhan produk dengan persyaratan fungsional dan teknis
dan standar kualitas secara keseluruhan.

7.4. Testing Penerimaan Pengguna

Tahap pengujian ini merupakan tahap terakhir dari proses pengujian dimana produk
divalidasi terhadap persyaratan pengguna akhir dan untuk akurasi. Langkah terakhir ini
membantu tim memutuskan apakah produk siap dikirim atau tidak. Tingkat pengujian ini
berfokus pada kualitas sistem secara keseluruhan, mulai dari konten dan UI hingga masalah
kinerja. Tahap penerimaan mungkin diikuti oleh pengujian alfa dan beta, yang
memungkinkan sejumlah kecil pengguna sebenarnya untuk mencoba perangkat lunak
sebelum dirilis secara resmi.

8. Pelaporan Masalah dan Tindakan Koreksi

Prosedur yang dilalui dalam melakukan pelaporan , penelusuran , dan menyelesaikan masalah
adalah melakukan perundingan secara team programmer , namun jika masih diluar kendali maka
akan melakukan menyampaian secara virtual dengan pemilik proyek. Kedua anggota team
bertanggung jawab bertanggung jawab terhadap temuan-temuan yang didapatkan dari proses audit
yang telah dilakukan.

9. Alat Bantu, Teknik dan Metodologi

9.1. Alat Bantu (tools)
QA Tools yang digunakan pada aplikasi ini antara lain:
1. Flowchart
2. Gantt chart

9.2. Teknik
Beberapa teknik yang digunakan pada Software Quality Assurance dalam proyek aplikasi ini
diantaranya:

1. Reviewing

QUALITY ASSURANCE 14
 Dalam peninjauan, pertemuan diadakan oleh pemangku kepentingan internal dan eksternal
untuk meninjau keseluruhan proyek yang menganalisis keseluruhan perangkat lunak.
Tujuan utamanya adalah untuk mengukur kualitas perangkat lunak dan memastikan apakah
itu memenuhi harapan pelanggan atau tidak.
2. Auditing
Dengan teknik Auditing, seluruh produk pekerjaan dan semua data diperiksa oleh
pemangku kepentingan untuk memeriksa apakah mengikuti proses standar atau tidak.
3. Functional Testing
Dalam pengujian fungsional, fungsionalitas dari keseluruhan perangkat lunak diuji apakah
berfungsi seperti yang diharapkan atau tidak.
4. Standardization
Ini memastikan bahwa semua yang ada di perangkat lunak harus distandarisasi, yaitu
mengikuti semua standar baik standar dalam dokumentasi, pengembangan, kontrol
kualitas. Ini mengurangi ambiguitas dan karenanya meningkatkan kualitas perangkat lunak
5. Code Inspection
Inspeksi Kode adalah salah satu jenis tinjauan paling formal dengan tujuan utama
menemukan cacat dalam kode program dan menyoroti masalah apa pun.

9.3. Metodologi
Metodologi Quality Assurance memiliki siklus tertentu yang disebut siklus PDCA atau siklus
Deming. Fase-fase dari siklus ini adalah

Gambar 3 Metodologi QA
1. Plan - tim pengembang merencanakan dan menetapkan tujuan terkait proses dan
menentukan proses yang diperlukan untuk menghasilkan produk akhir yang berkualitas
tinggi.
2. Do - Pengembangan dan pengujian Proses serta juga "Do" (melakukan) perubahan dalam
proses.
3. Check - Memantau proses, memodifikasi proses, dan memeriksa apakah itu memenuhi
tujuan yang telah ditentukan.

QUALITY ASSURANCE 15
 4. Act - Penguji Jaminan Kualitas harus menerapkan tindakan yang diperlukan untuk
mencapai peningkatan dalam proses
9.4. Kontrol Kode Program
Kontrol kode program dilakukan dengan meninjau pada kode program dan menyoroti masalah
apa pun. Dalam hal ini kami juga harus membutuhkan persiapan lengkap jika memang
membuat agenda rapat client dengan agar memiliki pengetahuan lengkap tentang dokumen.

9.5. Kontrol Media

Dalam hal ini media yang digunakan oleh tim pengembang menggunakan aset pribadi dari
masing-masing anggota pengembang seperti perangkat laptop/komputer yang memiliki
tanggung jawab masing-masing yaitu menyimpan di tempat penyimpanan sesuai dengan
persyaratan keamanan dan di lingkungan yang terkendali yang mencegah degradasi atau
kerusakan media.

9.6. Keamanan
Keamanan pada aplikasi ini memfokuskan pada identifikasi dan penilaian dari potensi bahaya
yang dapat memberikan dampak buruk bagi aplikasi dan membuat seluruh system fail/gagal.
Jika suatu bahaya dapat diidentifikasi di awal, fitur design aplikasi dapat dispesifikasikan untuk
menghilangkan atau mengontrol potensi bahaya tersebut.

9.7. Pemulihan dari Bencana (disaster recovery)

Pendekatan yang digunakan dalam proyek ini adalah Disaster Recovery Virtual dimana proses
pemulihan datanya mengandalkan metode virtualisasi. Ketika terjadi bencana, maka akan
langsung ada tindakan pemulihan data tanpa harus menunggu server fisik.

9.8. Kontrol Supplier

Dalam proyek ini masih belum adanya pemasok sehingga tidak adanya persyaratan yang
ditetapkan

9.9. Pemgumpulan Catatan, Pemeliharaan dan Retensi

• Mengidentifikasi dokumentasi jaminan kualitas perangkat lunak yang perlu
dipertahankan dan menentukan periode penyimpanan
• Menyediakan fasilitas yang akan digunakan untuk mengumpulkan, melindungi dan
memelihara dokumentasi SQA.

QUALITY ASSURANCE 16
10.Pelaporan Masalah dan Tindakan Koreksi
10.1. Pelatihan Pengguna
Untuk pengguna dapat memahami sistem maka akan ada pelatihan untuk pengguna ,
diantaranya :
1. Pengguna dilatih untuk menggunakan fitur CRUD kategori barang
2. Pengguna dilatih untuk menggunakan fitur CRUD produk
3. Pengguna dilatih untuk menggunakan fitur update status pembelian produk dari customer

11.Pelaporan Masalah dan Tindakan Koreksi

11.1. Penilaian Diri Proyek
Diantara resiko yang mungkin terjadi pada proyek ini sebagai berikut:
Tabel 7 Penilaian Diri Proyek
No Daftar Resiko Tindakan

1. Cacat yang Ditemukan Dalam Beta Testing Dihindari

2. Ketidakpuasan Klien dengan Penyimpangan Jadwal Dicegah

3. Ketidakpuasan Klien dengan Kualitas Dicegah

4. Ketidakpuasan Klien dengan Dukungan Setelah Rilis Dicegah

5. Ketidaktersediaan Sumberdaya untuk Testing Dicegah

6. Pengalihan Sumberdaya Dikurangi

Kekurangan dalam Berbagi Informasi Permasalahan/Alat

7. Dikurangi
Bantu Manajemen Konfigurasi

8. Kekurangpahaman Tim Teknis Terhadap Sistem Internal Dikurangi

9. Ketiadaan Manajemen Risiko Formal Dikurangi

11.2. Rencana Penilaian dan Manajemen Risiko

Penilaian risiko berdasarkan daftar risiko yang telah disusun:
Tabel 8 Rencana Penilaian dan Manajemen Risiko
Kemungkinan Akibat
No Daftar Resiko
Resiko Resiko

1. Cacat yang Ditemukan Dalam Beta Testing Rendah Sedang

2. Ketidakpuasan Klien dengan Penyimpangan Jadwal Sedang Tinggi

3. Ketidakpuasan Klien dengan Kualitas Sedang Tinggi

QUALITY ASSURANCE 17
 4. Ketidakpuasan Klien dengan Dukungan Setelah Rilis Sedang Tinggi

5. Ketidaktersediaan Sumberdaya untuk Testing Rendah Rendah

6. Pengalihan Sumberdaya Rendah Sedang

Kekurangan dalam Berbagi Informasi

7. Rendah Sedang
Permasalahan/Alat Bantu Manajemen Konfigurasi

Kekurangpahaman Tim Teknis Terhadap Sistem

8. Tinggi Tinggi
Internal

9. Ketiadaan Manajemen Risiko Formal Rendah Rendah

11.3. Proses Tinjauan dan Manajemen Risiko

Hasil identifikasi risiko sebagai berikut:
Tabel 9 Proses Tinjauan dan Manajemen Risiko
Kemungkinan Akibat
No Daftar Resiko Tindakan Penjelasan Tindakan
Resiko Resiko

Cacat yang Memastikan proses

1. Ditemukan Dalam Rendah Sedang Dihindari pengujian aplikasi
Beta Testing terhindar dari bug.

Melakukan
Ketidakpuasan komunikasi
Klien dengan penyampaian progress
2. Sedang Tinggi Dicegah
Penyimpangan serta mendiskusikan
Jadwal jika terjadi hal yang
tidak diinginkan.

Memastikan seluruh
Ketidakpuasan
antarmuka dan fitur
3. Klien dengan Sedang Tinggi Dicegah
sistem bekerja dengan
Kualitas
baik.

Menyesuaikan segala
Ketidakpuasan
requirement agar
Klien dengan
4. Sedang Tinggi Dicegah aplikasi dapat
Dukungan Setelah
digunakan klien
Rilis
dengan baik.

QUALITY ASSURANCE 18
 Memastikan jadwal
Ketidaktersediaan
testing yang
5. Sumberdaya untuk Rendah Rendah Dicegah
memungkinkan untuk
Testing
antar anggota tim.

Menggantikan
Pengalihan
6. Rendah Sedang Dikurangi pekerjaan antar
Sumberdaya
anggota tim.

Melakukan konfirmasi
Kekurangan dalam
dan kesepakatan
Berbagi Informasi
mengenai
7. Permasalahan/Alat Rendah Sedang Dikurangi
penyedia/alat
Bantu Manajemen
konfigurasi yang akan
Konfigurasi
digunakan.

Kekurangpahaman
Tim Teknis Memperpanjang durasi
8. Tinggi Tinggi Dikurangi
Terhadap Sistem pengerjaan aktivitas.
Internal

Mendiskusikan antar
Ketiadaan
anggota mengenai
9. Manajemen Risiko Rendah Rendah Dikurangi
risiko pengembangan
Formal
aplikasi.

11.4. Alat Bantu (tools)

Dalam proyek ini alat bantu yang digunakan dalam melakukan manajemen risiko
yaitu dengan identifikasi menggunakan tabel

12.Hal yang Dipelajari

Hal-hal yang dapat dipelajari dari proyek yaitu pengukuran kinerja antara rencana dan realisasi
terhadap proyek berupa metriks proyek meliputi:
• Memperkirakan status sebuah proyek yang sedang berlangsung
• Menelusuri resiko-resiko potensial
• Menemukan masalah sebelum masalah menjadi semakin kritis
• Menyesuaikan aliran kerja dan tugas
• Mengevaluasi kemampuan tim proyek (mengontrol kualitas kerja)

QUALITY ASSURANCE 19
13.Persetujuan Dokumen
(Lampiran 3: Lembar Persetujuan Dokumen)

QUALITY ASSURANCE 20
Lampiran 1: Aktifitas dan Task

*Keterangan: owner adalah manajer (ketua) proyek

QUALITY ASSURANCE 21
Lampiran 2: Laporan Hasil Audit

Laporan Hasil Audit Internal

Auditor : Ulla Delfana Rosiani, ST., MT

Obyek Audit : Perancangan Aplikasi Toko Online Berbasis Mobile beserta

Sistem Manajemen Data Barang dan Transaksi Pembelian

No Tanggal Kegiatan Hasil

1 29 Oktober 2021
2 05 November 2021
Penyampaian Hasil • Perlu penambahan sisa
Implementasi kuantitas pada halaman
detail produk
• Perlu adanya logika ketika
calon pembeli melakukan
pemesanan barang yang
melebihi sisa barang yang
dipesan
Revisi Impelementasi Disetujui

QUALITY ASSURANCE 22
Lampiran 3: Lembar Persetujuan Dokumen

LEMBAR PERSETUJUAN DOKUMEN

Dengan ini menyatakan bahwa dokumen Quality Assurance dari proyek Perancangan
Aplikasi Toko Online Berbasis Mobile beserta Sistem Manajemen Data Barang dan Transaksi
Pembelian ini telah disetujui oleh pemilik proyek.

Tangerang, 16 November 2021

Menyetujui, Mengajukan,
Pemilik Proyek Ketua Proyek

Cetya Chairunisa Razaki Muhammad Fauzan Tri Aji

QUALITY ASSURANCE 23