BAB 2 LANDASAN TEORI
2.1
Pengertian Sistem Menurut Satzinger, Jackson dan Burd (2010: 6), sistem adalah kumpulan
komponen yang saling terkait yang berfungsi secara bersama-sama untuk mencapai hasil tertentu.
2.2
Pengertian Informasi Menurut Stair & Reynolds (2010: 5), informasi adalah sekumpulan fakta-
fakta yang diolah dengan berbagai macam cara sehingga memiliki nilai tambah dibalik nilai dari fakta individu tersebut.
2.3
Pengertian Data Menurut Rainer & Cegielski (2011: 10), data merupakan deskripsi dasar
suatu benda, kejadian, aktivitas dan transaksi yang direkam, dikelompokkan, dan disimpan, tetapi belum disusun untuk mengungkapkan arti tertentu. Menurut Stair dan Renold (2010: 5), data terdiri dari fakta mentah yang jika dikelola dengan cara yang berarti, maka akan menjadi informasi.
2.4
Pengertian Sistem Informasi Menurut O’Brien (2010: 4), sistem informasi dapat berupa kombinasi dari
orang, hardware, software, jaringan komunikasi sumber daya data, kebijakan dan prosedur yang terorganisir, yang menyimpan, mengambil, mengubah dan menyebarkan informasi dalam organisasi. Menurut Stair & Reynolds (2010: 10), sistem informasi merupakan serangkaian elemen-elemen atau komponen-komponen yang saling berhubungan yang mengumpulkan (input), memanipulasi (proses), menyebarluaskan (output) data dan informasi, menyediakan mekanisme umpan balik untuk mencapai tujuan tertentu. Komponen dari sistem informasi yaitu: •
Input, merupakan aktivitas mengumpulkan dan mencatat fakta-fakta mentah.
•
Proses, merupakan kegiatan konversi atau mengubah data menjadi output yang berguna. Proses dapat mencakup membuat kalkulasi, membandingkan data, 5
6 mengambil tindakan alternatif dan menyimpan data untuk penggunaan di masa yang akan datang. •
Output, menghasilkan informasi yang berguna, biasanya dalam bentuk dokumen atau laporan.
•
Umpan balik, merupakan informasi dari sistem yang digunakan untuk membuat perubahan pada kegiatan input atau proses. Maka dapat disimpulkan bahwa sistem informasi adalah kombinasi teratur
dari manusia, perangkat keras, perangkat lunak, jaringan komunikasi dan sumber daya data yang mengumpulkan, memproses, menyimpan, dan menyediakan output yang dibutuhkan untuk melakukan tugas-tugas dari bisnis, di mana data tersebut telah diproses dan memiliki arti .
2.5
IBM Cognos TM1 Aplikasi IBM Cognos TM1 adalah infrastruktur komprehensif yang
digunakan untuk mendukung dan mengelola aplikasi perencanaan Cognos TM1. Menggunakan Cognos TM1 Performance Modeler untuk mendesain cube dan dimensi yang mendefinisikan data. Sehingga aplikasi Cognos TM1 dapat digunakan untuk mengelola workflow dari data tersebut seperti membantu dalam perencanaan atau meninjau perubahan. Aplikasi Cognos TM1 ini dikelola oleh server aplikasi Cognos TM1 yang menyediakan akses web ke aplikasi dan aplikasi ini juga dirancang agar berbagai macam klien dapat bekerja dengan aplikasi ini. Aplikasi Cognos TM1 menyediakan dasar untuk menyusun dan mengelola aplikasi. Application modelers menawarkan pilihan untuk menggunakan aplikasi web Cognos TM1, Cognos Insight terdistribusi atau Cognos Insight dalam mode tersambung untuk memberikan kontribusi ke aplikasi. (Accenture, 2014) 2.6
SAP ECC SAP ECC (ERP Central Component) adalah sistem ERP yang memiliki
komponen tradisional dari R/3 finance, logistik , penjualan manajemen material , HR , dan tambahan kumpulan extension. (Caddick, 2008) 2.7
Input Template Input template adalah sebuah template dalam bentuk tabel yang digunakan
untuk menginput data keuangan PT. XYZ yang relevan dan terhubung ke IBM
7 Cognos TM1 yang berguna untuk upload data dan tersimpan ke dalam cube. (Accenture, 2014)
Gambar 2.1 Contoh Input Template
2.8
Cube Cube adalah database yang terdiri dari dua tau lebih dimensi, kombinasi
elemen yang dipilih pada setiap dimensi cube membentuk sebuah data point dimana data tersebut disimpan. Rules (misalnya, formula) ditulis didalam cube untuk menghitung item tertentu secara otomatis. Views adalah potongan data didalam cube yang dibuat dan disimpan. (Accenture, 2014) Fungsi cube adalah :
2.9
•
Data didalam cube dapat diretrieve untuk dilihat.
•
Untuk memasukan dan menyebarkan data.
Pengertian Testing Menurut Lewis (2009: 3), software testing adalah aktivitas menjalankan
serangkaian eksekusi yang dinamis pada program software setelah source code software tersebut telah dikembangkan. Software testing dilakukan untuk menemukan dan memperbaiki sebanyak mungkin potensi kesalahan sebelum software tersebut digunakan oleh pelanggan atau end user. Menurut Black (2009: 1), testing sebuah proses untuk mengukur kualitas dari pengembangan software. Terdapat 3 pertanyaan kunci yang harus dipertanyakan sebelum testing : 1. What you might test? 2. What you should test? 3. What can you test?
8 Terdapat dua tipe prosedur testing, yaitu : 1. Test Granularity Test granularity mengacu kepada kehalusan atau kasarnya pada sebuah fokus test. Fine-grained test case memungkinkan tester untuk mengecek detail di level yang lebih rendah. Sedangkan, coarse-grained test case menyediakan tester informasi tentang sifat umum sistem. •
Structural (White Box) Tests Structural test (yang disebut juga white box tests dan glass-box tests) mencari bugs dalam elemen struktural tingkat rendah seperti barisan kode, skema database, chips, subassemblies, dan interface. Menurut Jovanovic (2009: 31), White Box Testing sangat efektif dalam mendeteksi dan menyelesaikan masalah atau error, karena bugs dapat ditemukan sebelum terjadi error.
•
Behavioral (Black-Box) Tests Testers menggunakan behavioral tests (yang disebut juga black-box tests) untuk mencari bugs dalam operasi tingkat tinggi, seperti major features, operational profiles, dan customer scenarios. Menurut Jovanovic (2009: 31), Black Box Testing yaitu testing software yang berdasarkan pada output requirements dan tanpa pengetahuan dari struktur internal atau coding dalam program. Dalam kata lain sebuah black box adalah suatu alat yang tidak dapat diakses atau dimengerti user tersebut.
•
Live Tests Live tests mencakup menempatkan pelanggan, ahli konten, pengguna awal, dan end users lainnya di hadapan sistem.
Gambar 2.2 The test granularity spectrum and owners Sumber : (Black, 2013: 2) 2. Test Phases Test phases adalah langkah-langkah dalam proses testing. Ada beberapa tahapan yang dikenal dalam pengujian, antara lain : •
Unit testing berfokus pada bagian-bagian individu dari kode.
9 •
Component atau Subsystem testing berfokus pada bagian penyusun atau pembentuk dari sistem.
•
Integration atau Product testing berfokus pada hubungan dan interface antara pasangan komponen dan sekumpulan komponen di dalam sistem yang sedang diuji.
•
String testing berfokus pada masalah dalam typical usage scripts dan customer operational strings.
•
System testing meliputi seluruh sistem yang terintegrasi sepenuhnya. Misalnya dalam instalasi dan usability testing, test ini melihat sistem dari sudut pandang pengguna.
•
Acceptance
atau User Acceptance testing yang bertujuan untuk
menunjukkan bahwa sistem tersebut memenuhi persyaratan.
Tahap
pengujian ini umum dalam situasi kontraktual, ketika acceptance tests selesai maka pembeli harus menerima sistem tersebut. •
Pilot testing untuk menguji kemampuan perakitan untuk produksi masal sistem yang telah diselesaikan.
Gambar 2.3 The test execution period for various test phases in a development project Sumber: Black (2009: 9)
2.10
Pengertian Integration Testing Menurut Li, Liangming (2013: 1), kemajuan teknologi software terutama
penampilan dari metode object-oriented, pembangunan berbasis komponen dan berorientasi pada pelayanan pembangunan telah menunjukkan bahwa integrasi komponen menjadi inti dari pengembangan sistem. Sehingga integration testing menjadi faktor utama dalam menjamin kualitas suatu sistem.
10 Menurut Kumar, Gandhi dan Garg (2013: 5), integration testing adalah teknik yang sistematis untuk membangun stuktur program dan melakukan test untuk mengungkap kesalahan yang terkait dengan interface. Tujuan utamanya adalah untuk membangun sturktur program sesuai dengan desain. Menurut Black (2009: 6) Integration testing atau product testing berfokus pada hubungan dan interface antara pasangan komponen dan kumpulan komponen di dalam sistem yang sedang diuji dan seringkali secara bertahap. Integration testing harus dilakukan dalam koordinasi dengan proyek pada tingkat aktivitas mengintegrasikan seluruh sistem. Menurut Lewis (2009: 134), integrated testing untuk semua modul dilakukan setelah unit testing selesai dilakukan. Pada tahap integration testing, sistem dibangun secara perlahan dengan menambahkan satu atau lebih modul pada saat modul utama telah terintegrasi. Tujuan dari integration testing adalah untuk memastikan setiap modul berfungsi dengan benar di dalam struktur kontrol dan antarmuka modul sudah benar. Menurut Khan dan Singh (2012), berpendapat bahwa tujuan dari integration testing adalah untuk memastikan bahwa setiap modul dan interface di dalam program berinteraksi satu sama lain dengan cara yang benar dan aman. Maka dapat disimpulkan bahwa integration testing yaitu suatu pengujian yang berfokus pada memastikan apakah hubungan antarmuka dengan modul- modul yang terdapat dalam sistem aplikasi sudah dapat berinteraksi dengan baik dengan benar dan membangun struktur program sesuai dengan desain.
2.11
Pengertian Failure Mode and Effects Analysis (FMEA) Menurut Black (2009: 32) Pada dasarnya FMEA adalah sebuah teknik untuk
memahami dan memprioritaskan kemungkinan mode kegagalan dalam fungsi, fitur, atribut, sifat, komponen dan antarmuka pada sistem. Menurut Shirouyehzad, Dabestani dan Badakhshian (2011), tujuan dari FMEA untuk mencegah kegagalan yang tidak dapat diterima dan membantu manajemen untuk mengalokasikan sumber daya dengan lebih efektif.
11
Gambar 2.4 FMEA (Failure Mode and Effect Analysis) Sumber : (Black, 2013: 33)
1) System Function or Feature Ini adalah titik awal dalam analisis. Dalam kebanyakan baris yang ada, di dalamnya terdapat deskripsi singkat tentang fungsi yang terdapat dari sistem. Jika di dalamnya merupakan sebuah kategori, maka harus dipecah atau di bagi ke dalam fungsi-fungsi atau fitur yang spesifik. 2) Potential Failure Mode(s)-quality risk(s) Semua fungsi yang spesifik dalam kolom ini digunakan untuk menjelaskan bagaimana mengidentifikasi kegagalan yang ditemukan. Tiap fungsi spesifik atau fitur data mempunyai beberapa mode kegagalan. 3) Potential Effect(s) of Failure Kolom ini berisi tentang bagaimana setiap mode kegagalan dapat mempengaruhi pengguna sistem. 4) Critical Dalam kolom ini merupakan penentuan apakah akibat yang berpotensi untuk timbul merupakan hal yang kritikal atau penting bagi pengguna. 5) Severity Kolom severity ini menujukkan akibat dari kegagalan pada sistem, dimana digunakan skala dari 1 (yang terburuk) hingga 5(yang terbaik), sebagai berikut: 1. Hilangnya data, kerusakan hardware, atau keamanan sistem 2. Hilangnya fungsionalitas sistem tanpa adanya solusi
12 3. Hilangnya fungsionalitas sistem dengan adanya solusi 4. Hilangnya sebagian fungsionalitas sistem 5. Hal-hal kecil lainnya 6) Potential Cause(s) of Failure Kolom ini berisi faktor yang dapat memicu munculnya kegagalan. 7) Priority Priority merupakan skala prioritas atas kegagalan terhadap pengguna, pelanggan atau operator. Digunakan skala 1(paling buruk) hingga 5 (paling tidak berbahaya) sebagai berikut: 1. Hilangnya value sistem secara total 2. Kehilangan value sistem yang tidak dapat diterima 3. Pengurangan value sistem yang mungkin dapat diterima 4. Pengurangan value sistem yang dapat diterima 5. Pengurangan value sistem yang tidak berarti 8) Detection Method(s) Kolom ini berisi prosedur atau metode yang ada seperti aktivitas-aktivitas pengembangan vendor yang menyebabkan masalah dapat ditemukan sebelum mempengaruhi pengguna. 9) Likelihood Dalam kolom ini merepresentasikan tingkat kerentanan dari aplikasi untuk muncul mulai dari skala 1(paling mungkin) hingga 5 (tidak mungkin). 1. Pasti mempunyai pengaruh semua user 2. Kemungkinan besar mempengaruhi sebagian user 3. Mungkin mempengaruhi sebagian user 4. Pengaruh terbatas ke beberapa user 5. Tidak dapat dibayangkan dalam penggunaan sebenarnya 10) RPN (Risk Priority Number) Kolom RPN ini merupakan hasil dari severity, priority dan likelihood. Karena digunakan oleh skala dari 1 (paling kecil) hingga 125 (paling tidak berbahaya). 11) Recommended Action Kolom ini berisi tindakan yang direkomendasikan untuk mengurangi resiko pada tiap potential effect sehingga RPN menjadi bernilai 125. 12) Who/When?
13 Kolom ini menjelaskan siapa yang bertanggung jawab terhadap kegiatan testing dan recommended actions. 13) References Menyediakan tambahan informasi yang bisa dijadikan referensi tentang kualitas resiko.
2.12
Test Plan Menurut Black (2009: 50), Test plan menjelaskan bagaimana tester berniat
untuk mengimplementasikan strategi testing dalam beberapa proyek tertentu. Berikut adalah template yang digunakan untuk mengembangkan test plan. Template ini dapat dikurangi atau ditambah sesuai dengan kebutuhan test pada sistem aplikasi yang ingin di test.
Gambar 2.5 Test Plan Template Sumber: (Black, 2009: 52) a. Scope Menurut Black (2009: 53) scope adalah konteks dari sebuah proyek atau operasi, yang menjelaskan seberapa luas treatment, aktivitas atau pengaruh dalam lingkup operasi tersebut. Dan juga menjelaskan tentang apa yang dilakukan dan yang tidak dilakukan selama proyek atau pekerjaan berlangsung.
14 b. Setting Menurut Black (2009: 54) setting yaitu dimana tester berniat untuk melakukan testing dan cara organisasi melakukan testing tersebut yang berkaitan dengan seluruh organisasi. c. Quality Risk Tujuan dari quality risk yaitu untuk merangkum dokumen quality risk, dapat digunakan untuk referensi dalam pembuatan test plan. (Black, 2009: 55) d. Entry Criteria Menurut Black (2009: 58) entry criteria menguraikan apa yang harus terjadi untuk memungkinkan sistem pindah ke fase test tertentu. Kriteria- kriteria ini harus dapat menjawab pertanyaan dibawah ini, yaitu : •
Apakah dokumentasi, desain, implementasi dan informasi persyaratan tersedia yang dibutuhkan akan memungkinkan tester untuk mengoperasikan sistem dan menilai sifat yang benar?
•
Apakah sistem telah siap untuk pengiriman, dalam bentuk apapun sesuai dengan tahap uji tersebut?
•
Apakah sarana penunjang, aksesoris dan prasyarat yang tersedia dalam bentuk yang dapat digunakan tester?
•
Apakah sistem dalam level kualitas yang baik? Pertanyaan ini biasanya menyiratkan bahwa beberapa atau semua sistem sebelumnya telah berhasil dan selesai, walaupun dapat mengacu juga pada sejauh mana masalahmasalah yang ada telah ditangani.
•
Apakah test environment, seperti lab, hardware dan sistem penunjang administrasi telah siap?
e. Continuation Criteria Menurut Black (2009: 59) continuation criteria mendefinisikan kondisi dan situasi tersebut yang harus terus dipakai dalam proses testing untuk memungkian testing dapat berlanjut dengan efektif dan efisien. f. Exit Criteria Menurut Black (2009: 60) exit criteria mengatasi masalah bagaimana cara untuk menentukan kapan testing proyek telah selesai. g. Test Development Menurut Black (2009: 61) test development dalam beberapa kasus yaitu menjalankan test kembali yang telah dilakukan pada testing sebelumnya. Atau
15 juga dapat melakukan test data selama testing lalu menjalankan testing sesuai prosedur dan spesifik langkah testing yang ada. Dengan kata lain, dalam proyek testing yang ada, juga diperlukan untuk mendesain dan mengembangkan berbagai test object seperti test cases, test tools, test procedures, test suites, automated test scripts, dan lainnya. h. Test Case and Bug Tracking Menurut Black (2009: 64) bagian test case and bug tracking berkaitan dengan sistem yang digunakan untuk mengelola dan melacak test cases dan bugs. Test case tracking ini mengacu pada spreadsheet, database atau alat yang digunakan untuk mengelola semua test cases yang ada di dalam test suites dan bagaimana cara untuk melacak perkembangan yang ada dalam test tersebut. i. Test Cycles Menurut Black (2009: 68) test cycle yaitu menjalankan satu, beberapa atau semua test suites yang sudah direncanakan untuk tahap test yang diberikan. Jika satu test phase selesai, akan memicu test selanjutnya untuk dimulai.
2.13
Test Case Menurut Black (2009: 610), test case adalah sebuah urutan atau rangkaian,
substeps dan tindakan lainnya, dilakukan secara berurut, secara paralel atau kombinasi dari deretan yang menciptakan test condition yang diinginkan, yang dimana test case dirancang untuk mengevaluasi sistem yang dikembangkan. Dalam beberapa gaya dokumentasi, elemen ini disebut sebagai test specification dan test procedures. Menurut Jovanović (2009: 30), test case adalah sekumpulan masukan, eksekusi dari prasyarat, dan hasil yang diperkirakan akan muncul untuk beberapa tujuan tertentu, seperti menjalankan sebagian jalur (kode) dari program atau dengan memeriksa kesesuaian dengan syarat yang spesifik. Menurut Perry (2006: 436), berikut adalah atribut yang harus dimiliki untuk mengembangkan setiap test case: •
Kondisi: memberitahukan apa yang terjadi.
•
Kriteria: memberitahukan apa yang seharusnya terjadi.
•
Efek: memberitahukan mengapa terjadi perbedaan antara kondisi dengan kriteria secara signifikan.
16 •
Akibat: memberitahukan alasan dari perbedaan yang terjadi. Dari definisi di atas, test case adalah beberapa urutan aktivitas yang dapat
dilakukan secara berurutan, paralel ataupun dengan beberapa kombinasi yang dapat membuat sebuah kondisi pengujian yang diinginkan yang merupakan masukan, eksekusi dari prasyarat, dan hasil yang diperkirakan akan muncul untuk beberapa tujuan tertentu di dalam suatu pengujian.
Gambar 2.6 Test Case Template Sumber: (Black, 2009: 93)
2.14
Test Tracking Spreadsheet Menurut Black (2009: 199), dalam bentuk paling dasarnya, test tracking
spreadsheet adalah to-do-list, dengan menambahkan kemampuan dalam status tracking.
17
Gambar 2.7 Test Tracking Spreadsheet Sumber: (Black, 2009: 220)
Kolom pertama berisi nama test suite atau test case dan ID nya. Kolom yang kedua (State) berisi status dari setiap test case. Jika kosong, maka test case sedang berjalan dan mungkin akan berlanjut untuk sementara. Dalam kolom state, Pass menunjukkan bahwa test case tidak mengidentifikasi bug sama sekali; Fail menunjukkan bahwa satu bug atau lebih yang ditemukan. Kolom System Config berisi pengidentifikasi yang digunakan untuk konfigurasi sistem dalam setiap test case, seperti operating system, network setup dan software atau hardware tambahan yang terlibat dalam pengujian. Test case yang menemukan kegagalan atau bug, kolom Bug ID nya akan terisi sebagai pengidentifikasi adanya bug.
18 Kolom By berisi inisial dari penguji yang melakukan setiap test case yang ada dan kolom comment memungkinkan penguji untuk memberikan informasi yang lebih detil terhadap status test case. Kolom Roll Up berisi rangkuman atas informasi status dari setiap test case. Setiap test case dapat memiliki tiga nilai numerik berdasarkan statusnya, yaitu: a. Kolom T memiliki nilai 1 apabila itu adalah test case. b. Kolom F memiliki nilai 1 apabila status dari test case adalah Fail. c. Kolom P memiliki nilai 1 apabila status dari test case adalah Pass.
2.15
Bug Report Menurut Black (2009: 146), bug report adalah dokumen teknikal yang
menjelaskan berbagai tanda atau failure mode terkait dengan satu bug. Bug report yang baik yaitu yang menyediakan informasi yang dibutuhkan tim project management untuk menentukan kapan dan bagaimana memperbaiki masalah tersebut. Mengklasifikasi laporan bug memberikan sebuah alasan untuk memasukkan sebuah bug ke dalam kategori tertentu yang mengindikasikan bahwa bagaimana bug tersebut harus ditangani, yaitu: -
Kegagalan persyaratan Laporan bug yang lebih memperhatikan kegagalan dalam sistem untuk mencapai persyaratan yang seharusnya.
-
Kegagalan yang bukan persyaratan Bug yang dilaporkan tidak termasuk dalam persyaratan sistem, tetapi secara signifikan mempengaruhi kualitas dari sistem melalui cara atau kejadian yang tidak biasa.
-
Permintaan diabaikan Laporan bug menggambarkan terjadinya kesalahan atau kegagalan tetapi pihak pengembangan meminta untuk mengabaikan karena mereka percaya bahwa hal tersebut tidak terlalu berpengaruh kepada pelanggan atau pengguna secara kualitas.
-
Kegagalan eksternal Laporan bug yang mencatat kegagalan yang muncul dari faktor atau beberapa faktor eksternal atau yang di luar kendali dari sistem yang diuji.
19 -
Kegagalan pengujian Pihak pengembang percaya bahwa pengujian memberikan hasil yang salah/ tidak valid. Dari definisi di atas, bug report merupakan dokumentasi teknikal yang berisi
daftar error atau kesalahan yang ditemukan selama pengujian yang telah dilakukan dan informasi yang terkait dengan kesalahan tersebut sehingga perbaikan atas kesalahan dapat dilakukan.
Gambar 2.8 Bug Report Sumber: (Black, 2009: 156)
2.16
Kerangka Pikir Untuk mempermudah dan menunjukkan hubungan dari proses dalam
penulisan ini, kerangka piker dibuat dan digambarkan dalam Gambar 2.9. Kerangka pikir ini dimulai dengan analisa proses bisnis menggunakan IBM Cognos TM1 versi 10.2. Proses bisnis akan digambarkan dan dijelaskan di Bab 3 pada sub bab IBM Cognos TM1 pada PT.XYZ dan spesifikasi proses bisnis. Dari penggambaran dan penjelasan proses bisnis dan aplikasi ini akan dilakukan analisis dengan menggunakan Failure Mode Effect Analysis (FMEA) untuk menentukan bug yang akan diperbaiki. Setelah itu akan dibuat Test Plan dan Test Case. Test Plan tersebut akan digunakan sebagai acuan dalam pelaksanaan testing. Test Case yang telah dibuat akan dikelompokkan kedalam beberapa Test Suite untuk memperjelas hubungan antar setiap Test Case. Langkah berikutnya yaitu pembuatan Test Cycle untuk memberikan alur pelaksanaan testing berdasarkan
20 tanggal yang telah ditetapkan. Test Suite dan Test Cycle ditetapkan pada pelaksanaan testing. Setelah tester selesai melakukan testing, maka hasil testing tersebut akan dimasukkan kedalam Test Result. Dari Test Result tersebut dapat dilihat Test Case mana yang memiliki status Pass atau Fail. Test Case yang memiliki status Fail akan dikelompokkan kedalam Bug List. Selanjutnya akan dibuat Test Tracking Spreadsheet untuk memberikan view yang lebih detail dari hasil pelaksanaan Test Case. Didalam Test Tracking Spreadsheet ini dapat melihat tester yang melakukan pengujian, serta sistem operasi software ataupun hardware yang terlibat dalam pengujian tersebut. Untuk melaporkan setiap bug yang ditemukan secara lebih detail, maka dibuat Bug Report, agar bug tersebut dapat dilaporkan dan diperbaiki oleh bagian teknikal. Hasil akhir dari penulisan skripsi ini adalah untuk menentukan apakah sistem yang telah dikembangkan siap dilanjutkan ke tahapan testing berikutnya yaitu User Acceptance Testing (UAT).
21
Gambar 2.9 Kerangka Pikir
22
