Untuk mengetahui jumlah defect yang terjadi dalam suatu PENGUJIAN disebut

1.1 Apa itu Testing Testing adalah proses yang dibuat sedemikian rupa untuk mengindentifikasikan etidaksesuaian hasil sebuah sistem informasi dengan hasil yang diharapkan.  Testing dilakukan untuk memastikan kualitas (quality assurance) yaitu menguji apakah sistem informasi yang dihasilkan sesuai dengan Testing dilakukan untuk memastikan kualitas (quality assurance)  Proses menganalisa suatu entitas software untuk mendeteksi perbedaan antara kondisi yang ada dengan kondisi yang diinginkan(defect) dan mengevaluasi fitur-fitur dari entitas software.(Standar ANSI/IEEE 1059)  Testing software adalah proses pengoperasian SW dalam suatu kondisi yang dikendalikan,untuk: 1. Verifikasi berlaku sebagaimana mestinya 2. Mendeteksi error, dan Validasi, apakah sudah memenuhi keinginan user 3. Verifikasi :pengecekan/pengetesan entitas-entitas, termasuk software,untuk pemenuhan dan konsistensi dengan melakukan evaluasi hasil terhadap kebutuhan yang telah ditetapkan 4. Validasi : melihat kebenaran sistem, apakah proses yang telah ditulis dalam spesifikasi adalah apa yang sebenarnya. 5. Deteksi error :testing untuk mendeteksi kesalahan secara insentif, yaitu menentukan apakah suatu hal tersebut terjadi bilamana tidak seharusnya terjadi . Alhasil melalui pengetesan terhadap system akan dapat : • Meningkatkan kepercayaan, tingkat resiko yang dapat diterima • Menyediakan informasi yang dapat mencegah terulangnya error • Menyediakan infromasi untuk mendeteksi error secara dini • Mencari error dan kelemahan/keterbatasan sistem. • Mencari sejauh apa kemampuan dari sistem • Menyediakan informasi untuk kualitas produk software 1.1.1. Prinsip testing • Testing yang komplit tidak mungkin • Testing merupakan pekerjaan yang kreatif dan sulit • Alasan yang penting diadakan testing adalah untuk mencegah terjadinya error • Testing berbasis pada resiko • Testing harus direncanakan • Testing membutuhkan independensi Testabilitas software adalah seberapa mudah suatu program komputer dapat dites (James Bach) • Operability Semakin baik software bekerja,akan membuat software dites dengan lebih efisiensi • Observability Apa yang anda lihat adalah apa yang anda tes • Controllability Semakin baik kita dapat mengendalikan software, semakin banyak testing dapat diotomatisasi dan dioptimalisasi • Decomposability Dengan pengendalian batasan testing, dapat lebih cepat dalam mengisolasi masalah dan melakukan testing ulang. • Simplicity Semakin sedikit yang dites, semakin cepat dilakukan tes • Understandability

Semakin banyak infromasi yang kita miliki, akan dapat melakukan test lebih baik.

1.1.2 Beberapa Defect Software Terdapat 13 kategori defect software (Kaner,Falk,Nguyen[KAM93A]): a. User Interface error-sistem memberikan suatu tampilan yang berbeda dari spesifikasi b. Erroe handling- perlakuan terhadap error bila terjadi c. Boundary- related error- perlakukan terdapat nilai batasan dari jangkauan mereka yang tidak benar d. Calculation error – perhitungan aritmatika dan logika yang mungkin tidak benar e. Initial and Later states – fungsi gagal pada saat pertama digunakan atau sesudah itu f. Control flow error – pilihan terhadap apa yang dilakukan berikutnya tidak sesuai untuk status saat ini. g. Error in handling or interpreting data – melewatkan dan mengkonversikan data antar sistem h. Race condition – bila dua event diproses maka salah satu akan diterima berdasarkan prioritas sampai pekerjaan selesai dengan baik, baru pekerjaan berikutnya. i. Load condition – saat sistem dipaksa maksimum, amsalh akan mulai muncul, seperti arrays, overflow, diskfull. j. Hardaware –antar muka dengan suatu device mungkin tidak dapat beroperasi dengan benar. k. Source and Version Control – program yang telah kadarluarsa mungkin dapat digunakan lagi bila ada revisi. l. Documentasi- penggunaan tidak dapat melihat operasi yang telah dideskripsikan dalam dokumen panduan

m. Tetsing error-tester membuat kesalahan selama testing dan berpikir bahawa sistem berkelakukan tidak benar.

1.2. Mengapa perlu pengujian? Persepsi umum tentang pengujian adalah bahwa ini hanya terdiri dari pelaksanaan, misalnya mejalankan perangkat lunak. Itu merupakan bagian dari pengujian, tapi bukan keseluruhan kegiatan pengujian. Kegiatan pengujian ada pada sebelum dan sesudah eksekusi pengujian :kegiatan seperti perencanaan dan pengendalian, memilih ketentuan pengujian, merancang kasus pengujian dan hasil pengecekan, mengevaluasi criteria hasil, melaporkan pengujian proses dan sistem selama pengujian, dan penyelesaian (setelah fase pengujian telah dilengkapi). Pengujian juga mencakup pengamatan dokumen (termasuk kode sumber ) dan analisis statis. Baik pengujian dinamis maupun statis, bias digunakan sebagai alat untuk mencapai tujuan yang sama, dan akan menyediakan informasi yang bertujuan untuk meningkatkan sistem untuk diuji, dan proses pengembangan serta pengujian. Terdapat beberapa tujuan pengujian: • Mencari tahu kerusakan • Mencapai keyakinan diri menyangkut tingkat kualitas dan penyediaan informasi. • Mencegah kerusakan Proses pemikiran untuk merencanakan pengujian lebih awal dalam daur hidup (memperbaharui dasar pengujian melalui rancangan pengujian) dapat membantu mencegah kerusakan berkaitan dengan kode. Pengamatan dokumen juga membantu mencegah kerusakan muncul dikode. Perbedaan sudut pandang pengujian membutuhkan objek yang berbeda. sebagai

Contoh, dalam pengembangan pengujian(komponen, pengujian integrasi dan sistem), objek utama bias menghasilkan kelalaian sebanyak mungkin sehingga kerusakan diperangkat lunak teridentifikasi dan bias diperbaiki. Dalam pengujian penerimaan, objek utama dapat memastikan bahwa sistem bekerja seperti yang diharapkan, untuk mencapai keyakinan bahwa telah memenuhi syarat. Dalam beberapa kasus objek utama pengujian dapat memastikan kualitas perangkat lunak (tanpa bermaksud memperbaiki kerusakan), untuk memberi informasi kepada stakeholder mengenai resiko melepaskan sistem pada waktu yang ditentukan.

1.3. Kenapa Testing diperlukan? 1.3.1. Konteks sistem Software

Sistem software sudah menjadi bagian dalam kehidupan dan menjadi kebutuhan untuk meningkatkan kinerja pada karyawan dan bisnis. Sistem memerlukan suatu perawatan dan berbaikan secara berkala sehingga program tidak banyak menimbulkan masalah, baik proses transaksi, proses bisnis seperti penggunaan komputer untuk kemudahan pada pekerjaan.

1.3.2. Beberapa Penyebab kegagalan software Kesalahan dalam mendesain dan analisa dapat mengakibatkan kegagalan pada sistem. Programmer dapat membuat kesalahan dalam pengkodean, pada sebuah program, atau dalam sistem sehingga terjadi kegagalan atau ketidak efectifan sistem yang digunakan dalam proses bisnis. Kegagalan dapat disebabkan oleh kondisi lingkungan seperti radiasi, magnetis, medan magnet dan polusi dapat meyebabkan kesalahan program atau mempengaruhi kondisi perangkat lunak atau perangkat keras.

1.4. Prinsip-prinsip Pengujian Umum

Prinsip 1-Pengujian Menunujukkan Adanya Kerusakan
Pengujian bisa menunjukkan bahwa kerusakan itu ada, tapi tidak bisa membuktikan bahwa tidak adanya kerusakan. Pengujian mengurangi kemungkinan kerusakan tertinggal di perangkat lunak, tapi walaupun tidak adanya kerusakan yang ditemukan, itu bukan merupakan bukti ketepatan.

Prinsip 2-Pengujian secara mendalam adalah Mustahil
menguji segalanya(semua kombinasi input dan prakondisi) tidak berlaku untuk beberapa kasus. Disamping pengujian mendalam,resiko analisis dan prioritas harus digunakan untuk memfokuskan tujuan pengujian.

Prinsip 3-Pengujian Awal
Pengujian harus dilakukan sedini mungkin bagi perangkat lunak atau daur hidup pengembangan sistem, dan harus difokuskan pada tujuan yang telah ditentukan.

Prinsip 4-Pengelompokkan Kerusakan
Beberapa modul berisi sebagian besar kerusakan ditemukan selama pra pengujian, atau bertanggung jawab terhadap sebagian besar kelalaian operasional. Kerusakan dapat dikelompokan dengan besarnya kerusakan tersebut.

Prinsip 5-Pradoks Pestisida

Bila sebuah pengujian yang sama dilakukan berulang kali, beberapa kasus pengujian yang sama tidak akan menemukan kerusakan baru lagi.untuk menyelesaikan “Raradoks Pestisida” ini, harus diamati dan diperbaharui secara rutin.

Prinsip 6-Pengujian Bergantung pada Keadaan
Pengujian dapat dibedakan dilihat dari kompleksitas sistem dan keadaan perangkat lunak serta kapasitas sistem tersebut. Contoh perangkat lunak keamanan tingkat tinggi berbeda dengan situs e-commerce.

Prinsip 7-Pemikiran tanpa kesalahan
Menemukan dan memperbaiki kerusakan tidak akan membantu jika sistem yang dibangun tidak dapat digunakan dan tidak memenuhi kebutuhan serta harapan pengguna.

2.1. Dalam pengujian perangkat lunak terdapat, 3 Tahapan dalam Testing • Unit Testing • System Testing • Acceptance Testing

Terdapat dua cara disain Test Case, yaitu:

• Dengan berdasarkan pada fungsi yang dispesifikasi dari produk, tes dapat dilakukan dengan mendemontrasikan tiap fungsi telah beroperasi secara penuh sesuai dengan harapan. • Dengan pengetahuan operasi internal dari produk, tes dapat dilakukan untuk memastiskan semua komponen berjalan semestinya, operasi internal berlaku berdasarkan pada spesifikasi dan semua komponen internal telah cukup diperiksa.

Pendekatan cara pertama disebut dengan black box testing, dan pendekatan cara kedua disebut white box testing.

PERANCANGAN SISTEM INFORMASI

2.1. PERANCANGAN INTERATIF, PENGUJIAN, DAN EVALUASI Participatory Design dan Analisis Tugas • Participatory design adalah perancangan yang melibatkan pemakai • Dampak Keterlibatan pemakai dalam perancangan : – Menghasilkan lebih banyak informasi yang akurat tentang tugas – Memberi kesempatan untuk berargumen atas keputusan rancangan – Memberi rasa keikutsertaan yang membentuk investasi ego dalam implementasi yang sukses – Potensi untuk meningkatkan penerimaan pemakai atas Sistem Final • Perancangan adalah hal yang kreatif dan tak dapat diduga. Carroll dan Rosson menyebutkan karakteristik perancangan sebagai berikut : – Perancangan adalah suatu proses; bukan merupakan keadaan dan tidak dapat direpresentasikan dengan memadai oleh statistik – Proses perancangan adalah non-hierarkis; tidak ketat bottom-up maupun top-down – Proses perancangan adalah transformasional secara radikal ; melibatkan pengembangan solusi sebagian dan sementara yang akhirnya mungkin tidak berperan dalam rancangan akhir

– Perancangan secara intrinsik melibatkan penemuan tujuan-tujuan baru

2.1.1. Sasaran Perancangan Sistem Informasi • Menentukan secara tepat banyaknya Informasi yang dibutuhkan User • Melakukan Standarisasi • Pengembangan Sistem Pengendalian

• Mengurangi Fungsi-fungsi yang terduplikasi

2.1.2. Panduan Dasar Perancangan Sistem • Apakah Sistem berjalan akan dikembangkan atau disederhanakan • Apakah sejumlah langkah telah dijalankan • Menghindari Fungsi yang mengalami Redundansi & Duplikasi • Sistem baru harus lebih lengkap, bekerja lebih cepat, menyeluruh, dan lebih murah dibanding Sistem berjalan • Laporan yang dikeluarkan Sistem Baru harus benar-benar memenuhi kebutuhan Informasi User dan Management • Diperlukan Sarana yang mempermudah pengendalian terhadap Implementasi Sistem 2.1.3 Prinsip Pemgembangan Sistem • Enduser harus dilibatkan secara aktif • Pendekatan Fase pekerjaan perlu dilakukan • Fase tersebut dapat saling tumpang tindak (parallel) • Sistem yang dihasilkan merupakan investasi Perusahaan • Management harus berani menyetop suatu pekerjaan pengembangan sistem yang dirasakan tidak layak

• Dokumentasi merupakan bagian yang tidak terpisahkan dari hasil akhir suatu proyek pengembangan sistem

2.1.4 Proses Pengembangan Kembangkan spesifikasi dokumen – Gunakan orientasi tugas – Gunakan rancangan minimalis – Tangani pembaca yang beraneka ragam – Tentukan tujuan – Organisasikan informasi dan kembangkan visualisasi – Perhatikan tata letak dan warna 2. Buat prototipe 3. Buat draft (bentuk kasar) 4. Perbaiki 5. Kaji ulang 6. Uji di lapangan 7. Terbitkan 8. Lakukan ulasan pascaproyek

9. Pelihara

2.1.4.1. Prototipe System • User dapat lebih mudah untuk menilai sistem dalam bentuk model yang sudah ada, daripada dalam bentuk teori • Langkah-langkah Pembuatan : – Identifikasi keperluan user dan feature-feature yang perlu – Buat / kembangkan prototype – Terapkan prototype perhatikan apa yang perlu diubah (penambahan dan pengurangan) – Perbaiki prototype berdasarkan informasi dari user

– Ulangi langkah-langkah di atas (sesuai keperluan) untuk menghasilkan sistem yang memuaskan.

Bagan Prototipe

Pengembangan Perangkat Lunak

2.1.5. Terdapat 3 Pilar Perancangan sistem 1. Guidelines document, meliputi : -Tata letak layar -Piranti masukan dan keluaran -Urutan aksi – Pelatihan 2. User-Interface Software Tools (UIMS dan Rapid Prototyping Tools) -Pelanggan dan pemakai belum mempunyai gambaran yang jelas bagaimana sistem akhir akan terlihat – Kesulitan dihindari dengan pemberian kesan realistik tentang seperti apa bentuk sistem akhir 3. Usability Laboratories and Iterative Testing -Harus dilakukan uji pilot kecil dan besar dari komponen-komponen sistem sebelum dirilis ke pelanggan

-Uji pilot membandingkan alternatif-alternatif rancangan, membedakan sistem baru dengan prosedur lama, atau mengevaluasi produk-produk kompetitif

2.1.6. Prinsip merancang tampilan Layar • Organisasi Layar • Caption dan Field Data Justification • Headings • Spacing • Title dan Screen Identifier

• Warna

2.1.6.1.Organisasi Layar 1. Minimasi gerakan mata baik dari atas ke bawah, atau kiri ke kanan 2. Dua elemen kunci adalah Caption dan Field Data 3. Caption ditulis lengkap dengan huruf besar (uppercase) dan densitas normal. Huruf kecil (lowercase) dipergunakan untuk caption yang panjang

4. Field data tunggal, letakkan caption di kiri field data dan dipisahkan dengan simbol yang unik dan spasi.

2.1.6.2. Heading Untuk section heading, tempatkan section heading pada baris di atas field data terkait. Posisi caption minimum 5 spasi masuk kedalam terhadap posisi heading.

Ditulis dalam uppercase.

2.1.6.3. Warna Bila digunakan dengan tepat pemakaian warna dapat mengorganisasikan data, memfokuskan perhatian, menegaskan perbedaan, menambah daya tarik. Untuk mendapatkan diskriminasi terbaik pilih 4 sampai dengan 6 warna dari spektrum warna, yaitu sbb: Merah, Orange, Kuning, Kuning-Hijau, Hijau, Biru-Hijau, Biru, Ungu. Petunjuk dalam menggunakan warna : • Untuk diskriminasi antara item, gunakan merah, kuning, hijau, biru dan putih. • Gunakan warna cerah untuk penegasan, warna gelap untuk kurang ditegaskan. Gradasi kecerahan warna mulai dari terendah: Putih, Kuning, Hijau, Biru, Merah. • Untuk menonjolkan perbedaan, pakai warna yang kontras, misalnya: Merah dengan hijau atau Biru dengan Kuning. • Untuk menunjukkan persamaan, gunakan warna yang senada misalnya : Orange dengan Kuning, Biru dengan Ungu • Gunakan tidak lebih dari 3 warna plus warna putih pada layar untuk satu saat yang sama • Gunakan warna yang hangat untuk meminta perhatian, tindakan atau respon misalnya: Merah, Orange, Kuning • Gunakan warna yang sejuk (Hijau, Biru-Hijau, Biru, Ungu) untuk menjelaskan status dan latar belakang informasi • Untuk teks gunakan warna kuning atau hijau

• Untuk latar belakang layar gunakan merah, biru atau hitam. Warna Biru pilihan terbaik

Catatan • Lakukan konfirmasi kepada user. Misal : – Merah : Hilang, berhenti atau berbahaya – Kuning : Hati-hati – Hijau : Lanjutkan, biasa saja • Perubahan arti dari warna akan dapat menimbulkan kesukaran bahkan error karena

salah arti

2.1.6.3.1 Pedoman penggunaan warna : Gunakan warna secara konservatif • Batasi jumlah warna • Kenali kekuatan warna sebagai teknik pengkodean (coding) • Pastikan bahwa color coding mendukung tugas • Tampilkan color coding dengan usaha pemakai yang minimal • Tempatkan color coding di bawah kendali pemakai • Rancang untuk monokrom dulu • Gunakan warna untuk membantu pemformatan • Gunakan color coding yang konsisten • Perhatikan ekspektasi umum tentang kode warna • Perhatikan masalah pemasangan warna • Gunakan perubahan warna untuk menunjukkan perubahan status • Gunakan warna pada tampilan grafis untuk kerapatan informasi yang lebih tinggi

• Waspada atas kehilangan resolusi pada tampilan warna

Perpaduan Warna yang baik

Perpaduan Warna yang tidak baik

2.1.7. Perancangan Sistem
2.1.7.1 Prosedure sistem berjalan

2.1.7.2. Menggunakan DFD (Data Flow Diagram)

2.1.7.3. Penggunaan BUPD (Bagan Umum Pengolahan Data)

Digunakan untuk mengambarkan secara keseluruhan kebutuhan aliran data dari input-proses-output

2.1.7.4. Penggunaan DFD pada sistem yang akan dibangun

2.1.8. Perancangan Database

“Model Data merupakan bagian kecil dari spesifikasi sistem secara keseluruhan, tetapi mempunyai peranan penting dalam menentukan kualitas dan kelangsungan hidup sistem “( Coad dan Yourdon )

Mengapa Perancangan database sangat penting? 1.Mengekspresikan permintaan pemakai 2.Mengantisipasi anomali-anomali dalam Memanipulasi Data 3.Menyederhanakan pemrograman 4. Mengurangi biaya pengeluaran 5. Mempermudah pemahaman informasi

6. Meningkatkan performance

DAMPAK DARI KESALAHAN PERANCANGAN 1. Hilangnya Informasi 2.Sukarnya memodifikasi database 3.Memerlukan waktu yang lama dalam penulisan program 4.Memerlukan waktu yang lama dalam pengaksesan database 5.Menambah volume pekerjaan dalam sistem database

6.Pemborosan waktu bagi Administrator

2.1.8.2. Tujuan Perancangan Database 1. Menyajikan data dan hubungan antar data yang diperlukan oleh pemakai dan aplikasi 2. Mempermudah pemahaman informasi 3. Melengkapi model data yang mendukung transaksi-transaksi yang diperlukan 4. Mendukung proses permintaan

5. Meningkatkan performance

2.1.8.3 .Proses Perancangan Database Logika

2.1.8.3.1.Transformasi Data * Transformasikan atribut-atribut dalam setiap Entity ke dalam suatu relasi * Bila ada Atribut Multivalue buat relasi baru * Bila Unary Degree , periksa cardinality rationya, tempatkan foreign key atau buat relasi baru * Bila Binary Degree, periksa cardinality ratio dan participation constraintnya, tempatkan foreign keynya atau buat relasi baru * Bila Ternary Degree buat relasi baru

* Bila Terdapat Weak Entity , Primary Keynya gabungan dari salah satu atribut dengan Primary Key dari Entity induknya

PENGUJIAN DAN IMPLEMENTASI

3.1. Implementasi Sebuah Sistem Dalam proses akhir dari pengembangan sebuah sistem yaitu melakukan implementasi dengan tahapan sebagai berikut: 1.Training Personal 2. Konversi Sistem 3. Review post-implementation 4. Dokumentasi

5. Dukungan lain

3.1. a. Tipe Training: disesuaikan dengan keadaan lingkungan implementasi sistem: -Eksternal Training: kursus dr vendor pelatihan • Internal Training: On the Job Training • Belajar Sendiri 3.1. b. Memilih Staf yang akan dilatih – Terdiri dari tiga kelompok User: • Teknisi & Administrator yang akan bertugas merawat sistem • Application user (user pd umumnya)

• General Manager

3.1.c. Konversi terdapat 4 macam: • Konversi Langsung • Konversi Paralel • Konversi phase-in

• Konversi Pilot

3.1.d. Evaluasi Sistem Bertujuan untuk mendapatkan cara meningkatkan efisiensi dan efektifitas sistem baru, serta memberikan informasi untuk pengembangan sistem mendatang. Biasanya dilakukan setelah dua hingga enam bulan instalasi -> sudah terdapat periodik pelaporan serta isu sistem masih baru 3.1.2.a. Area Peninjauan Evaluasi Sistem (Faktor Sistem) – Faktor kelayakan TELOS (Technical, Economical, Legality, Operation, Schedule) Teknologi pendukung; • Pendanaan utk biaya teknologi, operasional, pemeliharaan, • Operasinal sistem yg tidak melanggar hukum, kesesuain jadwal. -Keterampilan personal dlm Faktor strategik PDM (Productivity, Differentiation, Management ) • Sudah tercapainya produktivitas setelah implementasi sistem baru • Kontribusi terhadap diferensiasi produk dan layanan • Dukungan informasi utk peningkatan kualitas perencanaan, pengontrolan, dan pembuatan keputusan manajemen, -Faktor rancangan MURRE (Maintenability, Usability, reusability, extenability) • Dokumentasi sudah komprehensive, jelas dan uptodate • Mendukung CMS (Change Management System) • Module untuk user sudah terpenuhi • Terpenuhinya dukungan ke user • Modul perangkat lunak dapat digunakan kembali • Terbebas dari fault/error

• Adaptif dan fleksibel

3.1.2.b. Komponen Rancangan Sistem: Output • Output harus sesuai, relevan, akurat dan dapat digunakan kembali • Kemanan pengguna output bagi user yg tidak berhak • Kemudahan akses • Sesuai dengan kognitif user • Ketepatan edit dan identifikasi laporan Input • Form memenuhi kaidah pedoman dan spesifikasi rancangan • Verifikator data input

• Manual pengisian form

Proses • Pengujian terhadap semua proses • Peninjauan terhadap prosedur dan dokumentasi • Prosedure pengoperasian • Reliability sistem • Platform Teknologi • Peripheral, workstation, processor, dan jaringan, • Membandingkan kinerja dengan rancangan Membutuhkan komponen penunjang: • Job accounting system • Hardware monitoring • Software monitoring • Konfigurasi teknologi yang optimal • Respon time yang acceptable • Keakuratan Estimasi • Waktu: menggunakan tool spt PERT, Gannt, atau lainnya. • Biaya yg sebenarnya sesuai dg yg diestimasi Manfaat • Tingkat dukungan: • Sumber daya tersedia • Manajemen puncak

• Pelatihan (teknik pelatihan, user, tutor)

3.1.2.c. Dokumentasi Program Dokumentasi Proses

Merekam proses pengembangan dan perawatan. Isi dokumentasi proses adalah: perencanaan, jadwal, kualitas proses, standard proses.

Dokumentasi Produk
Menggambarkan produk yang sedang dikembangkan dr sudut pandang engineer pengembang/perawatan. Yg termasuk dokumentasi produk adalah: user manual, help.

1.Pengantar • Tujuan dari produk • Lingkungan operasi • Fungsi secara umum • Fitur Khusus • Keterbatasan • Keterangan dan notasi dokumen serta terminologi 2. Instalasi • Persyaratan minimal sistem yang dibutuhkan • Menyalin dan memback-up • Proses instalasi • Konfigurasi/kustomisasi produk 3. Tutorial Penjelasan langkah-demi langkah dengan contoh • Penjelasan tiap contoh • Pengembangan dari contoh dasar • Penggunaan on-line Help 4. Instruksi detail • Keluaran dari produk • Masukan untuk produk • Pengoperasian produk • Penanganan error • Fungsi khusus 5. Detail Teknis • Prinsip dari operasi • Fitur lanjutan • Algoritma utama yang digunakan • Struktur data utama • Modifikasi produk Cara memperoleh dukungan teknis dan informasi lanjutan • User Manual Source Code • Penamaan variable, constant, procedure. Function yang jelas dan konsisten • Memberi keterangan pada header setiap procedure, yang berisi: • Fungsi dari procedure • Variable local masukan, dan keluaran • Variable global yang digunakan dan yang dipengaruhi. • Pada Header Program diberi: Nama penulis program Editor Compiler dan Library yang digunakan Versi dan upgrade history Tanggal pembuatan software

Deskripsi singkat tentang software

3.1. MENGUJI SISTEM INFORMASI 3.1.1 Tujuan melakukan pengujian • Pengujian perangkat lunak adalah proses yang harus mengikuti pola tertentu dan dirancang secara matang. Proses ini dilakukan oleh Team yang bertanggang jawab atas kuantitas dan keandalan yang tinggi dari perangkat lunak yang dibuat setelah dapat menemukan dan memperbaiki error

• Tujuannya adalah untuk menghasilkan perangkat lunak yang handal. Tetapi tidak berarti error hilang sama sekali. Selalu masih terdapat kemungkinan tidak terdeteksinya error meskipun telah dilakukan pengujian secara teliti dan seksama

3.1.2. Proses Pengujian

Area yang bisa dikenal oleh uji kasus adalah : • Field • Record • File • Data entry • Control • Aliran program Jenis-jenis error dan kaitannya dengan keandalan Fatal error : – Crash – Logic

– Hang

¨ Serious error: – Menghasilkan keluaran yang tidak benar ¨ Minor error – User tidak puas terhadap hasil program

Penyebab error disebut Bug. Bila fatal error ditemukan maka keandalan program dipertanyakan, kemungkinan besar harus dirancang dan diprogram ulang, Bisa jadi dihancurkan sama sekali

• Minor error dapat dengan mudah diatasi, dengan kesimpulan : – Keandalan program cukup baik

– Uji kasus tidak memadai sehingga tidak dapat mendeteksi fatal dan serious error

• Debugging Adalah kegiatan menghilangkan Bug, yang memang harus dilakukan justru karena keberhasilan pengujian. Debugging mencoba untuk mencocokan antara simptom dengan problem, sehingga dapat dilakukan koreksi error secara menyeluruh

3.1.3. Jenis-jenis pengujian

1.White Box Testing – Mengetahui cara kerja dari program tersebut (terstruktur logik), sehingga dapat mengembangkan uji fungsional program yang efisien dan efektif. – Lakukan pengujian pada sekelompok program yang berstruktur SEQUENCE, IF-THEN-ELSE, DO-WHILE dan DO-UNTIL – Perlu diuji atas command dan percabangan berikut ini: • Select • Open/Close • Copy replacing • IF • Perform until dan perform while • Call Konsep Pengujian Basis Path (1) • Merupakan bagian dari pengujian White Box dalam hal pengujian prosedur-prosedure • Mempergunakan notasi aliaran grapt (node,link unutk merepresentasikan sequence, if, while, until); • Konsep kompleksitas cyclomatic antar lain cara perhitungan daerah tertutup pada graph planar dimana dapat menhubungkan batas atas jumlah pengujian yang harus direncanakan dan dieksekusi unutk menjamin pengujian seluruh statement program • Memunculkan kasus-kasus yang akan diuji dengan membuat daftar lintasan kasus pengujian berdasarkan kompleksitas & cyclomatic yang didapat

• Membuat alat bantu matrik graph untuk membantu pengawasan pengujian.

2.Black Box Testing – Mendemontrasikan bahwa fungsi perangkat lunak berjalan sebagaimana mestinya, keluaran yang dihasilkan sesuai dengan masukannya, database diakses secara benar dan diremajakan. – Kasus yang digunakan terdiri dari satu kumpulan kondisi masukan baik yang valid maupun yang invalid. Baik whitebox maupun black box berusaha mengungkap error selama pemrograman, tetapi khusus black box yang fokus pada pengungkapan error yang terjadi saat implementasi user requirement dan spesifikasi rancangan sistem.

– Karena itu black box testing sesuai untuk pengujian saat integrasi, sistem dan serah terima (acceptance) dibandingkan uji modul

3.1.3.1 UJI KLAS EKIVALEN • Uji jenis ini merupakan kunci dari black box testing • Contoh : – Suatu data hanya bisa diisi oleh angka 1 sampai dengan 50. maka uji dengan angka 1, 50 (batas dari klas), angka negatif, 0, dan angka > 50 – Uji apakah control total telah dibuat dengan benar – Uji memproses transaksi yang peka tanpa otorisasi, apakah sistem akan menolak? – Lakukan uji numerik alpabet dan karakter khusus – Masukan nilai dengan tanda negatif, apakah sistem mampu menanganinya. – Bagi total atau jumlah dengan nol – Lakukan validitas untuk field data kunci – Lakukan pemeriksaan range dan reasonableness – Periksa urutan transaksi dengan benar – Masukan beberapa field dengan data yang tidak lengkap atau hilang – Coba untuk baca dan tulis pada file yang salah – Masukan nomor rekening dengan check digit yang telah ditentukan, periksa

apakah sistem memproses dengan benar?

Tindakan yang harus dilakukan bila error telah dideteksi ? • Laporan error dan Penjelasan • Jenis Laporan : – Suggestion : Bukan berarti salah, tetapi ada yang bisa diperbaiki – Design Error : Biasanya berupa error pada antar muka dengan user – Coding Error : Kesalahan yang tidak sengaja dilakukan pemrograman – Documentation Error : Source code dan dokumentasi tidak sesuai – Querry : Program melakukan sesuatu yang pengujiannya tidak faham maksudnya, perlu klasifikasi lanjutan dengan pemrograman

– Attachments : Berupa disk berisi test data, hasil cetakan, catatan atas pelaksanaan uji, dan sebagainya

3.1.3.2. Tahapan Pengujian 1. Module Testing 2. Integration Testing 3. System Testing

4. Acceptance Testing

Module Testing • Adalah proses pengujian unit terkecil dari seluruh program sebelum disatukan bersama menjadi program utuh. Merupakan bagian dari whitebox testing • Tujuan module testing adalah: • Pelaksanaan setiap command pada sebuah modul. • Menelusuri setiap path logika modul. Hitung ulang semua command komputasi • Uji setiap modul dengan sekumpulan data input

• Karena tidak semua pengujian dapat dilakukan, maka konsentrasi ditujukan pada area yang memiliki resiko terbesar. Modul-modul di plot pada kisi yang bisa menggambarkan besarnya peluang error dan tingkatan pengaruhnya

Integration Testing • Dilakukan dengan menggabungkan modul dengan modul lainnya fokusnya pada hirarki dari modul, khususnya antar-muka antar modul. • Alasan perlunya pengujian jenis ini : • Data dapat hilang pada saat melewati antar muka • Fungsi tidak berjalan sebagaimana mestinya ketika digabungkan

• Modul yang satu ternyata memberikan pengaruh yang kurang baik pada modul lainnya

• Karena modul bukan stand-alone program, maka diperlukan Stub dan Driver

Cara pengujian dengan Stub dan Driver • Top Down Penyerahan modul tingkat atas dan stub sebagai basis pengujian. Modul diintegrasikan dengan pergerakan ke bawah melalui kendali hirarki, dimulai melalui modul eksekutif utama. Setelah modul selesai ditulis untuk setiap tingkatannya, Sub diganti dengan modul sebenarnya. Demikian seterusnya hingga semua modul selesai ditulis. Program secara keseluruhan dapat diuji dengan baik. • Bottom Up Modul tingkat paling bawah pada diagram terstruktur ditulis terlebih dulu dan diuji melalui driver yang memadai. Bersandar pada penyelesaian modul paling bawah dan driver sebagai basis pengujian integrasi. Demikian seterusnya hingga mencapai modul eksekutif utama

TOP-DOWN

BOTTOM DOWN

System Testing • Adalah proses pengujian peng-gabungan perangkat lunak yang akan mendukung fungsi sistem secara keseluruhan • System Testing meliputi : – Recovery Testing – Security Testing

– Stress Testing

Acceptance Testing

• Evaluasi dari sistem untuk menguji apakah sudah dapat memenuhi user requirement sesuai dengan kondisi operasionalnya

Ada 2 jenis pengujian : a. Alpha Testing Dilakukan pada lingkungan operasional alami dengan diawasi oleh profesional sistem untuk dicatat error dan masalah-masalah yang muncul Dua teknik yang dapat dipakai : – Usability Labs

– Usability Factors Checklist

b. Beta Testing
Sama dengan alpha, tetapi tanpa pengawasan dari profesional user mencatat se-mua masalah (baik yang riil maupun imaginasi) dan melaporkan pada pemrograman sistem secara periodik Modifikasi dibuat agar sistem dapat siap dipakai pada implementasi secara penuh