BAB II LANDASAN TEORI
2.1. Definisi Sistem Informasi
Sistem informasi adalah seperangkat unsur yang saling terkait atau komponen yang mengumpulkan / input , memanipulasi / process , menyimpan , dan menyebarkan / output data dan informasi, dan memberikan reaksi korektif / feedback untuk memenuhi tujuan (Stair dan Reynolds,2011). Mekanisme feedback merupakan komponen yang membantu tercapainya sebuah tujuan bisnis, seperti meningkatkan keuntungan atau meningkatkan layanan pelanggan. Dengan mengacu pada penjelasan diatas, sebuah sistem dapat terdiri dari sub sistem yang lain ataupun juga dapat menjadi bagian dari sistem yang lebih besar. Sistem mempunyai 4 fungsi dasar yaitu :
Gambar 2. 1 Fungsi Dasar Sistem Informasi
1. Input, menjelaskan tentang penerimaan dan penggabungan elemen – elemen yang akan diproses pada sebuah sistem.
2. Processing, melibatkan tentang proses transformasi yang merubah input menjadi outpu, atau data menjadi sebuah informasi yang lebih bermanfaat.
3. Output, yakni pendistribusian elemen – elemen sebagai hasil proses ke tujuan.
4. Feedback, adalah penjelasan mengenai perubahan yang dapat dilakukan pada saat proses masukan atau pengolahan (Ralph M. Stair, George W. Reynolds, 2012:10)
2.1.1. Definisi Perancangan Sistem Informasi
Perancangan sistem informasi (program design) merupakan bagian dari fase desain pada SDLC. Perancangan sistem membantu perancang dalam menganalisa dan menentukan program seperti apa yang akan ditulis, membuat instruksi untuk programmer tentang bagaimana kode program seharusnya ditulis serta mengidentifikasi tentang bagaimana bagian-bagian kode akan digabungkan bersama dalam membuat sebuah program. (Alan Dennis, Barbara Haley Wixom, dan Roberta M. Roth, 2012:260)
2.2. Definisi Sistem Informasi Pemeliharaan Produk Berbasis Web
Maintenance atau pemeliharaan adalah suatu kegiatan yang dilakukans secara berulang – ulang dengan tujuan agar peralatan selalu memiliki kondisi yang sama dengan keadaan awalnya. Maintenance juga dilakukan untuk menjaga peralatan tetap beraa dalam kondisi yang dapat diterima oleh penggunanya. (Maintenance Engineering Handbook, 8th Edition, McGraw-Hill, 2014).
Produk sendiri adalah sesuatu yang ditawarkan ke pasar / subyek dan dapat berupa peralatan sebagai solusi pemecahan masalah atau guna memenuhi kebutuhan yang dimiliki oleh subyek tersebut. Subyek tersebut dapat berupa sebuah organisasi yang sedang mencari solusi dalam menunjang kebutuhan bisnisnya.
Secara ringkas, Sistem Informasi Pemeliharaan Produk dapat diartikan sebagai sistem informasi yang mengelola dan mengolah data pemeliharaan produk yang telah didistribusikan ke penggunanya dalam rangka meningkatkan pelayanan dan kepuasan pengguna dalam penggunaan produk yang ditawarkan oleh sebuah perusahaan.
Dalam rangka meningkatkan pelayanan dan kepuasan pengguna, pemeliharaan produk yang dilakukan adalah sebagai berikut :
ü Layar entry produk
ü Informasi ketersediaan produk
ü Pengolahan data dan informasi produk yang akan ditawarkan ke calon pengguna, sampai dengan produk dapat digunakan dengan baik oleh pengguna
ü Pengelolaan produk yang telah terdistribusi ke pengguna, dalam rangka memelihara dan menjaga kualitas dari produk
ü Informasi historical kegiatan pemeliharan yang telah dilakukan, sebagai bahan evaluasi atas keseluruhan proses yang terjadi
2.3. Definisi Database
Database atau dikenal dengan basis data adalah sekumpulan data yang saling berhubungan yang merefleksikan fakta-fakta yang terdapat pada suatu organisasi.
Basis data merupakan komponen utama sistem infomarsi karena semua informasi untuk pengambilan keputusan berasal dari data di dalam basis data.
Basis Data merupakan sebuah kumpulan elemen-elemen data yang terintegrasi dan berelasi secara logis. Sebuah basis data menggabungkan baris- baris yang sebelumnya telah disimpan pada file terpisah. Basis Data membuat wadah bagi data-data, untuk melayani berbagai aplikasi. (George M. Marakas dan James A. O’Brien:684)
Istilah database mengacu pada koleksi dari data-data yang saling berhubungan dan perangkat lunak yang mengacu sebagai sistem manajemen basis data (DBMS). Jika konteksnya sudah jelas, banyak administrator dan programmer menggunakan istilah database untuk kedua arti tersebut.
2.3.1. Database Management System (DBMS)
DBMS atau sistem manajemen basis data adalah perangkat lunak untuk mendefinisikan, menciptakan, mengelola, dan mengendalikan pengaksesan
basis data. Tujuan utama sistem manajemen basis data adalah menyediakan lingkungan yang nyaman dan efisien untuk penyimpanan dan pengambilan data dari basis data.
DBMS merupakan program software yang kompleks, yang mengatur organisasi penyimpanan, manajemen, dan penggunaan data yang ada di database.
DBM S mencakup:
• Bahasa pemodelan untuk menjelaskan skema dari setiap database yang berada di dalam DBMS dan sesuai dengan data model DBMS.
• Data Struktur ( fields, record, file, dan object ) dioptimalkan untuk digunakan bersama dengan media penyimpanan data berskala besar.
• Database query language
• Mekanisme transaksi
2.3.2. MySQL
MySQL adalah suatu manajemen basis data reasional yang mampu bekerja dengan cepat, kokoh, dan mudah digunakan. Basis data memungkinan untuk menyimpan, menelusuri, mengurutkan, dan mengambil data secara efisien. Server MySQL yang akan membantu melakukan fungsionalitas tersebut. MySQL dikembangkan oleh sebuah perusahan Swedia bernama MySQL AB. MySQL berada di bawah bendera GNU GPL sehingga termasuk produk open source dan sekaligus memiliki lisensi komersial.
2.4. Teknologi Pendukung
Saat ini banyak tersedia paket perangkat lunak untuk memenuhi kebutuhan dari sistem. Terdapat perangkat lunak yang telah diuji serta terbukti mampu menghemat waktu dan biaya pengembangan.
2.4.1 PHP (Hypertext Preprocessor)
PHP merupakan suatu bahasa pemrograman sisi server yang dapat digunakan untuk membuat halaman web dinamis. Dalam suatu halaman HTML dapat ditanamkan kode PHP yang akan dieksekusi setiap kali halaman tersebut dikunjungi. PHP dibangun oleh Rasmus Lerdorf pada tahun 1994. Pada awal pengembangan, PHP disebut sebagai kependekan dari Personal Home Page. PHP merupakan produk open source sehingga kita dapat mengakses source code, menggunakan, dan mengubah secara gratis.
2.4.2 Definisi Framework
Dalam dunia pemrograman, framework adalah kumpulan kelas (class) dan fungsi (function, method) yang disusun secara sistematis berdasarkan kegunaan tertentu untuk mempermudah pembuatan atau pengembangan aplikasi. Saat ini sebagian besar framework dibangun berdasarkan konsep Object Oriented Programming (OOP). Beberapa contoh umum kelas yang disediakan framework adalah kelas session, kelas database, kelas email.
Manfaat framework salah satunya adalah menawarkan penghematan waktu kerja dalam penulisan code dan pengaturan berkas-berkas kode.
2.4.3 Arsitektur Model-View-Controller (MVC)
Arsitektur MVC muncul sejak era 70-an atas pemikiran Prof. Trygve Reenskaug, seorang berkebangsaan Norwegia. Dasar arsitektur ini adalah pemisahan antara logika aplikasi dengan tampilan. Penggunaan pola ini diharapkan dapat meminimalisasi penulisan perintah sehingga resiko terjadinya bug juga berkurang, serta meningkatkan efisiensi pembangunan aplikasi. Contoh framework PHP MVC adalah CodeIgniter (CI).
Gambaran penerapan arsitektur MVC dalam CI kurang lebih sebagai berikut :
• Model bertanggung jawab untuk melakukan pengelolaan data dalam basis data. Di dalamnya biasa dituliskan perintah untuk mengambil, mengubah, menghapus, dan menambah data.
• View merupakan “tempat” untuk meletakkan apa yang akan ditampilkan di halaman browser. Umumnya berisi kode bahasa pemrograman sisi klien.
• Controller merupakan pengatur utama hubungan antara model, view, dan juga sumber daya lain yang tersedia. Sumber daya ini diperoleh dari tipe/kelompok kelas yang dapat disebut dengan elemen framework CI.
2.4.4 Codeigniter (CI)
CodeIgniter (CI) ditulis oleh Rick Ellis setelah Rick melakukan suatu riset kecil. Dalam riset tersebut diambil kesimpulan bahwa banyak framework PHP yang berukuran terlalu besar atau terlalu minimalis untuk digunakan, serta dokumentasinya yang kurang baik. Rick berniat membuat CI hanya berukuran kecil, dapat berjalan ringan, tetapi tetap memenuhi fitur umum aplikasi PHP.
2.4.5 XAMPP
XAMPP merupakan aplikasi yang mengintegrasikan beberapa aplikasi utama web. Dalam XAMPP terdapat instalasi modul PHP MySQL, web server Apache sehingga memudahkan kita karena tidak perlu menginstal modul secara terpisah.
2.5. Unified Modeling Language (UML)
Tujuan dari Unified Modeling Language adalah untuk menyediakan alat bantu dalam teknik pemodelab berbasis obyek dan teknik pembuatan skema diagram yang cukup beragam untuk menggambarkan proyek pengembangan sistem dimulai dari analisa sampai dengan proses desain. (Alan Dennis, Barbara Haley Wixom dan Roberta M. Roth, 2012:513).
Diagram – diagram pada Unified Modeling Language (UML) dibagi menjadi 2 jenis yaitu structure diagram, yakni diagram yang digunakan untuk
menggambarkan data dan relasi paten yang ada di dalam sistem informasi. Jenis yang lain yaitu behavior diagrams yang menyediakan analisa dengan cara menggambarkan relasi yang dinamis antar obyek yang mewakili sistem ifnromasi dalam hal bisnis. Berikut adalah UML Diagram yang digunakan dalam mengerjakan tugas akhir :
Tabel 2. 1 Daftar Diagram UML
Nama Diagram Digunakan Untuk Fase Utama Behavior Diagram
Use Case Diagram Mengambil kebutuhan bisnis untuk sistem dan menggambarkan interaksi antara sistem dengan lingkungannya
Analisa
Activity Diagram Menggambarkan alur kerja bisnis pada masing-masing class, Alur dari aktivitas pada use case, atau dapat digunakan untuk
memperjelas metode perancangan
Analisa, Desain
Sequence Diagram Menampilakn perilaku objek dalam use case.
Berfokus pada urutan kegiatan berbasis waktu
Analisa, Desain
Structure Diagram
Class Diagram Menggambarkan relasi antar class modeled dalam sebuah sistem
Analisa, Desain
2.5.1 Use Case Diagram
Use Case Diagram digunakan oleh para analis untuk mengetahui lebih baik lagi mengenai fungsionalitas sistem dari tingkatan yang sangat tinggi (Alan Dennis, Barbara Haley Wixom dan Roberta M. Roth, 2012:517). Use Case Diagram menggambarkan apa yang sebenarnya dilakukan oleh sistem secara lengkap dan digambarkan dalam SDLC pada saat analis mengumpulkan dan mendefinisikan kebutuhan sistem. Use Case Diagram paling tidak memiliki 4 elemen seperti yang dijelaskan pada tabel dibawah ini :
Tabel 2. 2 Elemen Use Case Diagram
No. Nama Elemen Simbol Definisi
1 Aktor
• Aktor adalah orang atau sistem yang memperoleh manfaat dari dan /atau di luar sistem.
• Aktor harus diberikan label sesuai dengan peranannya
• Aktor dapat dikaitkan dengan aktor-aktor lain oleh spesialisasi atau asosiasi superclass yang dilambangkan dengan anak panah dengan panah berongga
• Aktor ditempatkan di luar batas sistem
No. Nama Elemen Simbol Definisi
2 Use Case • Use case merupakan bagian utama dari fungsionalitas sistem
• Use case dapat memperpanjang use case lain (extend)
• Use case depat menggunakan use case lain
• Use case ditempatkan di dalam batas sistem
• Use case diberi label dengan penjelasan kata kerja atau kata benda
3 Batasan Sistem • Batasan sistem terdiri dari nama sistem yang terdapat di dalam atau di atas simbol
• Batasan sistem merupakan ruang lingkup sistem
4 Relasi Asosiasi • Relasi asosiasi menghubungkan aktor dengan use case yang berinteraksi
2.5.2 Activity Diagram
Activity Diagram adalah notasi UML yang menjelaskan tentang perilaku sebuah sistem yang dilihat dari terminologi kegiatan – kegiatan. (Bernd Bruegge dan Allen H. Dutoit, 2010:33). Maksud dari kegiatan – kegiatan adalah elemen – elemen pemodelan yang menggambarkan pelaksanaan sekumpulan operasi.
Pelaksanaan dari sebuah aktivitas dapat didasari baik oleh penyelesaian tugas pada aktivitas yang lain, oleh ketersediaan obyek atau kejadian ekseternal.
Activity Diagram hampir sama dengan flowchart dalam hal penggambaran pengaturan alur ( operasi apa saja yang terjadi ) dan alur data ( obyek yang terlibat selama operasi berjalan ). Berikut adalah elemen – elemen UML dalam bentuk Activity Diagram :
Tabel 2. 3 Elemen Activity Diagram
No. Nama Elemen Simbol Definisi
1 Activity Menggambarkan aksi atau
aktivitas, activity dapat
dilakukan hanya setelah semua predecessor activty atau aktivitas yang sebelumnya telah selesai dilakukan
2 Control Flow Arah aliran dari dan ke masing-
masing activity 3 Control node –
Decision
Adalah cabang dari control flow.
Yang memberikan alternatif berbasis kondisi pada suatu object atau sekumpulan object 4 Control node –
Fork nodes
Membagi flow control ke dalam banyak activity (thread)
5 Control node – Join nodes
Melakukan sinkroniasi dari banyak activity (thread) ke dalam satu activity paralel
2.5.3 Sequence Diagram
Sequence Diagram menggambarkan obyek – obyek yang berperan serta dalam Use Case dan pesan – pesan yang dilewati oleh obyek dari waktu ke waktu untuk sebuah Use Case. (Alan Denis, Barbara Haley Wixom dan Roberta M. Roth,
.
Decision
2012:530). Sequence Diagram merupakan model dinamis yang mendukung tampilan yang dinamis untuk dimanfaatkan dalam pengembangan sistem.
Sequence Diagram menunjukkan urutan yang eksplisit yang dilewati antar obyek dalam suatu interaksi yang telah didefinisikan sebelumnya. Dikarenakan Sequence Diagram menekankan pada urutan kegiatan berdasarkan waktu, maka akan sangat membantu dalam memahami spesifikasi secara mendetail dan real time guna membantu memahami Use Case yang kompleks. Berikut ini adalah elemen – elemen yang dapat ditemukan dalam sebuah Sequence Diagram:
Tabel 2. 4 Elemen Sequence Diagram
No .
Nama Elemen Simbol Definisi
1 Aktor • Aktor adalah orang atau sistem
yang memperoleh manfaat dari dan di luar sistem
• Aktor berpartisipasi secara berurutan dengan mengirimkan atau menerima pesan
• Aktor ditempatkan di bagian atas diagram
2 Object • Objek berpartisipasi secara
berurutan dengan mengirimkan atau menerima message
• Objek ditempatkan di bagian atas diagram
3 Lifeline Lifeline menunjukkan masa dari
sebuah objek dalam sebuah urutan Lifeline berisi X pada suatu poin dimana kelas atau objek tidak lagi berinteraksi Object
No .
Nama Elemen Simbol Definisi
4 Focus of control • Focusof control berupa persegi panjang yang tipis ditempatkan di atas lifeline
• Focus of control ditunjuk ketika sebuah objek sedang mengirim atau menerima message
5 Message Message menyampaikan
informasi dari satu object ke object lain
6 Object destruction X Objectdestruction berupa simbol X ditempatkan pada akhir dari suatu object’s lifeline untuk menunjukkan bahwa lifeline akan berakhir
2.5.4 Class Diagram
Class Diagram merupakan model statis yang mendukung static view pada pengembangan sistem. Class Diagram menampilkan kelas – kelas dan relasi kelas yang terdapat dalam sebuah sistem dari waktu ke waktu secara konstan (Alan Dennis, Barbara Haley Wixton dan Roberta M. Roth, 2012:521). Berikut ini adalah elemen – elemen yang ada pada Class Diagram :
Tabel 2. 5 Elemen Class Diagram
No .
Nama Elemen Simbol Definisi
1 Class • Class dapat berupa jenis orang,
tempat atau mengenai suatu hal yang harus didapatkan sistem dan
disimpan informasinya.
• Class mempunyai nama class yang ditulis dengan huruf tebal dan berada di atas bagiannya (kompartemen).
• Class mempunyai daftar atribut di tengah bagiannya
• Class mempunyai daftar operasi di bagian paling bawah
• Class tidak secara eksplisit
menunjukkan operasi yang tersedia untuk semua class
2 Atribut Nama Atribut • Atribut menggambarkan properties yang menggambarkan kondisi dari suatu objek.
• Atribut dapat berasal dari atribut lain, ditunjukkan dengan menempatkan garis miring sebelum nama atribut itu 3 Metode Operation name
()
• Metode menggambarkan tindakan atau fungsi yang dapat dilakukan sebuah class
• Metode dapat diklasifikasikan sebagai konstruktor, query atau operasi update
• Metode terdiri dari tanda kurung yang dapat mengandung parameter khusus atau informasi yang
dibutuhkan untuk melakukan operasi
class +Attribute1 +Operation1()
No .
Nama Elemen Simbol Definisi
4 Asosiasi • Asosiasi menggambarkan hubungan
antara beberapa class, atau class dengan dirinya sendiri.
• Asosiasi diberi label kata kerja atau nama peran, tergantung yang mana yang lebih baik yang
menggambarkan relasi
• Asosiasi terdapat di antara satu class atau lebih
• Asosiasi berisi simbol multiplicity, yang mewakili jumlah minimum dan maksimum suatu class instance dapat dikaitkan dengan class intance yang lain
2.6. System Development Life Cycle (SDLC)
Konsep system development life cycle adalah proses pembuatan dan pengubahan sistem serta model dan metodologi yang digunakan untuk mengembangkan sistem-sistem tersebut. Konsep ini umumnya merujuk pada sistem komputer atau informasi. SDLC juga merupakan pola yang diambil untuk mengembangkan sistem perangkat lunak, yang terdiri dari tahap-tahap: rencana (planning), analisis (analysis), desain (design), implementasi (implementation), uji coba (testing), dan pengelolaan (maintenance).
Konsep system development life cycle mendasari berbagai jenis metodologi pengembangan perangkat lunak. Metodologi pengembangan perangkat lunak adalah suatu kerangka kerja yang digunakan untuk menstrukturkan, merencanakan, dan mengendalikan proses pengembangan suatu sistem infomasi. Ada beberapa
model SDLC, model yang populer dan banyak digunakan adalah metode waterfall.
Berikut ini metode pengembangan waterfall yang dijelaskan oleh gambar 2.21:
Gambar 2. 2 Fungsi Metode Waterfall
(Sumber : Software Engineering. Oleh : Roger S. Pressman)
2.6.1 Tahapan Metode Waterfall
Dalam pengembangannya metode waterfall memiliki beberapa tahapan yang runtut: Requirement, Design, Implementation, Verification dan Maintenance.
Tahap Requirement atau spesifikasi kebutuhan sistem adalah analisa kebutuhan sistem yang dibuat dalam bentuk yang dapat dimengerti oleh pengguna dan staf pengembang. Dalam tahap ini klien atau pengguna menjelaskan segala kendala dan tujuan serta mendefinisikan apa yang diinginkan dari sistem. Setelah dokumen spesifikasi disetujui maka dokumen tersebut menjadi kontrak kerja antara klien dan pihak pengembang.
Tahap selanjutnya adalah Design, dalam tahap ini pengembang akan menghasilkan sebuah arsitektur sistem secara keseluruhan, dalam tahap ini menentukan alur perangkat lunak hingga pada tahap algoritma yang detil.
Selanjutnya tahap Implementation, yaitu tahapan dimana keseluruhan desain diubah menjadi kode-kode program. kode program yang dihasilkan masih berupa modul-modul yang selanjutnya akan di integrasikan menjadi sistem yang lengkap untuk meyakinkan bahwa persyaratan perangkat lunak telah dipenuhi. Tahap selanjutnya adalah Veritication oleh pengguna, pengguna akan menguji apakah
sistem tersebut telah sesuai dengan kontrak yang telah disetujui. Tahap akhir adalah Maintenance yang termasuk diantaranya instalasi dan proses perbaikan sistem sesuai kontrak.
2.6.2 Manfaat Metode Waterfall
Keunggulan model pendekatan pengembangan software dengan metode waterfall adalah pencerminan kepraktisan rekayasa, yang membuat kualitas software tetap terjaga karena pengembangannya yang terstruktur dan terawasi.
Disisi lain model ini merupakan jenis model yang bersifat dokumen lengkap, sehingga proses pemeliharaan dapat dilakukan dengan mudah. Akan tetapi dikarenakan dokumentasi yang lengkap dan sangat teknis, membuat pihak pengguna sulit membaca dokumen yang berujung pada sulitnya komunikasi antar pengembang dan pengguna. Dokumentasi kode program yang lengkap juga secara tak langsung menghapus ketergantungan pengembang terhadap pemrogram yang keluar dari tim pengembang. Hal ini sangat menguntungkan bagi pihak pengembang dikarenakan proses pengembangan perangkat lunak tetap dapat dilanjutkan tanpa bergantung pada pemrogram tertentu.
2.6.3 Kelemahan Metode Waterfall
Kelemahan pengembangan software dengan metode waterfall yang utama adalah lambatnya proses pengembangan perangkat lunak. Dikarenakan prosesnya yang satu persatu dan tidak bisa diloncat-loncat menjadikan model klasik ini sangat memakan waktu dalam pengembangannya. Disisi lain, pihak pengguna tidak dapat mencoba sistem sebelum sistem benar-benar selesai pembuatannya. Kelemahan yang lain adalah kinerja personil yang tidak optimal dan efisien karena terdapat proses menunggu suatu tahapan selesai terlebih dahulu.
Secara keseluruhan model pendekatan pengembangan software dengan metode waterfall cocok untuk pengembangan software / perangkat lunak dengan tingkat resiko yang kecil, dan memiliki ukuran yang kecil serta waktu
pengembangan yang cukup panjang. Model ini tidak disarankan untuk ukuran perangkat lunak yang besar dan tingkat resiko yang besar.
2.7. Metode Pengujian Perangkat Lunak
2.7.1 Black Box Testing
Black Box Testing, atau yang biasa disebut sebagai Behavioral Testing atau Functional Testing, berfokus pada pengujian fungsional dari sebuah perangkat lunak. Black Box Testing memungkinkan kita untuk mengetahui secara lengkap apakah semua kebutuhan perangkat lunak telah dilaksanakan. (Roger Pressman, 2014:509)
Tidak seperti White Box Testing yang dilakukan pada tahap awal pengujian sistem perangkat lunak, Black Box Testing cenderung dilakukan pada saat tahap lanjutan pada tahapan pengujian karena metode pengujian ini sengaja mengabaikan komposisi structural, melainkan berfokus pada ranah informasi. Pengujian menggunakan metode ini di desain untuk menjawab kebutuhan berikut :
1. Bagaimana kebutuhan fungsional diuji?
2. Bagaimana karakteristik dan kemampuan sistem diuji?
3. Bagaimana klasifikasi masukan yang baik untuk uji sistem?
4. Apakah sistem sensitif terhadap masukan tertantu?
5. Bagaimana batasan kelas data dapat terisolasi dengan baik?
6. Pada batasan apa saja sistem dapat melakukan toleransi?
7. Apa pengaruh yang mungkin terjadi pada kombinasi data yang ada dalam sistem saat sistem berjalan / beroperasi.
Metode Black Box dilakukan tanpa melihat source code program dan dijalankan oleh tester atau user untuk mengamati pakah program tersebut telah menerima input, memproses dan menghasilkan output dengan benar. (Jogiyanto, 2004). Pengujian pada Black Box berusaha menemukan kesalahan seperti :
1. Fungsi-fungsi yang tidak benar atau hilang,
2. Kesalahan Interface / Tampilan,
3. Kesalahan dalam struktur data atau akses database eksternal, 4. Kesalahan kinerja,
5. Inisalisasi dan kesalahan termin.
