Modul Standar untuk digunakan dalam Perkuliahan di Universitas Mercu Buana

Transkripsi

1 MODUL PERKULIAHAN Testing dan Implementasi SI Modul Standar untuk digunakan dalam Perkuliahan di Universitas Mercu Buana Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh Disini diisi Fakultas Program Tim Dosen penerbit Modul Studi Sistem 1 Informasi Abstract Define Software Testing Scope, Purpose and Objective. Introduction for Testing in Software Engineering Kompetensi Understanding purposes and objective of Software Testing in Industri 1

2 Materi Testing Terminologi Software : seluruh komponen pengolahan data yang dapat membantu memecahkan masalah diluar dari perangkat hardware yang meliputi system design, program dan prosedur. Beberapa gambaran umum tentang perangkat lunak antara lain : 1. Perintah (program computer) yang bila dieksekusi memberikan fungsi dan unjuk kerja seperti yang diinginkan. 2. Struktur data yang memungkinkan program memanipulasi informasi secara proporsional. 3. Dokumen yang menggambarkan operasi dan kegunaan program. Jenis-jenis software antara lain : 1. CP/M-80 (control program for Microprocecor 8080) di pakai pada komputer Appel / Intel CP/m-86 (control program for Microprocecor 8086) di pakai untuk intel PC-Dos (Personal Computer Disk Operating System) di buat oleh Microsoft Corppration 4. MS-DOS (Microsoft Disk Operating System) pengembangan dari PC-DOS 5. MS-Windows dibuat oleh Microsoft Corporation, mulai dari Windows 3.1, Windows NT, Windows 95, Windows 98, Windows 2000 Profesional, dan Windows XP yang merupakan perbaikan dari versi sebelumnya, komponen strategisnya antara lain : Fleksibel dengan hardware yang ada saat ini Menggunakan konfigurasi hardware otomatis Prosedur instalasi mudah Fasilitas jaringan network Telah memperbaiki bug-bug pada versi sebelumnya. 1. Unix adalah sistem operasi yang dikembangkan oleh Dennis M. Ritche dan Ken Thompson, di tulis dalam pemrograman bahasa C. 2. Linux. 3. Dll. Ada dua tipe produk perangkat lunak : 1. Produk generik 2. Produk pesanan (yang disesuaikan) Pengujian perangkat lunak adalah elemen kritis dari jaminan kualitas perangkat lunak dan merespresentasikan kajian pokok dari spesifikasi, desain dan pengkodean. Meningkatnya visibilitas perangkat lunak sebagai suatu elemen sistem dan biaya yang muncul akibat 2

3 kegagalan perangkat lunak, memotivasi dilakukannya perencanaan yang baik melalui pengujian yang teliti. Pengujian termasuk dalam teknik verifikasi dan validasi (V & V). Pengujian melibatkan pelatihan perangkat lunak dengan memakai data seperti data riil yang diolah oleh perangkat lunak. Tujuan akhir dari proses verifikasi dan validasi adalah menanamkan kepercayaan bahwa system perangkat lunak siap untuk tujuannya. Apakah yang dimaksud dengan pengujian perangkat lunak? Pengujian adalah proses menjalankan sebuah program dengan maksud menemukan kesalahan-kesalahan (error). Proses untuk menjalankan sebuah program komputer dan membandingkan tingkah laku yang sesungguhnya dengan yang diharapkan. Yang dimaksud membandingkan adalah menemukan bentuk penyimpanganpenyimpangan (jika ada). Antara lain membandingkan tingkah laku yang sesungguhnya dengan yang diharapkan. Layanan pengujian sebagai bentuk suatu rintangan untuk menyediakan produk yang berkualitas dalam mendapatkan pelanggan Pada saat V & V perangkat lunak, kesalahan pada perangkat lunak biasanya ditemukan dan kemudian diubah untuk membetulkan kesalahan tersebut. Proses debug ini seringkali terintegrasi dengan kegiatan verifikasi dan validasi lain. Bagaimanapun, pengujian (atau lebih umum verifikasi dan validasi) dan debug merupakan proses yang berbeda yang tidak harus diintegrasikan : 1. Verifikasi dan validasi adalah proses yang meyakinkan adanya kesalahan pada sistem perangkat lunak. 2. Debug merupakan proses yang menemukan dan membetulkan kesalahan tersebut. Tipe pengujian yang dapat digunakan pada berbagai tahap proses perangkat lunak : 1.Pengujian cacat (Defect Testing) Menetapkan keberadaan cacat sistem. Tujuannya untuk menemukan ketidak konsistenan antara program dan spesifikasinya. Dirancang untuk mengungkapkan adanya cacat pada sistem dan bukan untuk mensimulasi penggunaan operasionalnya. Bermanfaat bagi pemrogram dan menunjukkan cacat-cacat yang ada di kode (program). 2.Pengujian statistik Menguji kinerja dan keandalan program dan memeriksa bagaimana kerjanya pada kondisi operasional 3

4 Dirancang untuk menunjukkan input user yang sebenarnya dan frekuensinya. Kehandalan sistem dapat dilakukan dengan menghitung kegagalan sistem yang diteliti. Sasaran Pengujian Glen Myers menyatakan bahwa sasaran dari pengujian perangkat lunak adalah : 1. Pengujian adalah proses menjalankan suatu program dengan maksud menemukan kesalahan. 2. Pengujian yang baik adalah yang memiliki kemungkinan tinggi untuk menemukan kesalahan yang belum pernah ditemukan sebelumnya. 3. Pengujian yang sukses adalah pengujian yang mengungkap semua kesalahan yang belum pernah ditemukan sebelumnya. Satu hal yang perlu diingat/diperhatikan dalam pengujian terhadap perangkat lunak bahwa : Pengujian tidak dapat memperlihatkan kerusakan sistem, tetapi hanya dapat memperlihatkan bahwa ada kesalahan perangkat lunak. Kaner, Falk dan Nguyen mengusulkan atribut-atribut dari pengujian yang baik sebagai berikut : 1. Pengujian yang baik memiliki probabilitas yang tinggi untuk menemukan kesalahan. 2. Pengujian yang baik tidak redundan. 3. Pengujian yang baik seharusnya jenis terbaik 4. Pengujian yang baik tidak boleh terlalu sederhana atau terlalu kompleks. Tidak semua pengujian akan berhasil dengan baik. Masih ada beberapa kekurangan yang terdapat pada pengujian suatu perangkat lunak. Kekurangan-kekurangan tersebut antara lain : 1.Tidak pernah cukup melakukan banyak ujian yang layak. 2.Pengujian tidak akan menemukan semua kesalahan 3.Pengujian sulit dan menghabiskan banyak waktu 4.Pengujian sebagian besar masih merupakan tugas yang tidak resmi. 4

5 Prinsip-prinsip Pengujian Sebelum menetapkan metode pengujian, seorang ahli pada bidang software harus mengerti betul atau memahami prinsip dasar yang menuntun pengujian perangkat lunak. Prinsip-prinsip pengujian secara umum yang banyak dianut oleh para ahli perangkat lunak, antara lain : Seorang Programmer seharusnya tidak menguji programnya sendiri. Sebaiknya satu pengujian tidak hanya mengerjakan program yang dianggap benar, tetapi tidak mengerjakan yang dianggap salah. Tujuan dari pengujian adalah untuk menemukan kesalahan, bukan untuk menunjukkan bahwa program tersebut salah. Tidak ada sejumlah pengujian yang dapat menjamin bahwa program bebas dari kesalahan. Bagian-bagian dari program di mana terdapat banyak kesalahan yang telah ditemukan adalah suatu tempat yang baik untuk menemukan kesalahan yang lebih banyak. Tujuannya adalah bukan untuk mempermalukan programmer. Selain pernyataan diatas, Roger S. Pressman mendefinisikan sendiri mengenai prinsip-prinsip pengujian terhadap perangkat lunak : Pengujian harus sesuai dengan persyaratan konsumen. Para ahli harus betul-betul mengetahui spesifikasi dari produk (software) yang diinginkan konsumen. Pengujian harus direncanakan lama sebelum pengujian itu di mulai. Prinsip Pareto berlaku untuk pengujian perangkat lunak. 80 % kesalahan yang ditemukan, hanya dapat ditelusuri sampai 20 % dari semua modul program. Pengujian harus dimulai dari yang kecil dan berkembang ke pengujian yang besar. Pengujian berfokus dalam usaha menemukan kesalahan pada modul yang terintegrasi, dan akhirnya pad asistem secara keseluruhan. Pengujian yang sempurna tidak mungkin. Agar efektif, pengujian harus dilakukan oleh pihak ketiga yang independent (third party). Pengujian yang memiliki probabilitas tinggi untuk menemukan kesalahan. Pembuat sistem bukanlah orang yang paling tepat untuk melakukan semua pengujian bagi perangkat lunak. Kegagalan dan Kesalahan Kesalahan sistem tidak selalu mengakibatkan eror sistem, karena status salahnya mungkin bersifat sementara dan dapat diperbaiki sebelum terjadi perilaku yang merupakan eror. 5

6 Jenis kegagalan dan kesalahan pada sistem antara lain : Kegagalan sistem (system failure) Peristiwa yang terjadi pada suatu waktu ketika sistem tidak memberikan layanan sebagaiman diharapkan oleh user. Eror sistem (system eror) Perilaku eror sistem dimana perilaku, sistem yang tidak sesuai dengan spesifikasinya Kesalahan sistem (system fault) Status sistem yang tidak benar, yaitu status sistem yang tidak diharapkan oleh perancang sistem. Eror atau kesalahan manusia (human error) Perilaku manusia yang mengakibatkan kesalahan sistem. Bagaimana kesalahan tersebut mempengaruhi kita? Telah diketahui bahwa salah satu tujuan dari pengujian terhadap perangkat lunak, adalah untuk menemukan suatu kesalahan. Kesalahan-kesalahan tersebut mempunyai tingkatan-tingkatan yang diukur dengan istilah yang dimengerti oleh manusia. Tingkatan-tingkatan kesalahan tersebut dikategorikan sebagai berikut A. MILD (ringan) Gejala dari kesalahan yang mengganggu kita secara estetis Kesalahan pengejaan Kesalahan penempatan B. MODERATE (sedang) Kesalahan yang berpengaruh pada penampilan system Informasi yang menyesatkan C. ANNOYING (menjengkelkan) Kesalahan dari system karena adanya suatu virus. Nama yang terpotong Tagihan untuk Rp. 0,00 di cetak / dikirim 6

7 D. DISTURBING (mengganggu) Sistem menolak untuk menangani transaksi yang sah Kartu kredit yang dilaporkan tidak bisa digunakan E. SERIOUS (serius) Perhitungan yang salah Hal ini menghilangkan hubungan pada proses transaksi Tidak mencetak setiap pembayaran F. VERY SERIOUS (sangat serius) Kesalahan yang menyebabkan system melakukan transaksi yang salah Sebuah system kredit dapat melakukan kesalahan perhitungan. G. EXTREME (besar) Masalah yang tidak terbatas pada beberapa transaksi Sering berubah-ubah atau masalah yang tidak lazim H. INTOLERABLE (kurang tahan) Pertimbangan yang serius diberikan untuk mematikan system. I. CATASTROPHIC (bencana besar) Sistem yang salah 7

8 8

9 9

10 MODUL PERKULIAHAN Testing dan Implementasi SI Modul Standar untuk digunakan dalam Perkuliahan di Universitas Mercu Buana Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh Disini diisi Fakultas Program Tim Dosen penerbit Modul Studi Sistem 2 Informasi Abstract A method how to organize software development project Kompetensi Understanding Software Development a Life Cycle in Software Engineering. 1

11 Testability (Kemampuan Test) Testabilitas perangkat lunak adalah seberapa mudah sebuah program komputer dapat diuji. Karena pengujian sangat sulit, maka perlu diketahui apa yang dapat dilakukan untuk membuatnya menjadi mudah. Kadang-kadang pemrogram bersedia melakukan hal-hal yang akan membantu proses pengujian, dan membuat checklist (daftar periksa) mengenai masalah-masalah desain yang mungkin, fitur dan lain sebagainya yang dijadikan sebagai pedoman dalam melakukan pengujian. Beberapa checklist dibawah ini, akan membantu sebagai pedoman dalam kegiatan pengujian perangkat lunak : 1. OPERABILITY. (Mampu menjalankan/operasi.) Semakin baik hal tersebut dijalankan, pengujian akan semakin efesien. Sistem memiliki sedikit kesalahan. Tidak ada kesalahan yang menghalangi jalannya pengujian. Produk berkembang dalam tahapan fungsional (memungkinkan pengembangan dan pengujian secara simultan) 2. OBSERVABILITY(Kemampuan untuk mengamati/meneliti) Apa yang dilihat adalah apa yang diuji. Output yang berbeda dikeluarkan oleh masing-masing input. Tahap dan variabel sistem dapat dilihat atau diantrikan selama eksekusi. Sistem dan variabel yang lalu dapat dilihat atau diantrikan (misalnya, logaritma transaksi) Semua faktor yang mempengaruhi output dapat dilihat. Output yang tidak benar dapat diidentifikasi dengan mudah. Kesalahan internal dideteksi secara otomatis melalui mekanisme pengujian itu sendiri. Kesalahan internal dilaporkan secara otomatis. Kode sumber dapat diakses. 3. CONTROLLABILITY(Kemampuan untuk mengawasi) Semakin baik kita dapat mengontrol perangkat lunak, semakin banyak pengujian yang dapat diotomatisasi dan dioptimalkan. Semua output yang baik, dapat diperoleh melalui beberapa kombinasi input. Semua kode dapat dijalankan melalui berbagai kombinasi input. Keadaan dan variabel perangkat lunak dan perangkat keras dapat dikontrol secara langsung oleh penguji. Format input dan output konsisten dan terstruktur. Pengujian dapat dispesifikasi, dioptimasi, dan direproduksi dengan baik. 2

12 4. DECOMPOSABILITY(Kemampuan untuk menyelesaikan). Dengan mengontrol ruang lingkup pengujian, kita dapat dengan lebih cepat mengisolasi masalah dan melakukan pengujian kembali secara lebih halus. Sistem perangkat lunak dibangun dari modul-modul yang independen. Modul-modul dapat diuji secara independen. 5. SIMPLICITY (Kemampuan untuk menyederhanakan kerumitan). Semakin sedikit yang diuji, semakin cepat kita dapat mengujinya. Fungsi yang sederhana (kumpulan fitur adalah kebutuhan minimum untuk memenuhi persyaratan). Struktur yang sederhana (arsitektur dimodularisasi untuk membatasi penyebaran kesalahan). Kode yang sederhana (standar pengkodean diadopsi demi kemudahan inspeksi dan pemeliharaan) 6. STABILITY(Mampu menyeimbangkan ). Semakin sedikit perubahan, semakin sedikit gangguan dalam pengujian. Perubahan perangkat lunak jarang terjadi. Perubahan perangkat lunak dapat dikontrol. Perubahan perangkat lunak memvalidasi pengujian yang sudah ada. Kegagalan perangkat lunak dapat diperbaiki dengan baik. 7. UNDERSTANDBILITY (kemampuan untuk memahami/mengerti). Semakin banyak informasi yang kita dapat, semakin mudah pengujian dilakukan. Rancangan dapat dipahami dengan baik. Ketergantungan antara komponen internal, eksternal, dan yang dipakai bersama, dipahami dengan baik. Perubahan rancangan dibicarakan. Dokumentasi teknik dapat diakses dengan cepat. Dokumen teknik diorganisasikan dengan baik. Dokumentasi teknik spesifik dan detail. Dokumentasi teknik akurat. Ÿ MENGAPA PROGRAM MENGALAMI KERUSAKAN? Ÿ Ketika orang mengerjakan tugas-tugas yang kompleks, mereka membuat kesalahan yang tidak dapat dihindari. Ÿ Mereka lebih memperbaiki kerusakan-kerusakan selama pengujian. Ÿ Mereka harus memperbaiki banyak kesalahan sebelum program akan berjalan semuanya. 3

13 Ÿ MEMPERBAIKI KERUSAKAN ADALAH SESUATU YANG MAHAL Ÿ Dengan waktu sehari, pengujian perangkat lunak secara umum masih mempunyai banyak kerusakan Ÿ Komputer akan menjalankan program yang tidak sempurna Ÿ ketika menghadapi kerusakan, program tidak akan mengerjakan apa yang seharusnya dikerjakan. Ÿ Bahkan mungkin menyebabkan kerugian. Ÿ Semakin lama kerusakan tersisa, semakin buruk memperbaikinya Ÿ membutuhkan biaya lebih untuk perbaikan Ÿ kerusakan yang tersisa akan menjadi penyebab gangguan Ÿ REVIEW (Peninjauan) Ÿ Melakukan peninjauan adalah langkah yang terpenting, karena dapat mengembangkan kualitas perangkat lunak. Ÿ Lebih awal mengenali dan mengatasi masalah, semakin mudah dan murah untuk memperbaikinya. Ÿ APA YANG PERLU DITINJAU? Ÿ REQUIREMENT & ANALYSIS (pemahaman dan analisa) Ÿ DESIGN (rancangan) Ÿ CODE (kode) Ÿ DOCUMNTATION (dokumentasi) Ÿ TEST PLAN & CASES (rencana ujian dan kasus) TESTING TECHNIQUE / Teknik Pengujian Pengujian merupakan elemen yang paling kritis dari penilaian perangkat lunak yang telah dikerjakan. Pembahasan : Dasar-dasar pengujian perangkat lunak 4

14 Perancangan permasalahan pengujian yang berfokus pada kumpulan teknik yang digunakan untuk membuat pengujian sesuai dengan permasalahan dan juga disesuaikan dengan tujuan pengujian secara keseluruhan. Pengujian merupakan salah satu dari siklus pengembangan perangkat lunak yang jika ditinjau dari sudut pandang psikologi adalah penghancuran dibandingkan penyusunan. 5

15 MODUL PERKULIAHAN Testing dan Implementasi SI Modul Standar untuk digunakan dalam Perkuliahan di Universitas Mercu Buana Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh Disini diisi Fakultas Program Tim Dosen penerbit Modul Studi Sistem 3 Informasi Abstract Production of High Quality Software and Its Development life Cycle Kompetensi Understanding Production of High Quality Software and Its Development life Cycle 1

16 Aliran Informasi Pengujian Aliran informasi yang terdapat pada saat pengujian dilaksanakan dapat digambarkan sebagai berikut : Terdapat 2 (dua) tingkatan yang tersedia pada proses pengujian, yaitu : Konfigurasi perangkat lunak yang mencakup spesifikasi keperluan perangkat lunak, spesifikasi perancangan, test case, dan program sumber. Konfigurasi pengujian yang mencakup rencana dan prosedur uji coba, test case dan hasil yang diharapkan. Desain Test Case Dengan melihat lagi sasaran pengujian, kita harus mendesain pengujian yang memiliki kemungkinan tertinggi dalam menemukan kesalahan dengan jumlah waktu dan usaha yang minimum. Terdapat 2 (dua) macam test case : Pengetahuan fungsi yang spesifik dari produk yang telah dirancang untuk diperlihatkan, test dapat dilakukan untuk menilai masing-masing fungsi apakah telah berjalan sebagaimana yang diharapkan. Pengetahuan tentang cara kerja dari produk, test dapat dilakukan untuk memperlihatkan cara kerja dari produk secara rinci sesuai dengan spesifikasinya. Terdapat dua pendekatan dalam teknik pengujian perangkat lunak : Black Box Testing Dilakukan untuk testing pada interface perangkat lunak. Test case ini bertujuan untuk menunjukkan fungsi perangkat lunak tentang cara beroperasinya, apakah pemasukan data keluaran telah berjalan sebagaimana yang diharapkan dan apakah informasi yang disimpan secara eksternal selalu dijaga kemutakhirannya. White Box Testing Meramalkan cara kerja perangkat lunak secara rinci, karenanya logikal path (jalur logika) yang melewati perangkat lunak diuji dengannmemberikan test case yang menguji serangkaian kondisi dan loop secara spesifik. Secara sekilas dapat disimpulkan bahwa metoda White Box Testing merupakan petunjuk untuk mendapatkan program yang benar, karena semuanya dilakukan dengan mendefinisikan seluruh 2

17 jalur logika, mengembangkan test case untuk mengerjakan program, dan mengevaluasi hasilnya, sehingga test case akan mengerjakan logika program secara mendalam. WHITE BOX TESTING Pengujian white box adalah metode perancangan test case yang menggunakan struktur kontrol dari perancangan prosedural untuk mendapatkan test case. Pengujian White Box disebut juga : Glass Box Testing (Pengujian kotak bening) Code Base Testing (Source kodenya dimunculkan) Structural Testing (Struktur program ditampilkan) Dengan menggunakan metoda White Box Testing, perekayasa sistem akan dapat melakukan test case yang : 1. Menjamin bahwa seluruh independent path di dalam modul telah dikerjakan paling tidak satu kali. 2. Mengerjakan seluruh keputusan logika pada sisi true dan false 3. Melaksanakan seluruh loop sesuai dengan batasannya 4. Mengerjakan seluruh struktur data internal yang menjamin validitas BASIS-PATH TESTING Pengujian basis path adalah teknik pengujian white box yang diusulkan oleh Tom MacCabe. Tujuannya memperoleh ukuran kekomplekan logikal dari perancangan prosedural dan menggunakannya sebagai petunjuk untuk menetapkan basis set dari jalur eksekusi. Objek dari pengujian path adalah untuk meyakinkan bahwa penerapan masalah ujian untuk masing-masing path yang melalui program dilaksanakan setidaknya sekali. Point permulaan dari pengujian path adalah Folwgraph program yang menunjukkan keputusan program dan aliran kontrol. Metode pengujian basis path dapat diaplikasikan pada desain prosedural atau kode sumber. Cyclomatic Complexity Adalah metrik perangkat lunak yang menyediakan ukuran kuantitatif dari kekomplekan logika suatu program. Nilai yang dihitung untuk cyclomatic complexity menentukan jumlah independent path dalam basis set suatu program. Memberikan batas atas bagi jumlah pengujian yang harus dilakukan untuk memastikan bahwa seluruh statemen telah dilaksanakan sedikitnya sekali. 3

18 Independet path adalah jalur yang melintasi atau melalui program dimana sekurangkurangnya terdapat proses perintah yang baru atau kondisi yang baru. Dalam flowgraph, independent path harus bergerak sekurang-kurangnya pada satu edge yang belum dilewati sebelum jalur tersebut didefinisikan. Cyclomatic Complexity digunakan untuk mencari jumlah path dalam satu flowgraph. Dapat dicari dengan 3 (tiga) metode, yaitu : Cyclomatic comlpexity V untuk flowgraph dihitung dengan rumus : V(G) = E N + 2 dimana E = jumlah Edge, dan N = jumlah Node Cyclomatic comlpexity V untuk flowgraph dapat dicari dengan rumus : V(G) = P + 1 dimana P = jumlah predikat node Jumlah region dalam flowgraph mempunyai hubungan dengan cyclomatic complexity. V(G) = R Nilai cyclomatic complexity memberi batas untuk jumlah jalur independen yang membentuk basis set dan implikasinya, batas atas jumlah pengujian yang harus didesain dan dieksekusi untuk menjamin semua statemen program. Graph metrik Adalah matrik empat persegi yang mempunyai ukuran (jumlah baris dan kolom) yang sama dengan jumlah node pada flowgraph. Masing-masing baris dan kolom mempunyai hubungan dengan node yang telah ditentukan. Pemasukan data matrik berhubungan dengan hubungan (edge) antarnode. dikembangkan untuk membantu pengujian basis path atau struktur data. LOOP TESTING Loop merupakan kendala yang sering muncul untuk menerapkan algoritma dengan cepat. Pengujian loop merupakan teknik pengujian white box yang berfokus pada validitas dari loop. Terdapat 4 kelas dari loop, : Simple loop. Nested loop. Concanated loop. 4

19 Unstructured loop. Simple Loop Diaplikasikan pada bentuk loop yang sederhana, dimana n adalah jumlah maksimum yang diijinkan untuk melalui loop. lewati loop secara keseluruhan. hanya satu yang melalui loop m dapat melalui loop dimana m = n atau m < n Nested loop teruskan sampai semua loop selesai diuji. Concanated Loop Dapat diuji dengan menggunakan pendekatan simple loop bila masing-masing dari loop independent terhadap yang lain. Bila dua loop dirangkai dan pencacah loop untuk loop 1 digunakan sebagai harga awal untuk loop 2, kemudian loop tersebut menjadi tidak independen, maka pendekatan yang diaplikasikan ke loop tersebut direkomendasikan. Unstructured Loop Apabila memungkinkan, kelas loop ini harus didesain lagi untuk mencerminkan penggunaan konsepsi pemrograman terstruktur. Black Box Testing Ÿ Metode pengujian black box berfokus pada keperluan fungsional dari perangkat lunak dan domain informasi. Ÿ Analis sistem memperoleh kumpulan kondisi dari input yang akan mengerjakan seluruh keperluan fungsional program. Ÿ Cenderung diaplikasikan selama tahap akhir pengujian. Ÿ Disebut juga pengujian behavioral/pengujian partisi/pengujian interface. Ÿ Memperhatikan dari sudut pandang Input data dan Output data. Perangkat lunak ditinjau sebagai kotak hitam yang menyalurkan input kepada output berdasarkan rincian dimana perangkat lunak tersebut harus melakukannya. Periksa kecocokan dari pengujian S/W yang membentuk tingkah laku. Mencari kesalahan-kesalahan yang dihasilkan oleh kesalahan ŸKesalahan perangkat lunak adalah bagian dari perangkat lunak yang tidak menurut pada penyedian definisi itu sendiri dalam dokumen pengembangan. Tujuannya untuk mencari kesalahan-kesalahan pada : 5

20 Fungsi yang salah atau hilang. Kesalahan pada interface. Kesalahan pada struktur data atau akses database. Kesalahan performansi (kinerja). Kesalahan initialisasi dan tujuan akhir. Type dari pengujian black box : 1. Equivalence Class Partitioning. (pembagian kelas yang sama) Metode pengujian black box yang memecah atau membagi domain input dari suatu program ke dalam kelas-kelas data. Perancangan test case berdasarkan evaluasi kelas equivalence untuk kondisi input. Kelas equivalence menggambarkan kumpulan keadaan yang valid dan tidak valid untuk kondisi input. Kondisi input dapat berupa nilai numerik, range dari nilai, kumpulan nilai yang berhubungan atau kondidi boolean. Kelas equivalence dapat ditentukan sesuai pedoman berikut ini : Bila kondisi input menentukan suatu range, maka kelas equivalence valid dan dua yang invalid ditentukan. Bila kondisi input membutuhkan suatu harga khusus, maka satu kelas equivalence valid dan dua yang invalid ditentukan. Bila kondisi input menentukan anggota suatu himpunan, maka satu kelas equivalence valid dan dua yang invalid ditentukan. Bila kondisi input adalah boolean, maka satu kelas dan satu yang tidak valid ditentukan. Contoh : Dalam persamaan matematika. 1 juta <= Gaji <= 5 juta Valid : 1 juta samapi 5 juta Invalid : kurang dari 1 juta lebih dari 5 juta 1. Boundary Value Analysis.(analisa penilaian terbatas) Untuk permasalahan yang tidak diketahui dengan jelas, akan cenderung menimbulkan kesalahan pada domain output-nya. Pemilihan test case yang mengerjakan nilai-nilai yang telah ditentukan. Melengkapi equivalence class partitioning. Petunjuk pemakaian BVA : 6

21 Jika kondisi input berupa range yang dibatasi oleh nilai a dan b, test case harus dirancang dengan nilai a dan b. Jika kondisi input ditentukan dengan sejumlah nilai, test case harus dikembangkan dengan mengerjakan sampai batas maksimal dari nilai tersebut. Sesuai dengan 1 dan 2, untuk kondisi output harus dirancang test case sampai jumlah maksimal. Untuk struktur data pada program juga harus dirancang sampai batas kemampuan. 1. Comparison Testing. (pengujian perbandingan) Perangkat keras dan perangkat lunak yang berlebihan memungkinkan untuk digunakan. Menggunakan team yang terpisah untuk mengembangkan versi-versi yang independent dari perangkat lunak dengan menggunakan spesifikasi yang sama. Mencoba masing-masing versi dengan data yang sama untuk memastikan bahwa semua versi memberikan output yang identik. Semua versi dieksekusi secara paralel dengan perbandingan real time hasil untuk memastikan konsistensi. Output dari masing-masing versi sama implementasi benar. Output berbeda masing-masing versi dari aplikasi diperiksa untuk menentukan cacat pada suatu versi (perbedaan jelas) Spesifikasi semua fungsi yang dikembangkan mengandung kesalahan, maka semua versi kemungkinan besar merefleksikan kesalahan. Masing-masing versi independen identik tetapi tidak benar, maka pengujian kondisi akan gagal mendeteksi kesalahan. 7

22 MODUL PERKULIAHAN Testing dan Implementasi SI Modul Standar untuk digunakan dalam Perkuliahan di Universitas Mercu Buana Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh Disini diisi Fakultas Program Tim Dosen penerbit Modul Studi Sistem 4 Informasi Abstract Basic of Software Testing, Model of Software Testing Blackbox and White Box Kompetensi Understanding a methodology to test a Software with Graph, Path. 1

23 Prosedur pengujian unit. Pengujian unit pada umumnya merupakan perkembangan dari langkah pengkodean. Setelah program sumber dikembangkan, ditinjau kembali dan diverifikasi untuk sintaknya, maka perancangan test case di mulai. Peninjauan kembali perancangan informasi akan menyediakan petunjuk untuk menentukan test case. Karena modul bukan program yang berdiri sendiri, maka driver (pengendali) dan atau stub perangkat lunak harus dikembangkan untuk tiap-tiap pengujian unit. MODUL TESTING (pengujian modul) Pengujian interaksi dari semua komponen yang berhubungan terhadap modul. Pengujian modul yang indpendent. Modul secara individu diuji secara terpisah. Modul berupa kumpulan fungsi, prosedure atau program-program. Tidak secara increment, biasanya dilakukan oleh seorang programmer yang membuat program tersebut. Menggunakan stub dan driver. Pengujian whit-box cocok untuk tingkatan ini. Pengujian struktur data lokal, kondisi batasan, jalur independen, jalur penanganan kesalahan. Formal : rencana pengujian dijelaskan dan tertulis. Modul bukanlah program yang berdiri sendiri, perangkat lunak driver dan atau stub harus dikembangkan bagi masing-masing pengujian unit. Pada sebagian besar aplikasi, driver tidak lebih dari sebuah program utama, yang menerima data test case. Data sampai ke modul untuk diuji, dan kemudian mencetak hasil yang relevan. Stub berfungsi untuk menggantikan modul yang merupakan subordinat dari modul yang akan diuji. Stub menggunakan interface modul subordinat untuk melakukan manipulasi data minimal, mencetak, entri dan kembali. INTEGRATION TESTING (pengujian integrasi) Pengujian integrasi adalah teknik yang sistematis untuk mengkonstruksi susunan program sambil melakukan pengujian untuk memeriksa kesalahan yang nantinya digabungkan dengan interface. Sasarannya adalah untuk mengambil modul yang dikenai pengujian unit dan membangun struktur program yang telah ditentukan oleh desain. Kesulitannya adalah lokalisasi error yang sulit ditemukan pada saat proses. 2

24 Terdapat interaksi yang rumit antara komponen sistem dan ketika ditemukan output yang menyimpang, mungkin sulit untuk menemukan sumber error tersebut. Integrasi non-inkremental Program diuji sebagai satu kesatuan. Serangkaian kesalahan akan terjadi. Koreksi sulit dilakukan karena isolasi penyebab diperumit oleh luasnya program keseluruhan. Sekali kesalahan tersebut dibetulkan, maka akan muncul lagi yang baru dan proses itu terus berlanjut dalam loop yang kelihatannya tidak akan pernah berhenti. Integrasi inkremental Program dibangun dan diuji di dalam segmen-segmen kecil, sehingga kesalahan lebih mudah diisolasi dan dibetulkan, interface lebih mungkin untuk diuji secara lengkap, dan pendekatan pengujian yang sistematis dapat diaplikasikan. Top-down Integrasi adalah pendekatan inkremental terhadap struktur program. Modul diintegrasikan dengan menggerakkan ke bawah melalui hirarki kontrol, dimulai dengan modul kontrol utama (program utama). Memverifikasi kontrol utama dan keputusan pada saat awal proses pengujian. Pada struktur program yang dibuat dengan baik, keputusan akan dikerjakan pada tingkat atas hirarki. Stub mengganti modul tingkat rendah pada awal pengujian top-down, sehingga tidak ada data yang penting yang dapat mengalir ke atas di dalam struktur program. Proses integrasi dilakukan dalam 5 (lima) langkah : 1. Modul kontrol utama digunakan sebagai test driver, dan stub ditambahkan pada semua modul yang secara langsung subordinat terhadap modul kontrol utama. 2. Stub subordinat diganti pada suatu saat dengan modul aktual. 3. Pengujian dilakukan pada saat masing-masing modul diintegrasi. 4. Pada pelengkapan masing-masing rangkaian pengujian, stub yang lain diganti dengan modul real. 5. Pengujian regresi dapat dilakukan untuk memastikan bahwa kesalahan baru belum dimunculkan. Bottom-up Integrasi Dapat dinyatakan dengan penyusunan yang dimulai dan diuji dengan atomic modul (modul tingkat paling bawah pada struktur program). Modul diintegrasikan dari bawah ke atas sehingga pemrosesan yang diperlukan untuk modul subordinat yang selalu diberikan akan selalu tersedia dan kebutuhan akan stub dapat dieliminasi. 3

25 Strategi bottom-up integration dapat diterapkan dengan urutan langkah-langkah sebagai berikut : 1. Modul tingkat bawah digabungkan ke dalam cluster (sering disebut build) yang malakukan subfungsi perangkat lunak spesifik. 2. Driver (program kontrol untuk pengujian) ditulis untuk mengkoordinasi input dan output test case. 3. Cluster diuji. 4. Driver diganti dan cluster digabungkan dengan menggerakkannya ke atas di dalam struktur program. Regression Testing (pengujian regresi) adalah aktivitas yang membantu memastikan bahwa perubahan (karena pengujian atau alasan lain) tidak menimbulkan tingkah laku yang tidak diharapkan atau kesalahan tambahan. Merupakan eksekusi ulang dari beberapa subset yang telah dilakukan untuk memastikan bahwa perubahan tidak menimbulkan efek samping yang tidak diharapkan. Pengujian yang berhasil akan menghasilkan kesalahan, dan setiap kesalahan harus dikoreksi. Setiap kali perangkat lunak dikoreksi, maka banyak aspek konfigurasi perangkat lunak (program, dokumentasi atau data yang mendukung) akan diubah. Pengujian regresi (subset dari pengujian yang akan dieksekusi) berisi tiga kelas test case yang berbeda, yaitu : Sampel respresentatif dari pengujian yang akan menggunakan semua fungsi perangkat lunak. Pengujian tambahan yang berfokus pada fungsi-fungsi perangkat lunak yang mungkin dipengaruhi oleh perubahan tersebut. Pengujian yang berfokus pada komponen perangkat lunak yang telah diubah. Pemilihan strategi integrasi, tergantung pada karakteristik perangkat lunak dan kadangkadang juga pada jadwal proyek. Secara umum, pendekatan yang digabungkan (sandwitch testing), yang menggunakan strategi top-down untuk tingkat yang lebih tinggi dari struktur program, dipasangkan dengan strategi bottom-up untuk tingkat subordinat. Pada saat pengujian integrasi dilakukan, penguji harus mengidentifikasi modul kritis. Modul kritis memiliki karakteristik sebagai berikut : 1. menekankan beberapa persyaratan perangkat lunak. 2. memiliki tingkat kontrol yang tinggi. 3. Kompleks (cyclomatic complexity dapat digunakan sebagai indikator). 4. memiliki persyaratan kinerja yang terbatas. 4

26 Scope of Testing merangkum fungsi yang spesifik, kinerja dan karakteristik desain internal yang akan diuji. Pengujian dibatasi ; kriteria perlengkapan dari masing-masing fase pengujian digambarkan; dan batasan jadwal didokumentasikan. Test Plan menggambarkan seluruh strategi integrasi. Pengujian dibagi ke dalam phases dan builds yang menekankan fungsional spesifik dan karakteristik tingkah laku dari perangkat lunak tersebut. Misalnya pengujian integrasi untuk sebuah sistem komputer yang berorientasi pada grafik dapat dibagi ke dalam fase-fase pengujian sebagai berikut : Interaksi pemakai (seleksi perintah, representasi tampilan, pemrosesan dan respresentasi kesalahan). Manipulasi dan analisis data (pembuatan simbol, penentuan dimensi, rotasi, komputasi sifat fisis) Pemrosesan dan pemunculan tampilan (tampilan dua dimensi, tampilan tiga dimensi, grafik dan bagan) Manajemen database (akses, update, integritas, kinerja) Kriteria dan pengujian yang sesuai diaplikasikan untuk semua fase pengujian : Integritas interface. Antar muka internal dan eksternal diuji pada saat masing-masing modul (kluster) ditambahkan ke dalam struktur. Validitas fungsional. Pengujian yang didesain untuk mengungkap kesalahan fungsional yang dilakukan. Isi informasi. Pengujian yang didesain untuk mengungkap kesalahan yang berhubungan dengan struktur data global atau lokal yang dilakukuan. Kinerja. Pengujian yang didesain untuk memeriksa batasan kinerja yang dibangun selama desain perangkat lunak dilakukan. VALIDATION TESTING (pengujian validasi) Dilakukan setelah integration testing dilakukan serta kesalahan-kesalahan yang ditemukan telah diperbaiki. Validasi berhasil jika fungsi-fungsi yang ada pada perangkat lunak telah sesuai dengan yang diharapkan oleh pemakai. Merupakan kumpulan pengujian black-box yang memperlihatkan atau menunjukkan sesuai dengan yang diperlukan. Garis besar rencana pengujian dikerjakan dan prosedur pengujian didefinisikan dengan test case yang spesifik untuk menunjukkan sesuai dengan yang diperlukan. Rencana dan prosedur dirancang untuk menjamin seluruh keperluan fungsional telah terpenuhi, seluruh performansi dapat dicapai, dokumentasi dilakukan dengan benar. Setelah pengujian dikerjakan, ada satu kemungkinan dari dua kondisi yang ada, yaitu : 1. Karakteristik performansi fungsi sesuai dengan spesifikasi dan dapat diterima. 2. Penyimpangan dari spesifikasi ditemukan dan daftar penyimpangan dibuat. 5

27 Kajian Konfigurasi Merupakan elemen penting dari proses validasi. Tujuannya untuk memastikan apakah semua elemen konfigurasi perangkat lunak telah dikembangkan dengan tepat, dikatalog, dan memiliki detail yang perlu untuk mendukung fase pemeliharaan dari siklus hidup perangkat lunak. Sering disebut audit. ALPHA & BETA TESTING Sangat tidak mungkin bagi pengembang perangkat lunak untuk meramalkan bagaimana pelanggan akan benar-benar menggunakan sebuah program. Instruksi yang digunakan dapat disalah-interprestasikan, kombinasi data yang aneh dapat dipakai secara reguler, dan output yang kelihatannya sudah jelas bagi penguji tidak dapat dimengerti oleh pemakai di lapangan. Bila perangkat lunak biasa dibangun bagi satu pelanggan, maka dapat acceptance test dapat dilakukan untuk memungkinkan pelanggan memvalidasi semua persyaratan. Acceptance test dilakukan karena memungkinkan pelanggan untuk menemukan kesalahan yang lebih terinci dan membiasakan pelanggan memahami perangkat lunak yang telah dibuat. Jika perangkat lunak dikembangkan atau dibuat untuk dipakai oleh banyak pelanggan, maka tidak praktis untuk melakukan pengujian satu per satu terhadap perangkat lunak tersebut. Maka digunakan alpha dan beta testing. Alpha testing adalah tahap pengembangan, dimana perangkat lunak atau perangkat keras yang telah dibuat dikirim ke kelompok pemakai atau pembeli yang potensial kemudian mereka akan menggunakan produk ini untuk melaporkan jika produk itu gagal? Pengujian aplha dilakukan pada sebuah lingkungan yang terkontrol. Pengujian beta dilakukan oleh pelanggan yang merupakan pemakai akhir perangkat lunak. Pengujian beta merupakan sebuah aplikasi live dari perangkat lunak dalam suatu lingkungan yang tidak dapat dikontrol oleh pengembang. Pelanggan merekam semua masalah yang ditemui selama pengujian beta dan melaporkannya kepada pengembang. Pengembang melakukan modifikasi kemudian mempersiapkan pelepasan produk ke seluruh pelanggan. SYSTEM TESTING Perangkat lunak merupakan salah satu elemen dari sistem yang berbasis komputer yang sangat besar. Perangkat lunak diintegrasi dengan elemen sistem lainnya (hardware, informasi) dan serangkaian integrasi sistem dan validasi test dilakukan. Jika pengujian gagal atau diluar scope dari pengembangan sistem dan tidak hanya dikerjakan oleh programmer, maka langkah yang diambil selama perancangan dan pengujian dapat diperbaiki 6

28 Peran analis sistem antara lain : o Menangani kesalahan yang muncul dari elemen-elemen perangkat lunak o Mengerjakan serangkaian pengujian o Mencatat hasil pengujian. o Berpartisipasi dalam perencanaan dan merangcang pengujian sistem untuk menjamin kualitas perangkat lunak. o System testing adalah sederetan pengujian yang berbeda-beda dengan tujuan utama mengerjakan keseluruhan elemen dalam sistem yang telah dikembangkan. Stress Testing (pengujian stres) Didesain untuk menghadapi situasi yang tidak normal pada saat program mengalami pengujian. Dilakukan oleh sistem untuk kondisi-kondisi seperti volume data yang normal (melebihi atau kurang dari batasan), frekuensi dll. Intinya penguji berusaha untuk merusak program. Recovery Testing (pengujian perbaikan) Adalah pengujian sistem yang memaksa perangkat lunak untuk mengalami kegagalan dalam berbagai cara dan melakukan verifikasi sesuai dengan performansi yang tepat. Banyak sistem yang berbasis komputer harus melindungi dari kesalahan dan melanjutkan prosesnya dalam waktu yang telah ditentukan. Sistem harus toleran terhadap kesalahan. Kesalahan pemrosesan tidak boleh menyebabkan keseluruhan fungsi sistem berhenti. Security Testing (pengujian keamanan) Adalah pengujian yang akan melakukan verifikasi dari mekanisme perlindungan yang akan dibuat oleh sistem, melindungi dari hal-hal yang mungkin terjadi. Penguji memerankan individu yang akan menembus sistem. Pengujian untuk mencoba menembus tingkat keamanan sebuah perangkat lunak. Strategi Sandwich Compromise, menguji perangkat lunak dengan melakukan pengujian mulai dari entry-point tertentu kemudian bergerak keatas ataupun kebawah. Volume Testing, menguji perangkat lunak dengan memberi data yang berlebihan. Configuration Testing, menguji berbagai variasi perangkat lunak diberbagai lingkungan perangkat lunak. Compatibility Testing, menguji kesesuaian sebuah perangkat lunak dengan sistem yang sedang dimanfaatkan. Timing sistem, melakukan pengujian terhadap perangkat lunak untuk evaluasi terhadap waktu tanggap dan waktu proses Yng dibutuhkan untuk menyelesaikan sebuah tugas. Enviromental Testing, menguji toleransi perangkat lunak terhadap suhu, kelembaban, gerak dan perpindahan. Human Factor Testing, menguji antarmuka perangkat lunak bersama-sama dengan pemakai. 7

29 Interface Testing (pengujian interface) Dilakukan ketika modul atau subsistem diintegrasi untuk membuat sistem yang lebih besar. Setiap modul atau subsistem memiliki interface yang terdifinisi yang dipanggil oleh komponen program lain. Tujuannya adalah untuk mendeteksi kesalahan yang mungkin telah masuk ke dalam sistem karena eror interface atau asumsi invalid mengenai interface. Penting untuk pengembangan berorientasi objek 8

30 MODUL PERKULIAHAN Testing dan Implementasi SI Modul Standar untuk digunakan dalam Perkuliahan di Universitas Mercu Buana Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh Disini diisi Fakultas Program Tim Dosen penerbit Modul Studi Sistem 5 Informasi Abstract Blackbox testing and Technique to implement a software testing with blackbox. Kompetensi Understanding Black box testing and its component 1

31 Black Box Testing Ÿ Metode pengujian black box berfokus pada keperluan fungsional dari perangkat lunak dan domain informasi. Ÿ Analis sistem memperoleh kumpulan kondisi dari input yang akan mengerjakan seluruh keperluan fungsional program. Ÿ Cenderung diaplikasikan selama tahap akhir pengujian. Ÿ Disebut juga pengujian behavioral/pengujian partisi/pengujian interface. Ÿ Memperhatikan dari sudut pandang Input data dan Output data. Perangkat lunak ditinjau sebagai kotak hitam yang menyalurkan input kepada output berdasarkan rincian dimana perangkat lunak tersebut harus melakukannya. Periksa kecocokan dari pengujian S/W yang membentuk tingkah laku. Mencari kesalahan-kesalahan yang dihasilkan oleh kesalahan ŸKesalahan perangkat lunak adalah bagian dari perangkat lunak yang tidak menurut pada penyedian definisi itu sendiri dalam dokumen pengembangan. Tujuannya untuk mencari kesalahan-kesalahan pada : Fungsi yang salah atau hilang. Kesalahan pada interface. Kesalahan pada struktur data atau akses database. Kesalahan performansi (kinerja). Kesalahan initialisasi dan tujuan akhir. Type dari pengujian black box : 2. Equivalence Class Partitioning. (pembagian kelas yang sama) Metode pengujian black box yang memecah atau membagi domain input dari suatu program ke dalam kelas-kelas data. Perancangan test case berdasarkan evaluasi kelas equivalence untuk kondisi input. Kelas equivalence menggambarkan kumpulan keadaan yang valid dan tidak valid untuk kondisi input. Kondisi input dapat berupa nilai numerik, range dari nilai, kumpulan nilai yang berhubungan atau kondidi boolean. Kelas equivalence dapat ditentukan sesuai pedoman berikut ini : Bila kondisi input menentukan suatu range, maka kelas equivalence valid dan dua yang invalid ditentukan. Bila kondisi input membutuhkan suatu harga khusus, maka satu kelas equivalence valid dan dua yang invalid ditentukan. 2

32 Bila kondisi input menentukan anggota suatu himpunan, maka satu kelas equivalence valid dan dua yang invalid ditentukan. Bila kondisi input adalah boolean, maka satu kelas dan satu yang tidak valid ditentukan. Contoh : Dalam persamaan matematika. 1 juta <= Gaji <= 5 juta Valid : 1 juta samapi 5 juta Invalid : kurang dari 1 juta lebih dari 5 juta 2. Boundary Value Analysis.(analisa penilaian terbatas) Untuk permasalahan yang tidak diketahui dengan jelas, akan cenderung menimbulkan kesalahan pada domain output-nya. Pemilihan test case yang mengerjakan nilai-nilai yang telah ditentukan. Melengkapi equivalence class partitioning. Petunjuk pemakaian BVA : Jika kondisi input berupa range yang dibatasi oleh nilai a dan b, test case harus dirancang dengan nilai a dan b. Jika kondisi input ditentukan dengan sejumlah nilai, test case harus dikembangkan dengan mengerjakan sampai batas maksimal dari nilai tersebut. Sesuai dengan 1 dan 2, untuk kondisi output harus dirancang test case sampai jumlah maksimal. Untuk struktur data pada program juga harus dirancang sampai batas kemampuan. 2. Comparison Testing. (pengujian perbandingan) Perangkat keras dan perangkat lunak yang berlebihan memungkinkan untuk digunakan. Menggunakan team yang terpisah untuk mengembangkan versi-versi yang independent dari perangkat lunak dengan menggunakan spesifikasi yang sama. Mencoba masing-masing versi dengan data yang sama untuk memastikan bahwa semua versi memberikan output yang identik. Semua versi dieksekusi secara paralel dengan perbandingan real time hasil untuk memastikan konsistensi. Output dari masing-masing versi sama implementasi benar. Output berbeda masing-masing versi dari aplikasi diperiksa untuk menentukan cacat pada suatu versi (perbedaan jelas) Spesifikasi semua fungsi yang dikembangkan mengandung kesalahan, maka semua versi kemungkinan besar merefleksikan kesalahan. 3

33 Masing-masing versi independen identik tetapi tidak benar, maka pengujian kondisi akan gagal mendeteksi kesalahan. TESTING STAGES Sasaran utama desain test case untuk mendapatkan serangkaian pengujian yang memiliki kemungkinan tertinggi di dalam pengungkapan kesalahan pada perangkat lunak. Teknik yang digunakan Pengujian white-box (white box testing) Pengujian black-box (black-box testing) Pengujian white-box Berfokus pada struktur kontrol program. Pengujian dilakukan untuk memastikan bahwa semua statemen pada program telah dieksekusi paling tidak satu kali selama pengujian dan semua kondisi telah diuji. Pengujian basis path, teknik pengujian white-box, menggunakan grafik program (matrik grafik) untuk melakukan serangkaian pengujian yang independen secara linear yang memastikan cakupan. Pengujian aliran data dan kondisi lebih lanjut menggunakan logika program, dan pengujian loop menyempurnakan teknik white box yang lain dengan memberikan sebuah prosedur untuk menguji loop dari tingkat kompleksitas yang bervariasi. Implikasinya secara khusus diaplikasikan ke dalam komponen program yang kecil (modul atau kelompok kecil dari modul). Pengujian black-box Didesain untuk mengungkap kesalahan pada persyaratan fungsional tanpa mengabaikan kerja internal dari suatu program. Berfokus pada domain informasi dari perangkat lunak. Melakukan teste case dengan mempartisi domain input dan output dari suatu program dengan cara yang memberikan cakupan pengujian yang mendalam. Partisi ekivalensi (Equivalence Class Partitioning) membagi domain input kedalam kelas data yang mungkin untuk melakukan fungsi perangkat lunak tertentu. Analisis nilai terbatas (Boundary Value Analysis) memeriksa kemampuan program untuk menangani data pada patas yang dapat diterima. Pengujian perbandingan (Comparison Testing) mengembangkan perangkat lunak ke dalam versi-versi yang independen dari suatu aplikasi dengan menggunakan spesifikasi yang sama. Setiap versi diuji dengan data uji yang sama untuk memastikan bahwa semua versi memberikan output yagn identik. Disebut juga pengujian back to back. 4

34 Pengembang perangkat lunak yang berpengalaman sering mengatakan, Pengujian tidak akan pernah berakhir. Pengujian hanya berpindah dari Penguji ke pelanggan. Setiap pelanggan menggunakan program tersebut, berarti suatu pengujian dilakukan. Dengan mengaplikasikan desain test case, perekayasa perangkat lunak dapat menapai pengujian yang lebih lengkap sehingga dapat mengungkap dan melakukan koreksi sebelum pengujian pelanggan dimulai. TESTING STAGES (tingkatan pengujian Validasi perangkat lunak (V & V) ditujukan untuk menunjukkan bahwa sistem sesuai dengan spesifikasinya dan bahwa sistem memenuhi harapan pelanggan yang membelinya. Validasi melibatkan proses pemeriksaan, seperti inspeksi dan peninjauan, pada setiap proses perangkat lunak dari definisi persyaratan user sampai pengembangan program. Validasi perangkat lunak adalah proses pemeriksaan untuk menjamin agar sistem telah sesuai dengan spesifikasinya dan memenuhi kebutuhan sesungguhnya dari user sistem. Namun demikian, mayoritas biaya validasi disediakan setelah implementasi sistem operasional diuji. Untuk program-program kecil, sistem seharusnya tidak diuji sebagai sistem tunggal. Sistem besar dibangun dari subsistem yang dibangun dari model yang terbuat dari prosedur dan fungsi. Proses demikian dengan demikian harus dilakukan bertahap, dimana pengujian dilakukan secara inkremental bersama dengan implementasi sistem. Proses pengujian terdiri dari 3 (tiga) tahap dimana komponen-komponen sistem diuji, sistem yang terintegrasi diuji, dan akhirnya sistem diuji dengan data pelanggan. Idealnya, kesalahan komponen ditemukan dini pada proses dan masalah interface ketika sistem diintegrasi. Namun demikian, dengan ditemukannya kesalahan, program harus didebug. Hal ini menuntut tahap proses pengujian ulang. Error pada komponen program, bisa muncul pada saat pengujian itegrasi. Proses dengan demikian bersifat iteratif, dengan informasi diumpan balik dari bagian akhir ke bagian awal proses. Tahap-tahap pada proses pengujian : 1. Unit Testing (pengujian unit). Komponen individual diuji untuk menjamin operasi yang benar. Setiap komponen diuji secara independen, tanpa komponen sistem yang lain. 2. Modul Testing (pengujian modul). 5

35 Modul merupakan sekumpulan komponen yang berhubungan seperti kelas objek, atau sekumpulan prosedur dan fungsi. Sebuah modul merangkum komponen-komponen yang berhubungan, sehingga dapat diuji tanpa modul sistem yang lain. 3. Sub-system Testing (pengujian subsistem). Melibatkan pengujian sekumpulan modul yang telah diintegrasikan menjadi subsistem. Masalah yang sering muncul pada sistem perangkat lunak besar adalah ketidaksesuaian interface. Proses pengujian subsistem dengan demikian harus terkonsentrasi pada deteksi kesalahan interface modul dengan menjalankan interface ini berkali-kali. 4. System Testing (pengujian sistem). Subsistem diintegrasikan untuk membentuk sistem. Proses ini berkenaan dengan penemuan kesalahan yang diakibatkan dari interaksi yang tidak diharapkan antara subsistem dan masalah interface subsistem. Sistem pengujian secara keseluruhan dimana pengujian timbul karena sifat-sifat yang baru. Pengujian atas penggabungan sistem perangkat lunak. 5. Acceptance Testing (pengujian penerimaan). v Merupakan tahap akhir proses pengujian sebelum sistem diterima untuk penggunaan operasional. v Sistem diuji dengan data yang dipasok oleh pelanggan dan bukan data uji simulasi. v Bisa menunjukkan kesalahan dan penghapusan definisi persyaratan sistem karena data riil menjalankan sistem dengan cara yang berbeda dari data uji. v Dapat mengungkap masalah persyaratan dimana fasilitas sistem tidak memenuhi keperluan user atau kinerja sistem tidak dapat diterima. Pengujian unit dan pengujian modul biasanya merupakan tanggung jawab programmer yang mengembangkan komponen tersebut. Programer membuat data uji sendiri dan secara inkremental menguji kode pada saat dikembangkan. Pengujian ini sangat ekonomis karena programmer adalah orang yang paling mengetahui komponen tersebut dan merupakan orang terbaik untuk membuat data uji. Tahap berikutnya mencakup integrasi dari sejumlah programmer dan harus direncanakan sebelumnya. Suatu tim penguji independent harus bekerja dari rencana uji pra-formulasi yang dikembangkan dari spesifikasi dan rancangan sistem. Pengujian penerimaan kadang-kadang disebut pengujian alpha. Sistem yang diperlihatkan dikembangkan untuk satu klien. Proses pengujian alpha berlanjut sampai 6

36 pengembang sistem dan pelanggan setuju bahwa sistem yang diserahkan merupakan implementasi yang dapat diterima dari persyaratan sistem. 7

37 MODUL PERKULIAHAN Testing dan Implementasi SI Modul Standar untuk digunakan dalam Perkuliahan di Universitas Mercu Buana Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh Disini diisi Fakultas Program Tim Dosen penerbit Modul Studi Sistem 6 Informasi Abstract Software Testing in Object Oriented Analysis and Design Kompetensi Understanding Software Testing in Object Oriented Analysis and Design 1

38 OBJECT ORIENTED TESTING (pengujian berorientasi objek) Pengujian operasi individual yang berhubungan dengan objek. Merupakan fungsi atau prosedur dan dapat digunakan pendekatan black-box dan white-box. Pengujian kelas objek individu. Prinsip pengujian black-box tidak berubah tetapi pengertian kelas ekuivalensi harus diperluas untuk mencakup rangkaian operasi yang berhubungan. Dengan cara yang sama, pengujian struktural membutuhkan jenis analisis yang berbeda. Pengujian kelompok objek. Integrasi top-down dan bottom-up yang ketat tidak sesuai untuk membuat kumpulan objek yang berhubungan. Pengujian berdasar skenario yang digunakan. Pengujian sistem berorientasi objek. Verifikasi dan validasi terhadap spesifikasi persyaratan sistem dilakukan dengan cara yang tepat sama sebagaimana untuk jenis sistem yang lain. Object Integration (integrasi objek) Pengujian use-case atau basis skenario. Mendeskripsikan satu model penggunaan sistem. Pengujian dapat didasarkan atas deskripsi skenario ini dan kelompok objek yang dibuat untuk mendukung use-case yang berhubungan dengan model penggunaan tersebut. Pengujian thread. Berdasar pengujian respon sistem terhadap suatu input atau set event input tertentu. Sistem berorientasi objek seringkali dikendalikan event sehingga merupakan bentuk pengujian yang sesuai. Untuk memakai pendekatan ini, kita harus mengidentifikasi cara pemrosesan event menelusuri jalannya melalui sistem. Pengujian interaksi objek. o Diusulkan oleh Jorgensen dan Erikson. o Tingkat menengah dari pengujian integrasi dapat didasarkan atas identifikasi jalur. o Jalur melalui serangkaian interaksi objek yang berhenti ketika operasi objek tidak memanggil layanan objek lain. Tiga hal yang harus dilakukan untuk menguji sistem OO : 1. Definisi pengujian harus diperluas untuk mencakup teknik penemuan kesalahan yang diaplikasikan ke model OOA dan OOD. 2. Strategi untuk pengujian unit dan terintegrasi harus berubah secara signifikan. 3. Desain test case harus bertanggung jawab terhadap karakteristik unik perangkat lunak OO. Model Pengujian OOA dan OOD Model desain dan analisis tidak dapat diuji dalam arti yang konvensional, karena model tersebut tidak dapat dieksekusi. 2

39 Kajian teknis formal dapat digunakan untuk menguji kebenaran dan konsistensi model analisis maupun model desain. Kebenaran Model OOA dan OOD Notasi dan sintaks digunakan untuk merespresentasikan model analisis dan desain. Kebenaran sintaks dinilai pada penggunaan simbol yang teratur. Masinag-masig model dikaji untuk memastikan apakah konvensi pemodelan yang tepat telah terjaga. Konsistensi Model OOA dan OOD mempertimbangkan hubungan antar entitas di dalam model tersebut. masing-masing kelas dan koneksinya ke kelas lain harus diuji. desain sistem dikaji dengan menguji model tingkah laku objek yang dikembangkan selama OOA. Metode Pengujian Berorientasi Objek Pengujian sistem berorientasi objek umumnya dilakukan secara bottom-up dalam empat level : 1. Pengujian level metode yang menguji metode individu di kelas. 2. Metode-metode dan atribut-atribut yang menyusun kelas. Pengujian level kelas (intra kelas) adalah pengujian terhadap interaksi-interaksi di antara komponen-komponen di satu kelas individu. 3. Kelas-kelas yang bekerja sama menyusun tandan kelas (class cluster). Pengujian tandan kelas menguji interaksi-interaksi di antara kelas-kelas. 4. Tandan-tandan kelas menyusun sistem. Pengujian level sistem berurusan dengan masukan dan keluaran yang tampak bagi pemakai sistem. Stratregi pengujian berorientasi objek Strategi klasik pengujian perangkat lunak : Dimulai dari pengujian unit, bergerak menuju pengujian integrasi dan berakhir pada validasi dan pengujian sistem. Pengujian unit berfokus pada satuan program kecil yang dapat di-compile. Unit diintegrasikan dengan suatu struktur program. Pengujian regresi dijalankan untuk mengungkap kesalahan sehubungan dengan interfacing modul dan efek samping yang disebabkan oleh penambahan unit-unit baru. Sistem secara keseluruhan diuji untuk memastikan apakah kesalahan terungkap. Perubahan strategi pengujian pada pendekatan berorientasi objek Pengujian unit, monsep mengenai unit diperluas di sistem berorientasi objek. 3

40 Pengujian integrasi, integrasi berfokus pada kelas-kelas dan eksekusinya pada satu thread atau use case. Pengujian validasi, menggunakan pengujian kotak hitam tradisional 4

41 MODUL PERKULIAHAN Testing dan Implementasi SI Modul Standar untuk digunakan dalam Perkuliahan di Universitas Mercu Buana Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh Disini diisi Fakultas Program Tim Dosen penerbit Modul Studi Sistem 7 Informasi Abstract Stratefy of Software Testing Approach and Validation Testing Kompetensi Understanding Stratefy of Software Testing Approach and Validation Testing 1

42 STRATEGI PENGUJIAN PERANGKAT LUNAK Strategi untuk pengujian perangkat lunak mengintegrasikan metode desain test case perangkat lunak ke dalam sederetan langkah yang direncanakan dengan baik, hasilnya adalah konstruksi perangkat lunak yang berhasil. Strategi pengujian perangkat lunak memberikan sebuah peta jalan bagi pengambang perangkat lunak, organisasi jaminan kualitas, dan pelanggan. Peta jalan menggambarkan langkah-langkah yang akan dilakukan sebagai bagian dari pengujian, kapan langkah-langkah itu direncanakan dan kemudian dijalankan, serta berapa banyak usaha, waktu, dan sumber daya yang dibutuhkan. Strategi pengujian menggabungkan perencanan pengujian, desain test case, dan kumpulan data resultan (hasil) serta evaluasi. Kesimpulan : Strategi pengujian perangkat lunak memudahkan para perancang untuk menentukan keberhasilan dari sistem yang telah dikerjakan. Hal yang harus diperhatikan adalah langkah-langkah perencanaan dan pelaksanaan harus direncanakan dengan baik dan berapa lama waktu, upaya dan sumber daya yang diperlukan. Pendekatan Strategis ke pengujian perangkat lunak Pengujian adalah serangkaian aktivitas yang dapat direncanakan sebelumnya dan dilakukan secara sistematis. Karena ituah harus ditentukan suatu template untuk desain perangkat lunak serangkaian langkah yang di dalamnya kita dapat menempatkan metode desain test case yang spesifik untuk proses rekayasa perangkat lunak. Banyak strategi pengujian yang dapat digunakan, tetapi secara umum mempunyai karakteristik sebagai berikut : Pengujian dimulai pada tingkat modul yang palin bawah, dilanjutkan dengan modul di atasnya kemudian hasilnya dipadukan. Teknik pengujian yang berbeda mungkin akan menghasilkan sedikit perbedaan dalam hal waktu. Pengujian dilakukan oleh pengembang perangkat lunak dan (untuk proyek yang besar) suatu kelompok pengujian yang independen. Pengujian dan debugging merupakan aktivitas yang berbeda, tetapi debugging termasuk dalam strategi pengujian. Pengujian perangkat lunak adalah suatu elemen dari topik yang sangat luas dimana dapat disebut sebagai verifikasi dan validasi (V & V). 2

43 Verifikasi adalah kumpulan aktivitas yang menjamin bahwa perangkat lunak benar-benar sesuai dengan fungsinya. Validasi adalah serangkain aktivitas yang berbeda yang memastikan bahwa perangkat lunak yang dibangun dapat sesuai dengan kepeluan pelanggan. Strategi pengujian perangkat lunak v Proses rekayasa perangkat lunak dapat juga dipandang sebagai sebuah bentuk spiral. v Pada awalnya, rekayasa sistem menentukan peran perangkat lunak dan membawa kepada analis persyaratan di mana domain informasi, fungsi, tingkah laku dan kinerja validasi bagi perangkat lunak di bangun. v Dengan bergerak dalam sepanjang spiral, kita akan sampai ke desain dan akhirnya ke pengkodean. Unit testing dimulai pada pusaran spiral dan terpusat pada masing-masing satuan perangkat lunak pada saat diimplementasikan di dalam kode sumber. Pengujian berjalan dengan bergerak keluar sepanjang spiral ke integration testing di mana fokusnya adalah desain dan konstruksi arsitektur perangkat lunak. Dengan mengambil urutan keluar lainnya di dalam spiral, akan sampai ke validation testing di mana persyaratan yang dibangun sebagai bagian dari analisis persyaratan perangkat lunak di validasi terhadap perangkat lunak yang telah dikonstruksi. Akhirnya sampai pada system tesing di mana perangkat lunak dan elemen sistem yang lain diuji secara keseluruhan. Dengan mempertimbangkan proses dari titik pandang prosedural, pengujian di dalam konteks rekayasa perangkat lunak secara aktual merupakan 4 (empat) langkah yang diimplementasi secara berurutan. 1. Pada awalnya, pengujian berfokus pada setiap modul secara individual, dengan memastikan bahwa modul berfungsi secara tepat sebagai suatu unit, karena itu dinamakan unit testing. Menggunakan metoda pengujian white-box. Selanjutnya modul diintegrasikan untuk membentuk paket perangkat lunak yang lengkap. 2. Integration testing menekankan pada masalah-masalah yang berhubungan dengan masalah-masalah verifikasi dan konstruksi program. Mengunakan teknik pengujian black-box. 3. Validation testing memberikan jaminan akhir di mana perangkat lunak harus memenuhi semua persyaratan fungsional, tingkah laku dan kinerja. Teknik pengujian black-box digunakan secara eksklusif selama validasi. Perangkat lunak, sekali divalidasi, harus dikombinasikan dengan elemen sistem yang lain (hardware, manusia, database). 4. Pengujian sistem membuktikan bahwa semua elemen sistem saling bertautan dengan tepat dan keseluruhan fungsi/kinerja sistem dapat dicapai. UNIT TESTING (pengujian unit) 3

44 Pengujian berfokus pada usaha verifikasi pada unit terkecil dari desain perangkat lunak, yakni modul. Dengan menggunakan deskripsi desain terinci sebagai panduan, jalur kontrol yang penting diuji untuk mengungkap kesalahan di dalam batas dari modul tersebut. Kompleksitas dari pengujian dan kesalahan ditentukan berdasarkan scope modul. Pengujian unit selalu berorientasi ke white-box testing dan dapat dikerjakan dengan paralel atau berurutan dengan modul-modul yang lainnya. Unit Testing Unit individu diuji secara terpisah. Unit mungkin menjadi fungsi-fungsi sendiri, prosedur atau program. Dikerjakan secara meningkat, biasanya oleh programmer sendiri yang memberikan kodenya. Kebanyakan white-box testing cocok untuk tingkatan ini. Susunan data ujian lokal, kondisi boundary, path independent dan path penanganan kesalahan. Tak resmi, rencana ujian tidak resmi, jelas dan tertulis. Interface diuji untuk menjamin informasi yang mengalir masuk dan keluar dari unit program telah tepat atau sesuai dengan yang diharapkan. Struktur data lokal dikerjakan untuk menjamin penyimpanan data selalu muthakir. Kondisi batasan-batasan adalah pengujian untuk menjamin modul-modul dioperasikan sesuai dengan batasannya. Independent path untuk menjamin seluruh perintah dalam modul telah bekerja dengan baik. Penanganan kesalahan kesalahan merupakan langkah terakhir dalam tahap ini. Prosedur pengujian unit. Pengujian unit pada umumnya merupakan perkembangan dari langkah pengkodean. Setelah program sumber dikembangkan, ditinjau kembali dan diverifikasi untuk sintaknya, maka perancangan test case di mulai. Peninjauan kembali perancangan informasi akan menyediakan petunjuk untuk menentukan test case. Karena modul bukan program yang berdiri sendiri, maka driver (pengendali) dan atau stub perangkat lunak harus dikembangkan untuk tiap-tiap pengujian unit. MODUL TESTING (pengujian modul) Pengujian interaksi dari semua komponen yang berhubungan terhadap modul. Pengujian modul yang indpendent. Modul secara individu diuji secara terpisah. Modul berupa kumpulan fungsi, prosedure atau program-program. Tidak secara increment, biasanya dilakukan oleh seorang programmer yang membuat program tersebut. Menggunakan stub dan driver. Pengujian whit-box cocok untuk tingkatan ini. 4

45 Pengujian struktur data lokal, kondisi batasan, jalur independen, jalur penanganan kesalahan. Formal : rencana pengujian dijelaskan dan tertulis. Modul bukanlah program yang berdiri sendiri, perangkat lunak driver dan atau stub harus dikembangkan bagi masing-masing pengujian unit. Pada sebagian besar aplikasi, driver tidak lebih dari sebuah program utama, yang menerima data test case. Data sampai ke modul untuk diuji, dan kemudian mencetak hasil yang relevan. Stub berfungsi untuk menggantikan modul yang merupakan subordinat dari modul yang akan diuji. Stub menggunakan interface modul subordinat untuk melakukan manipulasi data minimal, mencetak, entri dan kembali. INTEGRATION TESTING (pengujian integrasi) Pengujian integrasi adalah teknik yang sistematis untuk mengkonstruksi susunan program sambil melakukan pengujian untuk memeriksa kesalahan yang nantinya digabungkan dengan interface. Sasarannya adalah untuk mengambil modul yang dikenai pengujian unit dan membangun struktur program yang telah ditentukan oleh desain. Kesulitannya adalah lokalisasi error yang sulit ditemukan pada saat proses. Terdapat interaksi yang rumit antara komponen sistem dan ketika ditemukan output yang menyimpang, mungkin sulit untuk menemukan sumber error tersebut. Integrasi non-inkremental Program diuji sebagai satu kesatuan. Serangkaian kesalahan akan terjadi. Koreksi sulit dilakukan karena isolasi penyebab diperumit oleh luasnya program keseluruhan. Sekali kesalahan tersebut dibetulkan, maka akan muncul lagi yang baru dan proses itu terus berlanjut dalam loop yang kelihatannya tidak akan pernah berhenti. Integrasi inkremental Program dibangun dan diuji di dalam segmen-segmen kecil, sehingga kesalahan lebih mudah diisolasi dan dibetulkan, interface lebih mungkin untuk diuji secara lengkap, dan pendekatan pengujian yang sistematis dapat diaplikasikan. Top-down Integrasi adalah pendekatan inkremental terhadap struktur program. Modul diintegrasikan dengan menggerakkan ke bawah melalui hirarki kontrol, dimulai dengan modul kontrol utama (program utama). Memverifikasi kontrol utama dan keputusan pada saat awal proses pengujian. 5

46 Pada struktur program yang dibuat dengan baik, keputusan akan dikerjakan pada tingkat atas hirarki. Stub mengganti modul tingkat rendah pada awal pengujian top-down, sehingga tidak ada data yang penting yang dapat mengalir ke atas di dalam struktur program. Proses integrasi dilakukan dalam 5 (lima) langkah : 6. Modul kontrol utama digunakan sebagai test driver, dan stub ditambahkan pada semua modul yang secara langsung subordinat terhadap modul kontrol utama. 7. Stub subordinat diganti pada suatu saat dengan modul aktual. 8. Pengujian dilakukan pada saat masing-masing modul diintegrasi. 9. Pada pelengkapan masing-masing rangkaian pengujian, stub yang lain diganti dengan modul real. 10. Pengujian regresi dapat dilakukan untuk memastikan bahwa kesalahan baru belum dimunculkan. Bottom-up Integrasi Dapat dinyatakan dengan penyusunan yang dimulai dan diuji dengan atomic modul (modul tingkat paling bawah pada struktur program). Modul diintegrasikan dari bawah ke atas sehingga pemrosesan yang diperlukan untuk modul subordinat yang selalu diberikan akan selalu tersedia dan kebutuhan akan stub dapat dieliminasi. Strategi bottom-up integration dapat diterapkan dengan urutan langkah-langkah sebagai berikut : 5. Modul tingkat bawah digabungkan ke dalam cluster (sering disebut build) yang malakukan subfungsi perangkat lunak spesifik. 6. Driver (program kontrol untuk pengujian) ditulis untuk mengkoordinasi input dan output test case. 7. Cluster diuji. 8. Driver diganti dan cluster digabungkan dengan menggerakkannya ke atas di dalam struktur program. Regression Testing (pengujian regresi) adalah aktivitas yang membantu memastikan bahwa perubahan (karena pengujian atau alasan lain) tidak menimbulkan tingkah laku yang tidak diharapkan atau kesalahan tambahan. Merupakan eksekusi ulang dari beberapa subset yang telah dilakukan untuk memastikan bahwa perubahan tidak menimbulkan efek samping yang tidak diharapkan. Pengujian yang berhasil akan menghasilkan kesalahan, dan setiap kesalahan harus dikoreksi. Setiap kali perangkat lunak dikoreksi, maka banyak aspek konfigurasi perangkat lunak (program, dokumentasi atau data yang mendukung) akan diubah. 6

47 Pengujian regresi (subset dari pengujian yang akan dieksekusi) berisi tiga kelas test case yang berbeda, yaitu : Sampel respresentatif dari pengujian yang akan menggunakan semua fungsi perangkat lunak. Pengujian tambahan yang berfokus pada fungsi-fungsi perangkat lunak yang mungkin dipengaruhi oleh perubahan tersebut. Pengujian yang berfokus pada komponen perangkat lunak yang telah diubah. Pemilihan strategi integrasi, tergantung pada karakteristik perangkat lunak dan kadangkadang juga pada jadwal proyek. Secara umum, pendekatan yang digabungkan (sandwitch testing), yang menggunakan strategi top-down untuk tingkat yang lebih tinggi dari struktur program, dipasangkan dengan strategi bottom-up untuk tingkat subordinat. Pada saat pengujian integrasi dilakukan, penguji harus mengidentifikasi modul kritis. Modul kritis memiliki karakteristik sebagai berikut : 5. menekankan beberapa persyaratan perangkat lunak. 6. memiliki tingkat kontrol yang tinggi. 7. Kompleks (cyclomatic complexity dapat digunakan sebagai indikator). 8. memiliki persyaratan kinerja yang terbatas. Scope of Testing merangkum fungsi yang spesifik, kinerja dan karakteristik desain internal yang akan diuji. Pengujian dibatasi ; kriteria perlengkapan dari masing-masing fase pengujian digambarkan; dan batasan jadwal didokumentasikan. Test Plan menggambarkan seluruh strategi integrasi. Pengujian dibagi ke dalam phases dan builds yang menekankan fungsional spesifik dan karakteristik tingkah laku dari perangkat lunak tersebut. Misalnya pengujian integrasi untuk sebuah sistem komputer yang berorientasi pada grafik dapat dibagi ke dalam fase-fase pengujian sebagai berikut : Interaksi pemakai (seleksi perintah, representasi tampilan, pemrosesan dan respresentasi kesalahan). Manipulasi dan analisis data (pembuatan simbol, penentuan dimensi, rotasi, komputasi sifat fisis) Pemrosesan dan pemunculan tampilan (tampilan dua dimensi, tampilan tiga dimensi, grafik dan bagan) Manajemen database (akses, update, integritas, kinerja) Kriteria dan pengujian yang sesuai diaplikasikan untuk semua fase pengujian : Integritas interface. Antar muka internal dan eksternal diuji pada saat masing-masing modul (kluster) ditambahkan ke dalam struktur. Validitas fungsional. Pengujian yang didesain untuk mengungkap kesalahan fungsional yang dilakukan. Isi informasi. Pengujian yang didesain untuk mengungkap kesalahan yang berhubungan dengan struktur data global atau lokal yang dilakukuan. 7

48 Kinerja. Pengujian yang didesain untuk memeriksa batasan kinerja yang dibangun selama desain perangkat lunak dilakukan. VALIDATION TESTING (pengujian validasi) Dilakukan setelah integration testing dilakukan serta kesalahan-kesalahan yang ditemukan telah diperbaiki. Validasi berhasil jika fungsi-fungsi yang ada pada perangkat lunak telah sesuai dengan yang diharapkan oleh pemakai. Merupakan kumpulan pengujian black-box yang memperlihatkan atau menunjukkan sesuai dengan yang diperlukan. Garis besar rencana pengujian dikerjakan dan prosedur pengujian didefinisikan dengan test case yang spesifik untuk menunjukkan sesuai dengan yang diperlukan. Rencana dan prosedur dirancang untuk menjamin seluruh keperluan fungsional telah terpenuhi, seluruh performansi dapat dicapai, dokumentasi dilakukan dengan benar. Setelah pengujian dikerjakan, ada satu kemungkinan dari dua kondisi yang ada, yaitu : 3. Karakteristik performansi fungsi sesuai dengan spesifikasi dan dapat diterima. 4. Penyimpangan dari spesifikasi ditemukan dan daftar penyimpangan dibuat. Kajian Konfigurasi Merupakan elemen penting dari proses validasi. Tujuannya untuk memastikan apakah semua elemen konfigurasi perangkat lunak telah dikembangkan dengan tepat, dikatalog, dan memiliki detail yang perlu untuk mendukung fase pemeliharaan dari siklus hidup perangkat lunak. Sering disebut audit. ALPHA & BETA TESTING Sangat tidak mungkin bagi pengembang perangkat lunak untuk meramalkan bagaimana pelanggan akan benar-benar menggunakan sebuah program. Instruksi yang digunakan dapat disalah-interprestasikan, kombinasi data yang aneh dapat dipakai secara reguler, dan output yang kelihatannya sudah jelas bagi penguji tidak dapat dimengerti oleh pemakai di lapangan. Bila perangkat lunak biasa dibangun bagi satu pelanggan, maka dapat acceptance test dapat dilakukan untuk memungkinkan pelanggan memvalidasi semua persyaratan. Acceptance test dilakukan karena memungkinkan pelanggan untuk menemukan kesalahan yang lebih terinci dan membiasakan pelanggan memahami perangkat lunak yang telah dibuat. Jika perangkat lunak dikembangkan atau dibuat untuk dipakai oleh banyak pelanggan, maka tidak praktis untuk melakukan pengujian satu per satu terhadap perangkat lunak tersebut. Maka digunakan alpha dan beta testing. 8

49 Alpha testing adalah tahap pengembangan, dimana perangkat lunak atau perangkat keras yang telah dibuat dikirim ke kelompok pemakai atau pembeli yang potensial kemudian mereka akan menggunakan produk ini untuk melaporkan jika produk itu gagal? Pengujian aplha dilakukan pada sebuah lingkungan yang terkontrol. Pengujian beta dilakukan oleh pelanggan yang merupakan pemakai akhir perangkat lunak. Pengujian beta merupakan sebuah aplikasi live dari perangkat lunak dalam suatu lingkungan yang tidak dapat dikontrol oleh pengembang. Pelanggan merekam semua masalah yang ditemui selama pengujian beta dan melaporkannya kepada pengembang. Pengembang melakukan modifikasi kemudian mempersiapkan pelepasan produk ke seluruh pelanggan. SYSTEM TESTING Perangkat lunak merupakan salah satu elemen dari sistem yang berbasis komputer yang sangat besar. Perangkat lunak diintegrasi dengan elemen sistem lainnya (hardware, informasi) dan serangkaian integrasi sistem dan validasi test dilakukan. Jika pengujian gagal atau diluar scope dari pengembangan sistem dan tidak hanya dikerjakan oleh programmer, maka langkah yang diambil selama perancangan dan pengujian dapat diperbaiki Peran analis sistem antara lain : o Menangani kesalahan yang muncul dari elemen-elemen perangkat lunak o Mengerjakan serangkaian pengujian o Mencatat hasil pengujian. o Berpartisipasi dalam perencanaan dan merangcang pengujian sistem untuk menjamin kualitas perangkat lunak. o System testing adalah sederetan pengujian yang berbeda-beda dengan tujuan utama mengerjakan keseluruhan elemen dalam sistem yang telah dikembangkan. Stress Testing (pengujian stres) Didesain untuk menghadapi situasi yang tidak normal pada saat program mengalami pengujian. Dilakukan oleh sistem untuk kondisi-kondisi seperti volume data yang normal (melebihi atau kurang dari batasan), frekuensi dll. Intinya penguji berusaha untuk merusak program. Recovery Testing (pengujian perbaikan) Adalah pengujian sistem yang memaksa perangkat lunak untuk mengalami kegagalan dalam berbagai cara dan melakukan verifikasi sesuai dengan performansi yang tepat. Banyak sistem yang berbasis komputer harus melindungi dari kesalahan dan melanjutkan prosesnya dalam waktu yang telah ditentukan. 9

50 Sistem harus toleran terhadap kesalahan. Kesalahan pemrosesan tidak boleh menyebabkan keseluruhan fungsi sistem berhenti. Security Testing (pengujian keamanan) Adalah pengujian yang akan melakukan verifikasi dari mekanisme perlindungan yang akan dibuat oleh sistem, melindungi dari hal-hal yang mungkin terjadi. Penguji memerankan individu yang akan menembus sistem. Pengujian untuk mencoba menembus tingkat keamanan sebuah perangkat lunak. Strategi Sandwich Compromise, menguji perangkat lunak dengan melakukan pengujian mulai dari entry-point tertentu kemudian bergerak keatas ataupun kebawah. Volume Testing, menguji perangkat lunak dengan memberi data yang berlebihan. Configuration Testing, menguji berbagai variasi perangkat lunak diberbagai lingkungan perangkat lunak. Compatibility Testing, menguji kesesuaian sebuah perangkat lunak dengan sistem yang sedang dimanfaatkan. Timing sistem, melakukan pengujian terhadap perangkat lunak untuk evaluasi terhadap waktu tanggap dan waktu proses Yng dibutuhkan untuk menyelesaikan sebuah tugas. Enviromental Testing, menguji toleransi perangkat lunak terhadap suhu, kelembaban, gerak dan perpindahan. Human Factor Testing, menguji antarmuka perangkat lunak bersama-sama dengan pemakai. Interface Testing (pengujian interface) Dilakukan ketika modul atau subsistem diintegrasi untuk membuat sistem yang lebih besar. Setiap modul atau subsistem memiliki interface yang terdifinisi yang dipanggil oleh komponen program lain. Tujuannya adalah untuk mendeteksi kesalahan yang mungkin telah masuk ke dalam sistem karena eror interface atau asumsi invalid mengenai interface. Penting untuk pengembangan berorientasi objek 10

51 MODUL PERKULIAHAN Testing dan Implementasi SI Modul Standar untuk digunakan dalam Perkuliahan di Universitas Mercu Buana Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh Fasilkom Program Tim Dosen Studi Sistem 9 Informasi Abstract Produktivitas dan Kualitas Perangkat Lunak Kompetensi Mengerti dan Memahami Kualitas dan Produktivitas Perangkat Lunak 1

52 KUALITAS PERANGKAT LUNAK: Definisi, Pengukuran dan Implementasi Definisi Berbagai macam definisi kualitas perangkat lunak (software quality) tergantung dari mana pemakai (user) memandang dan melihat sesuai dengan kebutuhannya. Menurut Crosby (1979:34) mendefinisikan kualitas atau mutu sebagai conformance to requirements. Selama seseorang dapat berdebat tentang perbedaan antara kebutuhan, keinginan dan kemauannya, definisi kualitas harus mempertimbangkan perspektif pemakai tersebut. Kunci utama pertanyaan untuk sebuah definisi kualitas adalah siapa pemakainya, apa yang penting bagi merekadan bagaimana prioritasnya tentang metode apa yang dibangun, dibungkus untuk mendukung sebuah produk? Untuk menjawab pertanyaan tersebut, kita harus mengenali herarki dari kualitas perangkat lunak. Pertama, suatu produk perangkat lunak harus menyediakan fungsi suatu jenis dan waktu yang sama ketika pemakai memerlukannya. Kedua, produk harus berjalan. Jika produk memiliki kecacatan maka produk tersebut tentunya tidak ada konsistensi kelayakan. Para pemakai tidak akan menggunakannya dengan mengabaikan atribut-atribut yang menyertainya. Hal tersebut tidak berarti bahwa kecacatan selalu menjadi prioritas yang paling utama dalam menolak suatu produk tetapi akan menjadi sangat penting dalam melihat layak atau tidaknya. Jika tingkatan cacat minimum belum dicapai maka berbagai hal tidak ada yang perlu dipertimbangkan. Di luar ambang kualitas tersebut, bagaimanapun juga sesuatu yang berhubungan dengan pertimbangan dan penilaian cacat suatu produk perangkat lunak seperti halnya kegunaan, kecocokan, kemampuan, dan lainnya tergantung pada pemakai tersebut memandang dan menilainya termasuk didalamnya aplikasinya dan lingkungan software yang menyertainya (Humphrey, 1994). The Institute of Electrical and Electronic Engineers (IEEE) mendefinisikan kualitas sebagai the degree to which a system, component or process meets customer or user needs or expectations (IEEE90). Definisi dari IEEE digunakan dalam konteks suatu sistem perangkat lunak secara rinci. kualitas adalah suatu atribut dari sistem yang berjalan yang sangat erat kaitannya dengan resiko. Semakin tinggi resiko yang didapatkan dan kemudian dikuranginya maka akan tinggi kualitas yang dihasilkannya. Dengan cara yang sama, lebih cepat resiko dikenali dan dikurangi, akan lebih tinggi pula kualitasnya. Hasil dari sebuah aktivitas yang terencana, bukan kejadian yang spontan berbanding terbalik dengan delivery date 85% kesalahan ada pada proses,15% pada pada SDM. 2

53 Menurut definisi dalam Steve McConnell s Code Complete membagi perangkat lunak ke dalam dua hal yaitu: : internal dan external quality characteristics. Karakteristik kualitas eksternal merupakan bagianbagian dari suatu produk yang berhubungan dengan para pemakainya, sedangkan karakteristik kualitas internal tidak secara langsung berhubungan dengan pemakai. Software Quality didefinisikan sebagai: kesesuaian yang diharapkan pada semua software yang dibangun dalam hal fungsi software yang diutamakan dan unjuk kerja software, standar pembangunan software yang terdokumentasi dan karakteristik yang ditunjukkan oleh software. Definisi ini menekankan pada 3 hal yaitu: 1. kebutuhan software adalah fondasi ukuran kualitas software, jika software Tidak sesuai dengan kebutuhan yang ditentukan maka kualitaspun kurang 2. jika menggunakan suatu standar untuk pembangunan software maka jika software tidak memenuhi standar tersebut maka dianggap kurang berkualitas 3. seringkali ada kualitas yang secara langsung diutarakan (tersirat) seperti kemudahan penggunaan dan pemeliharaan yang baik. Kualitas software dipertanyakan jika tidak memenuhi kebutuhan ini. Sedangkan definisi kualitas menurut The International Organization for Standarization (ISO) mendefinisikannya sebagai: the totality of features and characteristics of a product or service that bear on its ability to satisfy specified or implied needs [11]. ISO menyoroti pada fitur-fitur dan karakteristik dari produk atau layanan dalam kemampuannya memenuhi kebutuhan yang ditentukan. menyediakan model yang berbasikan obyek dalam 3 konteks dasar yaitu: quality, requirements dan characteristics. Standar dapat membantu mendefinisikan suatu terminologi, seperti halnya kata kualitas (quality). Meskipun demikian, rata-rata suatu kata tertentu tidak menggunakan standar adalah sering sesuai dengan arti yang dimaksud. Hal ini juga benar untuk definisi ISO 8204 untuk mutu: Keseluruhan karakteristik dari suatu kesatuan dalam kemampuannya untuk memenuhi dan memuaskan pemakai yang dinyatakan dan disiratkan dalam suatu kebutuhan. Makna tersebut artinya, diperlukan suatu kualitas produk perangkat lunak yang mempunyai karakteristik tertentu yang dihubungkan dengan kebutuhan pemakai dan membuat puas penggunanya. Kualitas perangkat lunak adalah keberadaan karakteristik dari suatu produk ang dijabarkan dalam kebutuhannya, artinya kita harus melihat terlebih dahulu karakteristik-karakteristik apa yang berhubungan atau tidak dengan kebutuhankebutuhan yang diiinginkan oleh pemakai. Karakteristik yang dimaksud yaitu contraproductive characteristics dan neutral characteristic. Mengetahui karakteristik tersebut diperlukan untuk mengurangi kontra produktif dari kualitas perangkat lunak yang dimaksud dan relevan atau tidak perangkat lunak tersebut untuk kebutuhan suatu organisasi. Tidak hanya adanya keberadaan karakteristik tersebut tetapi juga tidak adanya kontra produktif dari suatu karakteristik dari suatu perangkat lunak yang diinginkan (Petrasch, 1999: 2). Kebutuhan dan karakteristik berperan penting dalam mendefinisikan suatu kualitas. Oleh karena itu, suatu model yang berbasiskan obyek bermanfaat dalam pemahaman yang lebih baik untuk masalah ini. Gambar di bawah menunjukkan suatu produk perangkat lunak, dimana untuk memenuhi suatu kebutuhan diperlukan karakteristik yang sesuai. Keberadaan hubungan antara kebutuhan dan karakteristik menjadikan dimungkinkannnta statemen yang jelas tentang kualitas suatu produk. 3

54 Hal lain yang perlu diperhatikan dalam kualitas perangkat lunak adalah quality assurarance (QA) yang merupakan cctivity of providing evidence needed to establish confidence mong ll concerned,that quality-related activities are being performed effectively (J.M.Juran). Selain itu harus adanya software quality management (SQM). Tujuan dari SQM adalah untuk mengembangkan suatu pemahaman kuantitatif dari kualitas proyek produk perangkat lunak dan mencapai tujuan spesifik kualitasnya yang digambarkan dalam table sederhana berikut: Pengukuran Kualitas Perangkat Lunak 4

55 Sistem dari kualitas perangkat lunak terintegrasi dalam tiga disiplin aplikasi yaitu: pemodelan proses pengembangan (process), pemodelan pengukuran produk (product), dan pemodelan manajemen dan interaksi manusia (human). Pemahaman suatu disiplin melibatkan pembangunan model, pengujian model dan pelajaran untuk dipahami dalam aplikasi yang nyatal. Pengembang kualitas prima perangkat lunak harus berhadapan dengan unsur-unsur matriks berikut: Model [M] [M*PROCESS] [M*PRODUCT] [M*HUMAN] Testing [T] Process Product Human = [T*PROCESS] [T*PRODUCT] [T*HUMAN] Data [D] [D*PROCESS] [D*PRODUCT] [D*HUMAN] Unsur-unsur perangkat lunak utama dari sistem kualitas perangkat lunak ditunjukkan pada gambar di bawah. Pengintegrasian dari semua unsur-unsur system kualitas memerlukan suatu model. Permasalahannya untuk diperbaiki oleh dua model berikut (1) penanganan kompleksitas dalam disiplin dari sistem kualitas dantunsur-unsurnya dan (2) penunjukan beberapa kelemahan dari model existing process. Kompleksitas proses pengembangan dan dokumentasinya serta perubahan dokumentasi selama pemeliharaan adalah permasalahan penting dalam peningkatan kualitas. Dokumentasi yang dievaluasi sering sangat banyak dan kompleks. Oleh karena itu, hubungan kompleksitas antara produk data teknis, dokumentasi perencanaan, pengujian kebutuhan dan tahapan unsur-unsur life cycle pengembangan yang berbeda mengakibatkan dokumentasi ini sulit untuk dievaluasi dalam meyakinkan semua aktivitas telah cukup dikerjakan. Dokumentasi menyediakan komunikasi antar semua kelompok terkait dengan pengembangannya dan kendali proses proyek tersebut. Schweiggert mencatat beberapa pertimbangan untuk krisis dokumentasi: Software in the application process must be constantly adapted and altered. The maintenance programmer usually does not have the time alteration to documentation. Often suitable tools are not available either. This causes the quality of documentation to suffer Metoda tradisional untuk verifikasi kualitas, seperti checklist bisa gagal dalam proses pengembangan software yang kompleks. Audit dan review tidak bisa dilakukan tanpa menggunakan bantuan dan alat yang membantu mengidentifikasi pemenuhan standar dan prosedur. Lebih dari itu, kompleksitas proses pengembangan dan perubahan yang tak terkontrol dari unsur-unsur proses secara negatif berdampak pada kualitas. Lifecycle pengembangan software yang berbeda dapat diusulkan. Hal ini dapat memungkinkan adanya perbedaan motivasi, kekuatan dan kelemahan. Tidak ada model lifecycle yang universal disesuaikan dengan lingkungan pengembangannya. Dalam model lifecycle tradisional, hubungan antara tahapan unsur-unsur lifecycle pengembangan software yang berbeda tidaklah cukup terwakili. Oleh karena itu, sulit untuk menguraikan efek segala perubahan dalam kebutuhannya yang ditetapkan atas kualitas, keselamatan dan sasaran hasil dari perangkat lunak. Lebih dari itu, keberadaan komputer dapat membantu untuk aplikasi model proses yang tidak fleksibel dan sulit untuk ditangani karena kekompleksitasnya. Dalam lifecycle pengembangan software, Identifikasi hubungan antara kelompok organisasi sangat penting untuk beberapa 5

56 pertimbangan berikut: (1) Pengembangan Proses harus berhadapan dengan kompleksitas dan perubahan kebutuhan, pengujian metoda, teknologi, ukuran dan lain lain; (2) Kesalahan perangkat lunak yang dihasilkan baik dalam suatu tahapan proses pengembangan software maupun sebagai alat penghubung antara dua tahapan; (3) Dukungan kuat dari manajemen puncak merupakan suatu faktor utama dalam mempengaruhi proses pengembangan tersebut. Menururut Wahono (2006), Deras masuknya produk perangkat lunak dari luarnegeri di satu sisi menguntungkan pengguna karena banyaknya pilihan produk dan harga. Namun di sisi lain cukup mengkhawatirkan karena di Indonesia tidak ada institusi yang secara aktif bertugas membuat standard dalam pengukuran kualitas perangkat lunak yang masuk ke Indonesia. Demikian juga dengan produk-produk perangkat lunak lokal, tentu akan semakin meningkat daya saing internasionalnya apabila pengembang dan software house di Indonesia mulai memperhatikan masalah kualitas perangkat lunak ini. Kualitas perangkat lunak (software quality) adalah tema kajian dan penelitian turun temurun dalam sejarah ilmu rekayasa perangkat lunak (software engineering). Kajian dimulai dari apa yang akan diukur (apakah proses atau produk), apakah memang perangkat lunak bisa diukur, sudut pandang pengukur dan bagaimana menentukan parameter pengukuran kualitas perangkat lunak. Bagaimanapun juga mengukur kualitas perangkat lunak memang bukan pekerjaan mudah. Ketika seseorang memberi nilai sangat baik terhadap sebuah perangkat lunak, orang lain belum tentu mengatakan hal yang sama. Sudut pandang seseorang tersebut mungkin berorientasi ke satu sisi masalah (misalnya tentang reliabilitas dan efisiensi perangkat lunak), sedangkan orang lain yang menyatakan bahwa perangkat lunak itu buruk menggunakan sudut pandang yang lain lagi (usabilitas dan aspek desain). Apa yang diukur? Pertanyaan pertama yang muncul ketika membahas pengukuran kualitas perangkat lunak, adalah apa yang sebenarnya mau kita ukur. Kualitas perangkat lunak dapat dilihat dari sudut pandang proses pengembangan perangkat lunak ( process) dan hasil produk yang dihasilkan (product). Dan penilaian ini tentu berorientasi akhir ke bagaimana suatu perangkat lunak dapat dikembangkan sesuai dengan yang diharapkan oleh pengguna. Dari sudut pandang produk, pengukuran dapat dilakukan dengan cara sebagai berikut: Parameter dan metode pengukuran menurut Kelvin dalam Wahono (2006), When you can measure what you are speaking about, and express it in numbers, you know something about it. But when you can not measure it, when you can not express it in numbers, your knowledge is of a meagre and unsatisfactory kind. Pendekatan engineering menginginkan bahwa kualitas perangkat lunak ini dapat diukur secara kuantitatif, dalam bentuk angka-angka yang mudah dipahami oleh manusia. Untuk itu perlu ditentukan parameter atau atribut pengukuran. Menurut taksonomi McCall, atribut tersusun secara hirarkis, dimana level atas (high-level attribute) disebut faktor (factor), dan level bawah (low-level attribute) disebut dengan kriteria (criteria). Faktor menunjukkan atribut kualitas produk dilihat dari sudut pandang pengguna. Sedangkan kriteria adalah parameter kualitas produk dilihat dari sudut pandang perangkat lunaknya sendiri. Faktor dan kriteria ini memiliki hubungan sebab akibat (causeeffect). Tabel berikut menunjukkan daftar lengkap faktor dan kriteria dalam kualitas perangkat lunak menurut McCall 6

57 Kualitas software diukur dengan metode penjumlahan dari keseluruhan kriteria dalam suatu faktor sesuai dengan bobot (weight) yang telah ditetapkan. Rumus pengukuran yang digunakan adalah: Fa = w1c1 + w2c2 + + wncn Dimana: Fa adalah nilai total dari faktor a wi adalah bobot untuk kriteria i ci adalah nilai untuk kriteria i Kemudian tahapan yang harus kita tempuh dalam pengukuran adalah sebagai berikut: Tahap 1: Tentukan kriteria yang digunakan untuk mengukur suatu faktor Tahap 2: Tentukan bobot (w) dari setiap kriteria (biasanya 0 <= w <= 1) Tahap 3: Tentukan skala dari nilai kriteria (misalnya, 0 <= nilai kriteria <=10) Tahap 4: Berikan nilai pada tiap kriteria Tahap 5: Hitung nilai total dengan rumus Fa = w1c1 + w2c2 + + wncn 7

58 Contoh pengukuran perangkat lunak Untuk mempermudah pemahaman, akan diberikan sebuah contoh pengukuran kualitas perangkat lunak dari faktor usabilitas (usability). Yang akan diukur adalah dua buah perangkat lunak yang memiliki fungsi untuk mengkontrol peralatan elektronik (electronic device). Perangkat lunak yang pertama bernama TukangKontrol, sedangkan kedua bernama Caktrol. Contoh dan hasil pengukuran dapat dilihat pada Table 3 dan Dari penghitungan yang ada di Tabel 4, dapat kita simpulkan bahwa dari faktor usabilitas, kualitas dari perangkat lunak bernama TukangKontrol lebih baik daripada Caktrol. Nilai total TukangKontrol untuk faktor usabilitas adalah 16.8, sedangkan Caktrol adalah 10.2 (dari maksimum total nilai 20). 4. Mengapa Software Quality Engineering perlu dipikirkan? Penerapan suatu rumusan pemrograman sederhana jawaban bisa diperkenalkan cara yang berikut: RISK= F (1/quality) Atau kualitas yang ditingkatkan untuk mengurangi resiko Suatu metode di mana hasil dari resiko dari kualitas yang pudar dapat dimanifestasikan lebih banyak, bagaimanapun untuk seorang pemakai yang berpengalaman dikenali dalam contoh berikut: Kerugian Sosial atau profesional (nformasi/data, waktu, uang, pekerjaan dll.) 8

59 Kerugian kesehatan atau kehidupan ( contoh: pasien over-x-rayed dalam suatu rumah sakit) Jelaslah bahwa sebagai pemakai mungkin akan bermimpi untuk mengharapakan adanya bug-free yang merupakan tingkatan paling tinggi kualitasnya dengan harga yang serendah-rendahnya. Akan tetapi seberapa besar hal tersebut terjadi, tergantung dari SQE oleh perusahaan pengembangan software. Paling mungkin ada suatu kesempatan untuk tidak membeli perangkat lunak yang jelas ada cacat produksinya. Rendahnya kualitas perangkat lunak merupakan resiko yang didapat suatu organisasi yang membelinya dan terkadang suatu pengembang ataupun supplier tidak ambil pusing bahkan tidak mau disalahkan. Berdasarkan pengalaman, resiko yang paling besar sebagai hasil dari rendahnya kualitas perangkat lunak sering didapatkan oleh pemakai dan hanya sedikit yang didapatkan oleh penyalur perangkat lunak. Karena itu harus ada suatu kompromi antara developer atau supplier dan pemakai tentang perangkat lunak yang akan dibeli sehingga diharapkan tidak ada yang dirugikan dari transaksi yang terjadi. Menentukan Kualitas Perangkat Lunak Dipandang dari sudut hipotesis, para ahli dalam membuat dan menentukan kualitas perangkat lunak sebaiknya menerapkan, mengukur, mengevaluasi dan meningkatkan mutu perangkat lunak sepanjang lifecycle-nya. Pengetahuan yang luas tentang rekayasa perangkat lunak memerlukan suatu pendekatan yang terstruktur dan sistematis dengan mempertimbangkan pengalaman yang diperolehnya. Jika mungkin, disesuiakan dengan praktek industri sebenarnya. Suatu pendekatan terstruktur tidak terbatas pada tiga komponen utama yang terpusat pada inti pengetahuan perangkat lunak. Contohnya komponen Quality Requirements didapatkan dengan adanya prasyarat: Kualitas kebutuhan (Quality requirements) Pengukuran kualitas dan instrument evaluasi (Quality measurement and evaluation instruments) Implementasi kualitas dalam lifecycle (In-lifecycle quality implementation) Pengetahuan dalam mendapatkan komponen Quality requirement (QR) sangat diperlukan terutama bagi kalangan ahli software dalam mempertimbangkan dan memperoleh kebutuhan yang berkualitas sehingga benar-benar didapatkan high-level stakeholder s requirements. Karena itu untuk mendapatkan kemudian untuk QR digambarkan pengukuran kualitas dalam gambar di bawah ini: 9

60 Model dekomposisi yang diusulkan didasarkan pada model kualitas dari ISO/IEC 9126 dalam konjungsi dengan standar TL 9000, dimana kontribusi dari penggunaan QR adalah untuk menetapkan kebutuhan mutu eksternal (External Quality requirements), yang mana pada gilirannya berperan untuk menetapkan kebutuhan mutu internal (Internal Quality requirements). Model tersebut didokumentasikan dengan baik sehingga relatif mudah untuk dipelajari dan digunakan akan tetapi sedikit statis dalam perubahannya. Karena itu, ahli SQ yang baik seharusnya mengetahuinya tidak hanya apa? tetapi juga bagaimana? Pendekatan ini ditujukan oleh model tersebut untuk proses praktis dalam melukiskan dan mengendalikan kualitas kebutuhan 10

61 Pada gambar di atas, anak panah dengan garis yang tidak putus-putus menunjukkan alur tentang bagaimana, yaitu menanyakan tentang eksekusi dekomposisi kebutuhan. Yang ada dalam kotak berisi tentang pertanyaan apa, yaitu menggambarkan kebutuhan apa yang diakibatkan oleh proses dekomposisi. Sedangkan anak panah dengan garis putus-putus menandai adanya alur pokok dari traceability kebutuhan. Pengetahuan teoritis dan praktis yang menjawab pertanyaan diatas membutuhkan ahli yang berkompeten tentang SQ untuk mengatur proses definisi dan analisis kebutuhan. Komponen dari The Quality measurement and evaluation instruments memiliki tujuan untuk mendidik para ahli SQ tentang keberadaan model kebutuhan dan mengukur pemilihan perangkat lunak dalam proses mendukung aktivitasnya. Demikian juga, dua unsur tersebut sebaiknya didokumentasikan sehingga mudah untuk dipelajari walau sedikit statis. Rancang bangun merupakan bagian dari pengetahuan dimana pemetaan tentang suatu instrumen ke dalam tahapan lifecycle perangkat lunak trlihat pada gambar di bawah sangat sedikit didokumentasikan dan memerlukan riset lebih lanjut. 11

62 Komponen terakhir dari hasil lifecycle quality implementation diakibatkan oleh dua Komponen yang sebelumnya di mana pengetahuan dasar telah didaptkan. Implementasi sekarang memerlukan aplikasi yang praktis tidak sekedar dengan pengetahuan tersebut tetapi juga dalam proses pengembangan perangkat lunak. Pengukuran Perangkat Lunak Menggunakan Metrik Size-Oriented dan Metrik Function Oriented. PENGANTAR: Pengukuran adalah suatu hal pokok bagi disiplin perekayasaan(engineering), tidak terkecuali pada perekayasaan perangkat lunak atau software. Jangkauan luas pengukuran pada perangkat lunak komputer disebut metrik perangkat lunak. Tujuan diterapkannya pengukuran pada proses perangkat lunak adalah untuk mengembangkan perangkat lunak itu sendiri dengan dasar yang kontinu. Pengukuran software dalam konteks manajemen software difokuskan pada produktivitas dan 12

63 metrik kualitas (pengukuran output perkembangan software sebagai fungsi usaha dan waktu yang diaplikasikan serta pengukuran kesesuaian pemakaian dari produk kerja yang dihasilkan). 1. PENGUKURAN, METRIK, DAN INDIKATOR Dalam konteks rekayasa perangkat lunak, mengukur (measure) mengindikasikan kuantitatif dari ukuran atribut sebuah proses atau produk. Pengukuran (measurement) adalah kegiatan menentukan sebuah measure (pengukuran). Dan definisi metriks menurut IEEE adalah ukuran kuantitatif dari tingkat dimana sebuah system, komponen atau proses memiliki atribut tertentu. Pengukuran telah ada jika suatu data-data tunggal telah dikumpulkan (misal: jumlah kesalahan yang ditemukan pada kajian sebuah modul tunggal). Metrik perangkat lunak menghubungkan pengukuran-pengukuran individu dengan banyak cara, misal rata-rata dari jumlah kesalahan yang ditemukan pada setiap kajian. Rekayasa perangkat lunak mengumpulkan pengukuran dan mengembangkan metrik menjadi sebuah indikator, yaitu sebuah metrik atau kombinasi metrik yang memberikan pengetahuan dalam proses perangkat lunak, sebuah proyek perangkat lunak, atau produk itu sendiri. Fungsinya adalah memberi pengetahuan pada manajer proyek atau perekayasa perangkat lunak untuk menyesuaikan proses, proyek, dan produk agar menjadi lebih baik. 2. PENGUKURAN PERANGKAT LUNAK Pengukuran langsung dari produk berkaitan dengan deretan kode, kecepatan eksekusi, ukuran memori, dan cacat yang dilaporkan pada suatu periode tertentu. Sedangkan pengukuran tidak langsung dari produk adalah tentang fungsionalitas, kualitas, kompleksitas, efisiensi, realibilitas, kemampuan pemeliharaan, dsb.dalam kenyataannya, pengukuran perangkat lunak secara objektif akan sulit dilakukan secara langsung karena ada pengaruh-pengaruh seperti individu dalam tim pengukuran, atau tingkat kompleksitas proyek. Tetapi jika pengukuran dinormalisasi, maka mungkin akan dapat didapatkan metrik perangkat lunak yang memungkinkan perbandingan dengan rata-rata organisasional yang lebih besar. METRIK SIZE ORIENTED Parameternya adalah ukuran dari software yang dihasilkan. Dapat dilakukan jika ada record atau catatan dari organisasi. Perlu diperhatikan bahwa yang record yang diperlukan adalah keseluruhan aktivitas rekayasa perangkat lunak. Misalnya tabel dibawah ini adalah pengumpulan dari data-data record yang ada dari sebuah organisasi: 13

64 Dimana LOC (line of code) menunjukkan jumlah baris kode yang dibuat pada masing-masing proyek, misalnya pada kolom pertama, proyek aplha dibuat dengan baris kode dalam 365 halaman, dikembangakan dengan usaha 24 orang per bulan dengan biaya $ Lalu ditemukan kesalahan sebanyak 134 pada proyek sebelum direlease, 29 cacat setelah direlease pada pelanggan, dan ada 3 orang yang bekerja pada pengembangan proyek perangkat lunak alpha. Untuk pengembangan dari metrik ini, dapat dibuat metrik size oriented baru yang sederhana untuk tiap proyek, misal: kesalahan per baris kode (dihitung ribuan), cacat per baris kode (ribuan), dokumentasi per baris kode (ribuan), kesalahan per usaha, baris kode per usaha, biaya per halaman dokumentasi, dsb. Metrik ini tidak dapat diterima secara universal karena adanya kontroversi pada penggunaan baris kode sebagai titik ukur. Sebagian yang setuju pada pengukuran LOC menganggap bahwa LOC adalah suatu bukti real dari apa yang dilakukan oleh perekayasa perangkat lunak (dalam konteks ini membuktikan berapa banyak baris program yang ditulis oleh seorang programmer comment yang ada). Sedangkan sebagian yang tidak setuju bahwa LOC dijadikan suatu tolak ukur kebanyakan disebabkan alasan ambiguitas dari cara menghitung LOC itu sendiri. Dalam masa-masa awal bahasa pemrograman Assembly, hal ini tidak menjadi suatu masalah karena dalam 1 baris aktual program merupakan 1 baris instruksi, tetapi dalam bahasa pemrograman tingkat tinggi, dimana pada masing-masing bahasa, untuk menyelesaikan suatu masalah dengan algoritma yang sama pun LOC nya sudah berbeda-beda. Bahkan dalam satu bahasa pemrograman yang sama, untuk menyelesaikan masalah yang sama, LOC nya bisa berbeda jauh tergantung dari algoritma yang digunakan. Hal ini yang membuat banyak sekali kontroversi mengenai LOC sebagai tolak ukur dari sebuah software. METRIK FUNCTION ORIENTED Normalisasi dilakukan pada fungsionalitas pada aplikasi, tetapi untuk melakukan hal ini, fungsionalitas harus diukur dengan pengukuran langsung yang lain karena fungsionalitas tidak dapat diukur secara langsung. Maka pengukuran dapat dilakukan dengan pengukuran function point. Function point didapat dari penarikan hubungan empiris berdasarkan pengukuran domain informasi software dan perkiraan kompleksitas software. Domain informasi yang biasa digunakan ada 5 karakteristik, yaitu: 14

65 1. jumlah input pemakai: setiap input pemakai yang memberikan data yang berorientasi pada aplikasi yang jelas pada perangkat lunak (harus dibedakan dari penelitian yang dihitung secara terpisah) misal: tipe transaksi. 2. jumlah output pemakai: setiap output pemakai yang memberikan informasi yang berorientasi pada aplikasi kepada pemakai. Pada konteks ini output mengacu pada laporan, layar, tampilan kesalahan, dsb. Jenis data individual pada laporan tidak dihitung terpisah. misal: report type. 3. jumlah penyelidikan pemakai: input online yang mengakibatkan munculnya beberapa respon perangkat lunak yang cepat dalam bentuk output online 4. jumlah file: setiap master logika (pengelompokan data logis yang menjadi suatu bagian dari sebuah database yang besar atau sebuah file terpisah). 5. jumlah interface eksternal: semua interface yang dapat dibaca oleh mesin yang digunakan untuk memindahkan informasi ke sistem yang lain Sekali data telah dikumpulkan, maka nilai kompleksitas dihubungkan dengan masing-masing penghitungan dengan tabel perhitungan sebagai berikut: Faktor pembobotan Dalam hal ini faktor pembobotan setiap faktor sudah menjadi standar dan tidak dapat diubahubah, tetapi dalam penentuan kriteria suatu perangkat lunak pada salah satu parameter pengukuran adalah sederhana, rata-rata atau kompleks ditentukan oleh organisasi atau perkeyasa perangkat lunak yang melakukan penghitungan itu sendiri. Tetapi meskipun begitu perkiraan kompleksitas tetap bersifat subyektif. Untuk menghitung function point (FP) dapat digunakan hubungan sbb: FP = jumlah total x [0,65 + 0,01 x Fi] dimana jumlah total adalah nilai yang kita dapatkan pada tabel perhitungan di atas. Sedangkan Fi dapat dihitung dari perhitungan sebagai berikut: Pertama-tama kita diberi 14 buah karakteristik dari suatu perangkat sebagai berikut: 1. Data communications 2. Distributed functions 3. Performance. 4. Heavily used configuration 15

66 5. Transaction rate 6. Online data entry 7. End-user efficiency 8. Online update 9. Complex processing 10. Reusability 11. Installation ease 12. Operational ease 13. Multiple sites 14. Facilitation of change Pada setiap karakteristik tersebut diberi bobot dari nilai 0 sampai 5 dengan asumsi nilai sebagai berikut: 0. Tidak berpengaruh 1. Insidental 2. Moderat 3. Rata-rata 4. Signifikan 5. Essential Setelah setiap karakteristik diberi bobot masing-masing, lalu bobot-bobot dari setiap karakteristik ini dijumlahkan (jadi minimum 0 dan maksimal 70) dan kita akan mendapatkan nilai Fi. Setelah mendapatkan nilai Fi maka kita bisa menghitung nilai FP dengan rumus di yang sudah ada di atas. Setelah kita mendapatkan nilai FP, maka kita dapat menggunakannya dengan cara analog dengan LOC untuk menormalisasi pengukuran produktivitas, kualitas perangkat lunak, serta atribut-atribut yang lain seperti: kesalahan per FP cacat per FP $ per FP halaman dokumentasi per FP FP per person-month dsb (dimana untuk mendapatkan data-data untuk kesalahan, cacat, dolar, dsb dapat diambil dari data-data pada tabel record pada metrik size-oriented). Contoh: Pada proyek alpha (tabel record metrik size oriented) sudah dihitung bahwa jumlah input pemakainya ada 18 buah, jumlah output pemakai: 6 buah, jumlah penyelidikan pemakai 22 buah, jumlah file 45 buah, jumlah interface eksternal 20 buah, dengan asumsi bahwa jumlah input pemakai rata-rata, jumlah output pemakai sederhana, jumlah penyelidikan pemakai rata-rata, jumlah file kompleks, jumlah interface eksternal sederhana. Semua karakteristik pada perangkat lunak ini moderat. Hitung $ per FP nya! Jawab: 16

67 jumlah total = (18 x 4) + (6 x 4) + (22 x 4) + (45 x 15) + (20 x 6) = 979 Fi = 14 x 2 = 28 FP = 979 x (0,65 + (0,01 x 28)) = 910,47 $ pada proyek alpha: $ per FP = / 910,47 = $184,52 Hasil dari contoh kasus diatas masih berupa suatu angka mentah, untuk dapat dilihat apakah angka ini termasuk baik atau tidak harus diperbandingkan dengan perhitungan lain, misalnya $ per FP dari proyek beta atau gamma, atau proyek dari organisasi lain. Sebenarnya banyak sekali metrik-metrik yang digunakan untuk mengukur perangkat lunak, misalnya metrik FP yang diperluas (biasanya diaplikasikan dalam dunia bisnis) tetapi belum sempat dibahas disini. 17

68 MODUL PERKULIAHAN Testing dan Implementasi SI Modul Standar untuk digunakan dalam Perkuliahan di Universitas Mercu Buana Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh Fasilkom Program Tim Dosen Studi Sistem 10 Informasi Abstract Metriks untuk Object Oriented Software Kompetensi Metrik Teknis Untuk Sistem Berorientasi Objek 1

69 2

70 METRIK PENGEMBANGAN PERANGKAT LUNAK BERORIENTASI OBJEK: Pengembangan dan desain perangkat lunak berorientasi objek saat ini sangat populer. Perbedaan utama antara pemrograman terstruktur dengan berorientasi objek adalah pada pemrograman terstruktur fundamental pembangunan program adalah algoritma. Sedangkan pada pemrograman berorientasi objek menggunakan objek sebagai fundamentalnya. Dalam pengembangan perangkat lunak berorientasi objek, supaya perangkat lunak/source code yang kita buat berkualitas harus memperhatikan kaidah-kaidah seperti reusability, understandability, maintainability dan testability. Reusability adalah kemampuan kode yang kita buat bisa digunakan lagi pada aplikasi lain maupun pada aplikasi itu sendiri. Kode yang kita buat harus mudah dimengerti(understanbility) supaya mudah di maintenace. Selain itu, kode yang kita buat usahakan sederhana(simplicity) sehingga mudah dilakukan pengujian (testing). Nah pertanyaannya sekarang, bagaimana kita mengetahui kualitas kode yang kita buat? Bagaimana cara mengukurnya? Metrics software merupakan tools yang bisa digunakan untuk mengukur kode yang kita buat dengan berbagai macam tipe pengukuran yang berhubungan dengan sistem, proses atau dokumen terkait dalam perangkat lunak. Metrics membantu dalam melakukan evaluasi terhadap pengembangan dan testing yang perlu dilakukan dalam suatu sistem yang meliputi aspek testability, understandability, maintainability dan reusability. Metrics yang bisa digunakan untuk mengukur perangkat lunak berorientasi objek bisa juga metrik tradisional(pada pemrograman struktural) dan metrik yang khusus digunakakan untuk pengembangan perangkat lunak berbasis objek. Pada posting ini kami akan membahas paper berjudul Applying and Interpreting Object Oriented Metrics yang ditulis oleh Dr. Linda H. Rosenberg. Paper ini membahas tentang Software Assurance Technology Center (SATC) pada NASA Goddard Space Flight Center yang melakukan pendekatan untuk memilih metrics untuk project dengan terlebih dahulu mengidentifikasi atribut yang terkait dengan pengembangan berorientasi objek. Cakupan bahasan tersebut meliputi penjelasan metrik-metrik tersebut, termasuk, cara menghitung dan bagaimana cara membacanya. Kami juga mengambil studi kasus dari tugas Character Graphics pada mata kuliah TPL. Pada paper ini, SATC mengusulkan panduan interpretasi metrik-metrik dengan cara melihat kenapa suatu nilai metrik berbeda dari satu modul dengan modul lainnya, kemudian menginvestigasinya. Berikut tabel intepretasi metrik. 3

71 Dalam penjelasan masing-masing metrik penghitungan metrik dilakukan pada kelas Character Graphic. Berikut adalah kelas diagram Character Graphic. Metric software: Cyclomatic Complexity (CC) Cyclomatic Complexity (CC) merupakan metrik tradisional yang menghitung tingkat kompleksitas suatu method/procedure. Metrik ini bisa diterapkan pada pemrograman berorientasi objek untuk menghitung kompleksitas suatu method. Kompleksitas dalam method merujuk kepada berapa jumlah test case yang diperlukan untuk mengevaluasi method tersebut sehingga setiap percabangan didalam method tersebut pernah dilalui. Cyclomatic Complexity (CC) secara langsung tidak bisa digunakan untuk mengukur kompleksitas kelas. Menurut sumber kami, hal tersebut tidak bisa karena adanya pewarisan dalam code. Namun Cyclomatic Complexity (CC) bisa menghitung kompleksitas kelas jika dikombinasikan dengan pengukuran lain. Cyclomatic Complexity (CC) berpengaruh terhadap Understandability, Maintainability dan Testing. Semakin kompleks suatu method berpengaruh terhadap semakin sulit untuk memahami method tersebut dan tentu saja akan semakin sulit jika nantinya ingin melakukan memaintenace method tersebut. Selain itu, tentu saja akan berpengaruh terhadap kompleksitas pengujian yang dilakukan terjadap method tersebut. Dalam menghitung Cyclomatic Complexity (CC) dalam method, statement disimbolkan dengan node dan aliran program dilambangkan dengan edge. Nilai Cyclomatic Complexity (CC) merupakan jumlah edges-jumlah node +2. Berikut contoh penghitungan CC. 4

72 Berikut contoh perhitungan CC dari code. Nilai CC 4 yang dihasilkan berarti diperlukan 4 test case untuk menguji method tersebut Kami juga melakukan penghitungan nilai CC pada program Character Graphic, diperoleh hasil seperti berikut. 5

73 CC tertinggi ditemukan pada kelas Drawing Package. Nilai CC Drawing Package sangat significant dibanding dengan kelas-kelas lain. Ini terjadi karena kelas Drawing Package merupakan kelas yang berisi banyak kondisional case untuk menterjemahkan menu-menu diinput. Metric software : Size Metric Size merupakan metrik tradisional yang digunakan untuk mengevaluasi tingkat kemudahan untuk mengerti code oleh developer dan mainteners. Seperti metrik Cyclomatic Complexity, Metrik size juga berpengaruh terhadap understandbility, maintainability dan testing. Semakin rendah nilai metrik size, maka semakin mudah untuk mengerti dan memelihara method tersebut. Ada beberapa cara untuk menghitung size dari method, diantaranya adalah Line of Code (LOC), Non-Comment Non Blank (NCNB) dan Executable Statements(EXEC). LOC menghitung seluruh baris dalam program, NCNB menghitung semua baris yang tidak berisi komentar dan tidak kosong sedangkan EXEC menghitung banyaknya jumlah statement excecutable tanpa memperhatikan jumlah LOC. LOC dan NCNB sangat dipengaruhi oleh bahasa pemrograman dan style dari programmer. pengukuran Exec paling sedikit dipengaruhi oleh programmer, Exec sangat bagus digunakan untuk mengukur metric size terutama jika project menggunakan banyak bahasa pemrograman seperti yang dilakukan oleh SATC yang menggunakan EXEC untuk mengevaluasi project size. Berikut contoh perhitungan metric size. IF X=3 Then Y=10 Nilai LOC= 3, NCNB=3, EXEC=1 6

74 Berikut hasil pengukuran metrik size pada Characters Graphic LOC = 6, NCNB = 5, EXEC = 1. Metric Software : Comment Percentage Total Comments=1, LOC=6, Blank line =0, CP = 1/(6-0) x 100% =17% Berikut hasil metric comment percentage Characters Graphic 7

75 New Object Oriented Metric Metric Software : Weighted Methods per Class (WMC) WMC termasuk metrik untuk object oriented yang mengukur banyaknya method yang diimplementasikan dalam kelas atau jumlah keseluruhan kompleksitas method (CC). Dalam paper sumber kami, WMC dihitung berdasarkan banyaknya method yang terdapat dalam kelas. WMC berpengaruh terhadap understandability, maintenance dan reusability. Semakin banyak method yang terdapat kelas, maka semakin sulit untuk memahami kelas tersebut dan semakin sulit untuk melakukan pemeliharaan. Disamping itu, dengan semakin banyak method didalam suatu kelas, maka kelas tersebut semakin tidak reusable. Untuk menghitung WMC dilakukan secara sederhana, yaitu menghitung banyaknya suatu method dalam kelas tersebut. Contohnya pada kelas dibawah ini, WMC nya adalah 6. Berikut hasil WMC yang didapatkan pada program Character Graphic 8

76 Pada paper sumber kami, diperoleh Histogram WMC seperti dibawah ini. Histogramtersebut memperlihatkan bahwa sebagian besar class memiliki WMC yang kurang dari 20 dan terdapat beberapa class dengan WMC lebih besar dari 100. Beberapa class dengan WMC tertinggi merupakan kandidat class yang perlu untuk diperiksa atau perlu dilakukan revisi.histogram ini juga berguna untuk melakukan monitor kompleksitas terhadap waktu. Metric Software : Response for Class (RFC) RFC(Response for Class) merupakan metrik yang menghitung banyaknya method yang kemungkinan di eksekusi sebagai response atas message objek dari kelas tersebut. RFC Menyatakan banyaknya method lokal dan banyaknya method yang dipanggil oleh method lokal termasuk semua method dalam kelas hirarki dan juga termasuk kelas library(kecuali method print). Method tersebut menghitung method secara rekursif. Method yang sama cukup dihitung sekali. sumber 9

77 Metrik ini berpengaruh terhadap Testability dan Reuseablility. Semakin banyak method yang ada pada kelas tersebut + method kelas lain yang dipanggil maka kelas tersebut akan semakin sulit ditesting dan semakin tidak reusable. RFC pada code dibawah adalah : RFC(tool)=1(self)+1(drawing) RFC(tool)=2; Berikut hasil RFC pada kelas Characters Graphic. Sedangkan grafik yang dihasilkan pada paper yang kami bahas seperti di bawah ini. Pada gambar dibawah, terdapat beberapa class didalam project yang dalam prosesnya dapat melibatkan lebih dari 200 method. Class dengan RFC yang besar memiliki kompleksitas yang tinggi dan mengurangi understandability dari class tersebut, sehingga menyebabkan testing dan debugging menjadi rumit. 10

78 Metric software: Lack of Cohesion (LCOM) LCOM digunakan untuk mengukur derajat kemiripan method oleh variabel input data atau atribut dalam class. Semakin besar nilai LCOM pada suatu class mengindikasikan meningkatnya kompleksitas sehingga meningka levitra online tkan kemungkinan dari error selama proses pengembangan. Class dengan nilai LCOM yang ditinggi dapat dibagi menjadi dua atau lebih subclass sehingga dapat meningkatkan nilai cohesi dari class. Semakin kecil nilai LCOM pada suatu class mengindikasikan meningkatnya reuseability, maintainabilty dan understanability. Berikut rumus yang digunakan untuk menghitung LCOM: Berikut contoh perhitungan LCOM pada class Cshape: 11

79 Cara perhitungan : Berikut hasil pengukuran metrik LCOM pada program Characters Graphic 12

80 Pada paper berjudul Applying and Interpreting Object Oriented Metrics yang ditulis oleh Dr. Linda H. Rosenberg disajikan aplikasi dan interpretasi dari metric LCOM dengan menggunakan NASA project data sebagai berikut: Dari grafik plot yang disajikan diatas, kita dapat melihat pengukuran LCOM yang dibandingkan dengan kemungkinan maksimumnya dari LCOM. Nilai LCOM maksimum bila tidak irisan atribut diantara method di dalam class atau q=0. write my paper for me Rich Text Area Toolbar Bold (Ctrl / Alt + Shift + B) Italic (Ctrl / Alt + Shift + I) Strikethrough (Alt + Shift + D) Unordered list (Alt + Shift + U) Ordered list (Alt + Shift + O) Blockquote (Alt + Shift + Q) Align Left (Alt + Shift + L) Align Center (Alt + Shift + C) Align Right (Alt + Shift 13

81 + R) Insert/edit link (Alt + Shift + A) Unlink (Alt + Shift + S) Insert More Tag (Alt + Shift + T) Toggle spellchecker (Alt + Shift + N) Toggle fullscreen mode (Alt + Shift + G) Show/Hide Kitchen Sink (Alt + Shift + Z) Format Paragraph Underline Align Full (Alt + Shift + J) Select text color Paste as Plain Text Paste from Word Remove formatting Insert custom character Outdent Indent Undo (Ctrl + Z) Redo (Ctrl + Y) Help (Alt + Shift + H) LCOM digunakan untuk mengukur derajat kemiripan method oleh variabel input data atau atribut dalam class. Semakin besar nilai LCOM pada suatu class mengindikasikan meningkatnya kompleksitas sehingga meningkatkan kemungkinan dari error selama proses pengembangan. Class dengan nilai LCOM yang ditinggi dapat dibagi menjadi dua atau lebih subclass sehingga dapat meningkatkan nilai cohesi dari class. Semakin kecil nilai LCOM pada suatu class mengindikasikan meningkatnya reuseability, maintainabilty dan understanability. Berikut rumus yang digunakan untuk menghitung LCOM: Berikut contoh perhitungan LCOM pada class Cshape: Cara perhitungan : Berikut hasil pengukuran metrik LCOM pada program Characters Graphic Pada paper berjudul Applying and Interpreting Object Oriented Metrics yang ditulis oleh Dr. Linda H. Rosenberg disajikan aplikasi dan interpretasi dari metric LCOM dengan menggunakan NASA project data sebagai berikut: Dari grafik plot yang disajikan diatas, kita dapat melihat pengukuran LCOM yang dibandingkan dengan kemungkinan maksimumnya dari LCOM. Nilai LCOM maksimum bila tidak irisan atribut diantara method di dalam class atau q=0. Path Metric software: Coupling Between Object Classes (CBO) CBO digunakan untuk menghitung jumlah class lainnya yang non-inheritance dimana class tersebut di couple. Couple yang dimaksudkan adalah didalam satu class memanggil method dari class lainnya. Class-class yang memiliki nilai CBO yang tinggi dapat mengganggu desain modular dan mencegah reuseablity dari suatu class. Untuk meningkatkan modularitas dan mendukung enkapsulasi, CBO seharusnya dijaga tetap minimum. Karena semakin banyak couple, semakin besar sensivitas di dalam desain sehingga pemeliharaan menjadi semakin rumit. Apabila ada class lain yang dipanggil lebih dari 1x maka akan tetap dihitung sebagai 1x pemanggilan. Berikut contoh perhitungan CBO pada class Tool: Berikut hasil pengukuran metrik CBO pada program Characters Graphic 14

82 Pada paper berjudul Applying and Interpreting Object Oriented Metrics yang ditulis oleh Dr. Linda H. Rosenberg disajikan aplikasi dan interpretasi dari metric CBO dengan menggunakan NASA project data sebagai berikut: Pada gambar grafik diatas, kita melihat bahwa dari 240 class, lebih dari 1/3 nya berdiri sendiri(terdapat lebih dari 80 class memiliki CBO=0). Semakin besar CBO suatu class mengindikasikan bahwa class tersebut kemungkinan lebih sulit dimengerti, susah untuk digunakan kembali(reuse) dan lebih sulit untuk dimaintain. Metric software: Depth of Inheritance Tree (DIT) 15

83 DIT digunakan untuk mengukur kedalaman dari suatu class pada inheritance hierarchy tree. DIT dihitung dengan cara menghitung jumlah tingkatan dari kelas node ke root dari inheritance hierarchy tree. Semakin besar nilai DIT pada suatu class maka semakin banyak method yang diwarisi sehingga semakin rumit untuk mengamati tingkah laku dari class tersebut tetapi semakin besar reuseability dari method yang diwarisi. Berikut contoh perhitungan DIT pada program Characters Graphic: Berikut hasil pengukuran metrik DIT pada seluruh class pada program Characters Graphic 16

84 Pada paper berjudul Applying and Interpreting Object Oriented Metrics yang ditulis oleh Dr. Linda H. Rosenberg disajikan aplikasi dan interpretasi dari metric DIT dengan menggunakan NASA project data sebagai berikut: Pada gambar grafik diatas, kita melihat bahwa Hampir 66% (DIT>0) dari class project ini berada di bawah class lainnya di dalam tree, yang mengindikasikan berada dalam level sedang dari reuse. Metric software: Number of Children (NOC) NOC merupakan jumlah subclass yang diturunkan langsung dari suatu class. Semakin tinggi nilai NOC menyebabkan semakin besar reuseability karena inheritance adalah bentuk dari reuse. Semakin besar NOC juga dapat menyebabkan proses pengujian semakin banyak karena apabila terjadi perubahan di suatu class dapat mempengaruhi class yang menjadi subclass dari class tersebut. Berikut contoh perhitungan NOC pada program Characters Graphic: 17

85 Berikut hasil pengukuran metrik NOC pada seluruh class pada program Characters Graphic Pada paper berjudul Applying and Interpreting Object Oriented Metrics yang ditulis oleh Dr. Linda H. Rosenberg disajikan aplikasi dan interpretasi dari metric DIT dan NOC dengan menggunakan NASA project data sebagai berikut: 18

86 Gambar grafik diatas menampilkan bagaimana dua cara pandang dari indentifikasi data pada class yang diamati. DIT yang tinggi mengindikasikan trade-off diantara meningkatnya kompleksitas dan meningkatnya reuse, tetapi perlu dilakukan lebih banyak testing pada sistem. NOC yang tinggi juga mengindikasikan peningkatan reuse, tetapi kemungkinan memerlukan lebih banyak testing pada sistem. 19

87 MODUL PERKULIAHAN Testing dan Implementasi SI Modul Standar untuk digunakan dalam Perkuliahan di Universitas Mercu Buana Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh Fasilkom Program Tim Dosen Studi Sistem 11 Informasi Abstract Kompetensi Impelementasi Sistem Impelementasi Sistem 1

88 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 2

89 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 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 b. Komponen Rancangan Sistem: Output Output harus sesuai, relevan, akurat dan dapat digunakan kembali Kemanan pengguna output bagi user yg tidak berhak Kemudahan akses 3

90 Input Sesuai dengan kognitif user Ketepatan edit dan identifikasi laporan 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) 4

91 5

92 MODUL PERKULIAHAN Testing dan Implementasi SI Modul Standar untuk digunakan dalam Perkuliahan di Universitas Mercu Buana Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh Fasilkom Program Tim Dosen Studi Sistem 12 Informasi Abstract Dokumentasi Perangkat Lunak Kompetensi Memahami Dokumentasi Perangkat Lunak 1

93 2

94 Dokumentasi yang ada di Departemen Sistem Informasi (Departemen Operasi) diantaranya adalah : 1. Dokumentasi Dokumen Dasar Merupakan dokumentasi yang berisi kumpulan dokumen- dokumen dasar sebagai bukti transaksi yang digunakan dalam sistem. Contoh :Faktur penjualan, Order penjualan, order pembelian, surat pengiriman barang, time-card. 2. Dokumentasi Daftar Rekening (chart of account) Merupakan dokumentasi yang menunjukkan informasi mengenai rekening-rekening yang dipergunakan di dalam transaksi. Daftar rekening berisi daftar dari kode rekening, nama rekening, klasifikasinya (aktiva, utang, modal, pendapatan-pendapatan, dan biaya-biaya), serta petunjuk dari masing-masing rekening bagaimana rekening tersebut dipergunakan. 3. Dokumentasi Prosedur Manual Merupakan dokumentasi yang menunjukkan arus dari dokumen-dokumen dasar di dalam perusahaan. Dokumentasi ini menyedia-kan informasi mengenai bagian mana yang menyiapkan dokumen dasar, jumlah tembusannya, bagian-bagian mana saja yang mengarsipkannya dan kepada bagian mana saja dokumen dasar tersebut harus dikirimkan 4. Dokumentasi Prosedur Dokumentasi prosedur dapat berisi prosedur-prosedur yang harus dilakukan pada suatu keadaan tertentu, seperti misalnya prosedur pengetesan program, prosedur penggunaan file, prosedur pembuatan back-up dan restore, dsb. 5. Dokumentasi Sistem Dokumentasi sistem menunjukkan bentuk dari sistem informasi yang digambarkan dalam bagan alir sistem (system flowchart). Pada dokumentasi ini dapat terlihat deskripsi dari input yang digunakan, deskripsi output yang digunakan, deskripsi output yang dihasilkan, deskripsi file-file yang digunakan, berita-berita kesalahan pengolahan dan daftar-daftar pengendalian untuk tiaptiap sistem pengolahan. Dokumentasi sistem merupakan dokumen yang dibutuhkan oleh sistem analis, pemakai sistem, dan auditor. 6. Dokumentasi Program Dokumentasi program menggambarkan logika dari program dalam bentuk bagan alir program (program flowchart), tabel keputusan (decision table) dan bentuk pengendalian program. Dokumentasi program sangat dibutuhkan oleh programmer bila akan memodifikasi atau mengembangkan program. 7. Dokumentasi Operasi Dokumentasi operasi berisi penjelasan-penjelasan cara dan prosedur-prosedur mengoperasikan program. Dokumentasi ini sangat berguna untuk operator. 3

95 8. Dokumentasi DataDokumentasi data berisi definisi-definisi dari item-item data di dalam database yang digunakan oleh sistem informasi. Yang paling banyak membutuhkan dokumentasi ini adalah data base administrator (DBA) dan auditor Sedangkan tujuan dokumentasi adalah : 1. Arus komunikasi Komunikasi terjadi dalam tiga arah : - Ke bawah untuk melakukan instruksi - Ke atas untuk memberi laporan - Ke samping (Lateral) untuk memberi saran 2. Untuk memberi informasi Penting kiranya untuk terus menerus memberi informasi kepada orang tentang apa yang telah, sedang, dan akan dilakukan, serta segala perubahan dalam pekerjaan yang telah ditetapkan. 3. Untuk mengidentifikasi Beberapa dokumentasi dirancang untuk mengidentifikasi. 4. Untuk menetapkan prosedur dan standar Prosedur menentukan rangkaian kegiatan yang akan dilaksanakan, sedangkan Standar menentukan aturan yang akan dianut dalam menjalankan prosedur tersebut. 5. Untuk mencatat Dokumentasi akan diperlukan unutuk memonitor kinerja peralatan, sistem, dan sumber daya manusia. Dari dokumentasi ini, manajemen dapat memutuskan atau menilai apakah departemen tersebut memenuhi atau mencapai tujuannya dalam skala waktu dan batasan sumber dayanya. Selain itu manajemen dapat mengukur kualitas pekerjaan, yaitu apakah outputnya sesuai dengan spesifikasi dan standar yang telah ditetapkan. 6. Untuk memberi instruksi Dokumentasi yang baik akan membantu dalam pelatihan staf, apakah pelatihan untuk tujuan penanganan instalasi baru atau untuk tujuan promosi. Prinsip Dokumentasi : 1. Metode Komunikasi yang baik tidak terjadi begitu saja. Manajer Operasi harus menetapkan dan memelihara saluran komunikasi dan menetapkan kontrol guna memastikan bahwa saluran komunikasi tersebut terbuka dan dapat digunakan. Manajer Operasi harus memberi perhatian khusus pada : - Siapa yang bertanggung jawab atas perpustakaan? - Siapa yang membuat atau menghasilkan dokumentasi - Kapan dokumentasi tersebut harus dibuat? - Sirkulasi - Pemeliharaan 4

96 - Aksesibilitas 2. Jumlah dokumentasi Manajer Operasi harus mencoba untuk mengarsip dokumentasi agar dapat mencapai keseimbangan antara jumlah yang terlalu banyak dan terlalu sedikit. 3. Kesederhanaan Dokumentasi harus bersifat sederhana dan langsung, sehingga ia dapat dilengkapi secara mudah dan dapat dipahami secara langsung. Hal ini dapat merangsang munculnya partisipasi dan meningkatkan keakuratan. Informasi yang tidak akurat, tidak hanya tidak andal namun juga menyesatkan. 4. Desain Form Perlu dirancang sejumlah form untuk digunakan menurut kepentingan atau kegunaan kita sendiri. Dalam merancang sebuah form untuk dokumentasi perlu dipertimbangkan hal-hal berikut ini : - Typeface (huruf ketikkannya) - Tata letak - Warna - Referensi - Identifikasi 5

97 MODUL PERKULIAHAN Testing dan Implementasi SI Modul Standar untuk digunakan dalam Perkuliahan di Universitas Mercu Buana Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh Fasilkom Program Tim Dosen Studi Sistem 13 Informasi Abstract Pemliharaan Sistem dalam SDLC Kompetensi Memahami Pemeliharaan Sistem dalam SDLC 1

98 2

99 PEMELIHARAAN SISTEM Definisi Pemeliharaan Sistem Pemeliharaan Sistem adalah suatu kombinasi dari berbagai tindakan yang dilakukan untuk menjaga suatu sistem dalam, atau memperbaikinya sampai, suatu kondisi yang bisa diterima. Pada bulan April 1970 didefinisikan sebuah istilah untuk Teknologi Pemeliharaan yang mencakup pengertian yang lebih luas dari pada pengertian Pemeliharaan diatas. Istilah ini adalah Teroteknologi. Sistem perlu dipelihara karena beberapa hal, yaitu : 1. Sistem memiliki kesalahan yang dulunya belum terdeteksi, sehingga kesalahan-kesalahan sistem perlu diperbaiki. 2. Sistem mengalami perubahan-perubahan karena permintaan baru dari pemakai sistem. 3. Sistem mengalami perubahan karena perubahan lingkungan luar (perubahan bisnis). 4. Sistem terinfeksi malware aktif 5. Sistem berkas corrupt 6. Perangkat keras melemah Untuk mencegah hal-hal tesebut, digunakanlah mos(maintenance Operating system) yang berfungsi untuk: -Manajemen Malware yang aktif -Pemulihan data (recovery) dan perbaikan sistem berkas -Diagnosa perangkat keras. mos tidak menulis ke disk atau menjalankan kode apapun dari disk, memiliki akses langsung ke perangkat keras, dan hanya membutuhkan sedikit bagian dari perangkat keras untuk bekerja dengan sempurna. Selain dengan mos, kita juga dapat memelihara sistem (pada windows) dengan cara-cara yang sederhana seperti: -Jangan pernah mematikan power sampai sistem benar-benar sudah shutdown. -Buatlah backup data-data yang penting. -Lakukan defragment setidaknya satu bulan sekali -Sisakan sedikitspace kosong di partisi tempat sistem operasi berada -Gunakan firewall jika anda terkoneksi dengan jaringan. -Lakukan pengecekan virus secara rutin. Selain dengan menggunakan mos pemeliharaan sistem juga dapat dilakukan dengan cara : 3

100 Pemeliharaan Korektif Pemeliharaan korektif adalah bagian pemeliharaan sistem yang tidak begitu tinggi nilainya dan lebih membebani, karena pemeliharaan ini mengkoreksi kesalahan-kesalahan yang ditemukan pada saat sistem berjalan. Umumnya pemeliharaan korektif ini mencakup kondisi penting atau bahaya yang memerlukan tindakan segera. Kemampuan untuk mendiagnosa atau memperbaiki kesalahan atau malfungsi dengan cepat sangatlah berharga bagi perusahaan. Pemeliharaan Adaptif Pemeliharaan adaptif dilakukan untuk menyesuaikan perubahan dalam lingkungan data atau pemrosesan dan memenuhi persyaratan pemakai baru. Lingkungan tempat sistem beroperasi adalah dinamik, dengan demikian, sistem harus terus merespon perubahan persyaratan pemakai. Misalnya, Undang-Undang Perpajakan yang baru mungkin memerlukan suatu perubahan dalam kalkulasi pembayaran bersih. Umumnya pemeliharaan adatif ini baik dan tidak dapat dihindari. Pemeliharaan Perfektif (Penyempurnaan) Pemeliharaan penyempurnaan mempertinggi cara kerja atau maintainabilitas (kemampuan untuk dipelihara). Tindakan ini juga memungkinkan sistem untuk memenuhi persyaratan pemakai yang sebelumnya tidak dikenal. Ketika membuat perubahan substansial modul apapun, petugas pemeliharaan juga menggunakan kesempatan untuk meng-upgrade kode, mengganti cabangcabang yang kadaluwarsa, memperbaiki kecerobohan, dan mengembangkan dokumentasi. Sebagai contoh, kegiatan pemeliharaan ini dapat berbentuk perekayasaan ulang atau restrukturisasi perangkat lunak, penulisan ulang dokumentasi, pengubahan format dan isi laporan, penentuan logika pemrosesan yang lebih efisien, dan pengembangan efisiensi pengoperasian perangkat. Pemeliharaan Preventif Pemeliharaan Preventif terdiri atas inspeksi periodik dan pemeriksaan sistem untuk mengungkap dan mengantisipasi permasalahan. Karena personil pemeliharaan sistem bekerja dalam sistem ini, mereka seringkali menemukan cacat-cacat (bukan kesalahan yang sebenarnya) yang menandakan permasalahan potensial. Sementara tidak memerlukan tindakan segera, cacat ini bila tidak dikoreksi di tingkat awal, jelas sekali akan mempengaruhi baik fungsi sistem maupun kemampuan untuk memeliharanya dalam waktu dekat. Memelihara Perangkat Lunak Perangkat lunak aplikasi mungkin terstruktur mungkin pula tidak, atau mungkin didokumentasikan mungkin pula tidak. Beberapa perangkat lunak yang tidak terstruktur dan tidak didokumentasikan mungkin hampir tidak dapat dipelihara. Sebenarnya salah satu sebab utama mengapa pemeliharaan sistem memerlukan anggaran sistem yang amat banyak adalah 4

101 karena kenaikan tenaga yang dibutuhkan untuk mencoba memelihara perangkat lunak yang didokumentasikan serta distruktur secara acak-acakan. Di lain pihak program perangkat lunak yang tidak terstruktur dan tidak terdokumentasi juga tidak dapat dipelihara. Seandainya suatu perubahan dalam operasi memaksa program itu untuk berubah, maka program itu harus disingkirkan dan dikembangkanlah program baru. Sehinga menyia-nyiakan semua sumber yang dikeluarkan untuk membangun program asli yang tidak dapat dipelihara tersebut, belum lagi kerugian operasi bisnis bila hari yang ditentukan tiba. Memelihara Perangkat Keras Pemeliharaan perangkat keras terutama pemeliharaan preventif yang memerlukan reparasi, penggantian, atau penambahan suku cadang dan komponen untuk merestorasi atau menjaga agar perangkat keras tetap bekerja dengan baik. Komponen perangkat keras sistem informasi sebaiknya dicek dan diservis secara periodik Siklus Hidup Pemeliharaan Sistem (SMLC) -Permintaan Perubahan -Mengubah permohonan pemeliharaan menjadi suatu perubahan -Menspesifikasi perubahan Membangun pengganti -Menguji pengganti -Melatih pengguna dan melakukan tes penerimaan -Pengkonversian dan pelepasan ke operasi -Mengupdate dokumentasi -Melakukan pemeriksaan pascaimplementasi Mengatur Pemeliharaan Sistem -Menetapkan kegiatan pemeliharaan -Mengawali dan merekam kegiatan pemeliharaan sistem tidak terjadwal -HELP DESK -Mengevaluasi aktivitas pemeliharaan sistem Tahapan-Tahapan Siklus Hidup Pemeliharaan Sistem (SMLC) Tahap pemeliharaan dilakukan setelah tahap implementasi. Sistem baru yang berjalan digunakan sesuai dengan keperluan organisasi. Selama masa hidupnya, sistem secara periodik akan ditinjau. Perubahan dilakukan jika muncul masalah atau jika ternyata ada kebutuhan baru. Selanjutnya, organisasi akan menggunakan sistem yang telah diperbaiki tersebut. 5

102 Pemeliharaan sistem dilaksanakan untuk 3 alasan: 1. Memperbaiki kesalahan 2. Menjaga kemutakhiran sistem 3. Meningkatkan sistem 4. Menyiapkan usulan rekayasa ulang 5. Menyetujui atau menolak rekayasa ulang sistem Merupakan siklus terakhir dari SDLC Pemeriksaan periodik, audit dan permintaan pengguna akan menjadi source untuk melakukan perawatan sistem diseluruh masa hidup sistem. Jenis Pemeliharaan : 1.Pemeliharaan Korektif 2.Pemeliharaan Adaptif 3.Pemeliharaan Perfektif 4.Pemeliharaan Preventif Siklus Hidup Pemeliharaan Sistem (SDLC) : 1.Permintaan Perubahan 2.Mengubah permohonan pemeliharaan menjadi suatu perubahan 3.Menspesifikasi perubahan 4.Membangun pengganti 5.Menguji pengganti 6.Melatih pengguna dan melakukan tes penerimaan Siklus Hidup Pemeliharaan Sistem (SDLC) : 1.Pengkonversian dan pelepasan ke operasi 2.Mengupdate dokumentasi 3.Melakukan pemeriksaan pascaimplementasi Prosedur Pemeliharaan Sistem : 1.SDLC dan SWDLC 2.Definisi data standar 3.Bahasa pemrograman standar 4.Rancangan Moduler 5.Model yang dapat digunakan kembali 6.Dokumentasi standar 7.Kontrol sentral 6

103 Tahapan-Tahapan Siklus Hidup Pemeliharaan Sistem (SMLC) a. Memahami Permintaan Pemeliharaan b. Mentransformasi Permintaan Pemeliharaan Menjadi Pengubahan c. Menspesifikasi Perubahan d. Mengembangkan Perubahan e. Menguji Perubahan f. Melatih Pengguna dan Melakukan Test Penerimaan g. Pengkonversian dan Meluncurkan Operasi h. Mengupdate Dokumen i. Melakukan Pemeriksaan Pasca Implementasi Case Tools Untuk memelihara Sistem : 1.Forward engineering 2.Reverse Engineering 3.Reengineering 4.Restrukturing 5.Maintenance Expert Systems Mengatur Pemeliharaan Sistem : 1.Menetapkan kegiatan pemeliharaan 2.Mengawali dan merekam kegiatan pemeliharaan sistem tidak terjadwal HELP DESK 3.Mengevaluasi aktivitas pemeliharaan sistem Langkah-langkah pemeliharaan sistem terdiri atas: 1. Penggunaan Sistem Yaitu menggunakan sistem sesuai dengan fungsi tugasnya masing-masing untuk operasi rutin atau sehari-hari. 7

104 2. Audit Sistem Yaitu melakukan penggunaan dan penelitian formal untuk menentukan seberapa baik sistem baru dapat memenuhi kriteria kinerja. Hal semacam ini disebut penelaahan setelah penerapan dan dapat dilakukan oleh seorang auditor internal. 3. Penjagaan Sistem Yaitu melakukan pemantauan untuk pemeriksaan rutin sehingga sistem tetap beroperasi dengan baik. Selain itu juga untuk menjaga kemutakhiran sistem jika sewaktu-waktu terjadi perubahan lingkungan sistem atau modifikasi rancangan software. 4. Perbaikan Sistem Yaitu melakukan perbaikan jika dalam operasi terjadi kesalahan (bugs) dalam program atau kelemahan rancangan yang tidak terdeteksi saat tahap pengujian sistem. 5. Peningkatan Sistem Yaitu melakukan modifikasi terhadap sistem ketika terdapat potensi peningkatan sistem setelah sistem berjalan beberapa waktu, biasanya adanya potensi peningkatan sistem tersebut terlihat oleh manajer kemudian diteruskan kepada spesialis informasi untuk dilakukan modifikasi sesuai keinginan manajer. Jenis-Jenis Pemeliharaan : Pemeliharaan Korektif Pemeliharaan Adaptif Pemeliharaan Perfektif Pemeliharaan Preventif Siklus Hidup Pemeliharaan Sistem (SMLC): Pengkonversian dan pelepasan ke operasi Mengupdate dokumentasi Melakukan pemeriksaan pascaimplementasi Prosedur Pemeliharaan sistem : SDLC dan SWDLC Definisi data standar Bahasa pemrograman standar Rancangan Moduler Model yang dapat digunakan kembali Dokumentasi standar Kontrol sentral Case Tools Untuk memelihara Sistem : Forward engineering Reverse Engineering Reengineering Restrukturing Maintenance Expert Systems 8

105 Mengatur Pemeliharaan sistem : Menetapkan kegiatan pemeliharaan Mengawali dan merekam kegiatan pemeliharaan sistem tidak terjadwal HELP DESK Mengevaluasi aktivitas pemeliharaan system Alat-Alat Pemliharaan Sistem Hardware Yang dibutuhkan sesuai dengan kebutuhan system Software yang di butuhkan sesuai dengan kebutuhan system Mengatur Pemeliharaan sitem Tentukan jadwal maintenance pada system yang kita miliki Update software yang compatible terhadap system kita Gunakan tenaga ahli yang terpercaya untuk Mengembangkan Perubahan Sistem manajemen Salah satu konsep yang dibahas,, dan dianalisis paling sering dalam beberapa tahun terakhir telah terjadi perubahan organisasi dan konsep terkait resistensi terhadap perubahan dan manajemen perubahan. Perubahan telah banyak didefinisikan sebagai membuat perbedaan materi dalam sesuatu dibandingkan dengan keadaan sebelumnya, atau mengubah sesuatu, atau hanya menjadi berbeda. Semua definisi ini dapat diterapkan untuk mengubah seperti itu terjadi dalam organisasi dan bisnis. Perubahan organisasi bisa berarti perubahan teknologi infrastruktur (misalnya, bergerak dari lingkungan mainframe untuk komputasi terdistribusi), strategi pemasaran (target basis pelanggan baru), atau manajemen dan praktek pengambilan keputusan. Perubahan organisasi bukanlah hal baru dengan lanskap bisnis Amerika. Sejak abad kesembilan belas dan Revolusi Industri, perusahaan harus berurusan dengan perubahan dalam skala yang semakin cepat. Semakin besar perkembangan teknologi dan semakin besar jumlah produk dan informasi yang dihasilkan, semakin diperlukan menjadi bagi perusahaan untuk memberikan manajemen yang efektif dan mengembangkan praktek organisasi yang solid Para profesional bisnis yang paling dihormati di Amerika Serikat telah orang-orang yang paling mampu memanfaatkan perubahan dalam bisnis dan perekonomian. Sebagai contoh, pada akhir abad kesembilan belas, Andrew Carnegie sangat memperluas kerajaannya dengan membeli usaha yang sangat ia bergantung pada untuk bisnis baja-nya, membuat satu perusahaannya contoh sukses pertama dari integrasi vertikal. Dimulai pada 1990-an, perubahan datang pada tingkat yang secara eksponensial lebih cepat karena faktor-faktor seperti persaingan yang meningkat dalam ekonomi global, memperluas pasar, cara-cara baru melakukan bisnis (seperti e-commerce), dan tugas di mana-mana menjaga dengan yang terbaru teknologi. Guru manajemen Peter F. Drucker mengabdikan bukunya Manajemen Tantangan dari 21 abad ke topik yang sangat. Akibatnya, perusahaan harus merevisi (atau menyusun) misi perusahaan dan tujuan, praktek manajemen, dan fungsi bisnis sehari-hari. Perusahaan secara rutin mulai merancang ulang strategi bisnis, sering menggantikan bagan 9

106 organisasi tradisional hirarki dengan struktur datar berpusat di sekitar diberdayakan tim. Tujuan utama bagi kebanyakan organisasi adalah untuk perubahan iklim dan budaya perusahaan. iklim Suatu organisasi dapat didefinisikan oleh bagaimana karyawan melihat alasan mendasar organisasi. karena, khususnya, misi perusahaan secara keseluruhan dan tujuan dan bagaimana pentingnya pengertian karyawan kesejahteraan adalah tujuan-tujuan tersebut. Iklim perusahaan kemudian melahirkan budaya organisasi yang terdiri dari apa karyawan lihat sebagai kepercayaan manajemen dan sistem nilai. Kedua hal, iklim dan budaya, kemudian menentukan bagaimana setiap manajer dan karyawan bentuk kinerja nya sendiri, biasanya dalam rangka paling berhasil mencapai tujuan perusahaan dan mudah-mudahan memastikan keberhasilan sendiri serta perusahaan. Faktor-faktor ini mempengaruhi setiap aspek dari pekerjaan setiap orang, termasuk proses pengambilan keputusan, pola komunikasi dalam organisasi, dan tanggung jawab individu dan tanggung jawab perusahaan. INDIKATOR PERUBAHAN Ada empat indikator utama dari perubahan pekerjaan-tempat utama.. Mereka adalah perubahan struktur organisasi, produk atau jasa baru, manajemen baru, dan teknologi baru. Struktur Organisasi bisa berubah melalui perampingan besar, outsourcing, akuisisi, atau merger. Tindakan ini sering disertai dengan PHK, khususnya sebagai posisi tertentu menjadi berlebihan.. Sebuah produk atau jasa baru memiliki implikasi untuk perubahan dalam produksi, penjualan, dan layanan pelanggan.. Selain itu, dengan mengubah produk atau jasa organisasi mungkin menghadapi pesaing baru atau pasar baru.. manajemen baru, seperti perubahan dalam CEO atau presiden, sering membawa masa transisi di mana para manajer tingkat atas cenderung untuk mengubah proses bisnis yang ada dan kebijakan personil. Akhirnya, teknologi baru dapat membuat perubahan besar bagi organisasi. Teknologi dapat mengubah proses produksi atau kondisi kerja (yaitu, telecommuting), dan perubahan ini mungkin mempengaruhi keterampilan yang karyawan menggunakan pada pekerjaan. 10

107 MODUL PERKULIAHAN Testing dan Implementasi SI Modul Standar untuk digunakan dalam Perkuliahan di Universitas Mercu Buana Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh Fasilkom Program Tim Dosen Studi Sistem 13 Informasi Abstract Pemliharaan Sistem dalam SDLC Kompetensi Memahami Pemeliharaan Sistem dalam SDLC 1

108 2

109 PEMELIHARAAN SISTEM Definisi Pemeliharaan Sistem Pemeliharaan Sistem adalah suatu kombinasi dari berbagai tindakan yang dilakukan untuk menjaga suatu sistem dalam, atau memperbaikinya sampai, suatu kondisi yang bisa diterima. Pada bulan April 1970 didefinisikan sebuah istilah untuk Teknologi Pemeliharaan yang mencakup pengertian yang lebih luas dari pada pengertian Pemeliharaan diatas. Istilah ini adalah Teroteknologi. Sistem perlu dipelihara karena beberapa hal, yaitu : 7. Sistem memiliki kesalahan yang dulunya belum terdeteksi, sehingga kesalahan-kesalahan sistem perlu diperbaiki. 8. Sistem mengalami perubahan-perubahan karena permintaan baru dari pemakai sistem. 9. Sistem mengalami perubahan karena perubahan lingkungan luar (perubahan bisnis). 10. Sistem terinfeksi malware aktif 11. Sistem berkas corrupt 12. Perangkat keras melemah Untuk mencegah hal-hal tesebut, digunakanlah mos(maintenance Operating system) yang berfungsi untuk: -Manajemen Malware yang aktif -Pemulihan data (recovery) dan perbaikan sistem berkas -Diagnosa perangkat keras. mos tidak menulis ke disk atau menjalankan kode apapun dari disk, memiliki akses langsung ke perangkat keras, dan hanya membutuhkan sedikit bagian dari perangkat keras untuk bekerja dengan sempurna. Selain dengan mos, kita juga dapat memelihara sistem (pada windows) dengan cara-cara yang sederhana seperti: -Jangan pernah mematikan power sampai sistem benar-benar sudah shutdown. -Buatlah backup data-data yang penting. -Lakukan defragment setidaknya satu bulan sekali -Sisakan sedikitspace kosong di partisi tempat sistem operasi berada -Gunakan firewall jika anda terkoneksi dengan jaringan. -Lakukan pengecekan virus secara rutin. Selain dengan menggunakan mos pemeliharaan sistem juga dapat dilakukan dengan cara : 3

110 Pemeliharaan Korektif Pemeliharaan korektif adalah bagian pemeliharaan sistem yang tidak begitu tinggi nilainya dan lebih membebani, karena pemeliharaan ini mengkoreksi kesalahan-kesalahan yang ditemukan pada saat sistem berjalan. Umumnya pemeliharaan korektif ini mencakup kondisi penting atau bahaya yang memerlukan tindakan segera. Kemampuan untuk mendiagnosa atau memperbaiki kesalahan atau malfungsi dengan cepat sangatlah berharga bagi perusahaan. Pemeliharaan Adaptif Pemeliharaan adaptif dilakukan untuk menyesuaikan perubahan dalam lingkungan data atau pemrosesan dan memenuhi persyaratan pemakai baru. Lingkungan tempat sistem beroperasi adalah dinamik, dengan demikian, sistem harus terus merespon perubahan persyaratan pemakai. Misalnya, Undang-Undang Perpajakan yang baru mungkin memerlukan suatu perubahan dalam kalkulasi pembayaran bersih. Umumnya pemeliharaan adatif ini baik dan tidak dapat dihindari. Pemeliharaan Perfektif (Penyempurnaan) Pemeliharaan penyempurnaan mempertinggi cara kerja atau maintainabilitas (kemampuan untuk dipelihara). Tindakan ini juga memungkinkan sistem untuk memenuhi persyaratan pemakai yang sebelumnya tidak dikenal. Ketika membuat perubahan substansial modul apapun, petugas pemeliharaan juga menggunakan kesempatan untuk meng-upgrade kode, mengganti cabangcabang yang kadaluwarsa, memperbaiki kecerobohan, dan mengembangkan dokumentasi. Sebagai contoh, kegiatan pemeliharaan ini dapat berbentuk perekayasaan ulang atau restrukturisasi perangkat lunak, penulisan ulang dokumentasi, pengubahan format dan isi laporan, penentuan logika pemrosesan yang lebih efisien, dan pengembangan efisiensi pengoperasian perangkat. Pemeliharaan Preventif Pemeliharaan Preventif terdiri atas inspeksi periodik dan pemeriksaan sistem untuk mengungkap dan mengantisipasi permasalahan. Karena personil pemeliharaan sistem bekerja dalam sistem ini, mereka seringkali menemukan cacat-cacat (bukan kesalahan yang sebenarnya) yang menandakan permasalahan potensial. Sementara tidak memerlukan tindakan segera, cacat ini bila tidak dikoreksi di tingkat awal, jelas sekali akan mempengaruhi baik fungsi sistem maupun kemampuan untuk memeliharanya dalam waktu dekat. Memelihara Perangkat Lunak Perangkat lunak aplikasi mungkin terstruktur mungkin pula tidak, atau mungkin didokumentasikan mungkin pula tidak. Beberapa perangkat lunak yang tidak terstruktur dan tidak didokumentasikan mungkin hampir tidak dapat dipelihara. Sebenarnya salah satu sebab utama mengapa pemeliharaan sistem memerlukan anggaran sistem yang amat banyak adalah 4

111 karena kenaikan tenaga yang dibutuhkan untuk mencoba memelihara perangkat lunak yang didokumentasikan serta distruktur secara acak-acakan. Di lain pihak program perangkat lunak yang tidak terstruktur dan tidak terdokumentasi juga tidak dapat dipelihara. Seandainya suatu perubahan dalam operasi memaksa program itu untuk berubah, maka program itu harus disingkirkan dan dikembangkanlah program baru. Sehinga menyia-nyiakan semua sumber yang dikeluarkan untuk membangun program asli yang tidak dapat dipelihara tersebut, belum lagi kerugian operasi bisnis bila hari yang ditentukan tiba. Memelihara Perangkat Keras Pemeliharaan perangkat keras terutama pemeliharaan preventif yang memerlukan reparasi, penggantian, atau penambahan suku cadang dan komponen untuk merestorasi atau menjaga agar perangkat keras tetap bekerja dengan baik. Komponen perangkat keras sistem informasi sebaiknya dicek dan diservis secara periodik Siklus Hidup Pemeliharaan Sistem (SMLC) -Permintaan Perubahan -Mengubah permohonan pemeliharaan menjadi suatu perubahan -Menspesifikasi perubahan Membangun pengganti -Menguji pengganti -Melatih pengguna dan melakukan tes penerimaan -Pengkonversian dan pelepasan ke operasi -Mengupdate dokumentasi -Melakukan pemeriksaan pascaimplementasi Mengatur Pemeliharaan Sistem -Menetapkan kegiatan pemeliharaan -Mengawali dan merekam kegiatan pemeliharaan sistem tidak terjadwal -HELP DESK -Mengevaluasi aktivitas pemeliharaan sistem Tahapan-Tahapan Siklus Hidup Pemeliharaan Sistem (SMLC) Tahap pemeliharaan dilakukan setelah tahap implementasi. Sistem baru yang berjalan digunakan sesuai dengan keperluan organisasi. Selama masa hidupnya, sistem secara periodik akan ditinjau. Perubahan dilakukan jika muncul masalah atau jika ternyata ada kebutuhan baru. Selanjutnya, organisasi akan menggunakan sistem yang telah diperbaiki tersebut. 5

112 Pemeliharaan sistem dilaksanakan untuk 3 alasan: 1. Memperbaiki kesalahan 2. Menjaga kemutakhiran sistem 3. Meningkatkan sistem 4. Menyiapkan usulan rekayasa ulang 5. Menyetujui atau menolak rekayasa ulang sistem Merupakan siklus terakhir dari SDLC Pemeriksaan periodik, audit dan permintaan pengguna akan menjadi source untuk melakukan perawatan sistem diseluruh masa hidup sistem. Jenis Pemeliharaan : 1.Pemeliharaan Korektif 2.Pemeliharaan Adaptif 3.Pemeliharaan Perfektif 4.Pemeliharaan Preventif Siklus Hidup Pemeliharaan Sistem (SDLC) : 1.Permintaan Perubahan 2.Mengubah permohonan pemeliharaan menjadi suatu perubahan 3.Menspesifikasi perubahan 4.Membangun pengganti 5.Menguji pengganti 6.Melatih pengguna dan melakukan tes penerimaan Siklus Hidup Pemeliharaan Sistem (SDLC) : 1.Pengkonversian dan pelepasan ke operasi 2.Mengupdate dokumentasi 3.Melakukan pemeriksaan pascaimplementasi Prosedur Pemeliharaan Sistem : 1.SDLC dan SWDLC 2.Definisi data standar 3.Bahasa pemrograman standar 4.Rancangan Moduler 5.Model yang dapat digunakan kembali 6.Dokumentasi standar 7.Kontrol sentral 6

113 Tahapan-Tahapan Siklus Hidup Pemeliharaan Sistem (SMLC) a. Memahami Permintaan Pemeliharaan b. Mentransformasi Permintaan Pemeliharaan Menjadi Pengubahan c. Menspesifikasi Perubahan d. Mengembangkan Perubahan e. Menguji Perubahan f. Melatih Pengguna dan Melakukan Test Penerimaan g. Pengkonversian dan Meluncurkan Operasi h. Mengupdate Dokumen i. Melakukan Pemeriksaan Pasca Implementasi Case Tools Untuk memelihara Sistem : 1.Forward engineering 2.Reverse Engineering 3.Reengineering 4.Restrukturing 5.Maintenance Expert Systems Mengatur Pemeliharaan Sistem : 1.Menetapkan kegiatan pemeliharaan 2.Mengawali dan merekam kegiatan pemeliharaan sistem tidak terjadwal HELP DESK 3.Mengevaluasi aktivitas pemeliharaan sistem Langkah-langkah pemeliharaan sistem terdiri atas: 1. Penggunaan Sistem Yaitu menggunakan sistem sesuai dengan fungsi tugasnya masing-masing untuk operasi rutin atau sehari-hari. 7

114 2. Audit Sistem Yaitu melakukan penggunaan dan penelitian formal untuk menentukan seberapa baik sistem baru dapat memenuhi kriteria kinerja. Hal semacam ini disebut penelaahan setelah penerapan dan dapat dilakukan oleh seorang auditor internal. 3. Penjagaan Sistem Yaitu melakukan pemantauan untuk pemeriksaan rutin sehingga sistem tetap beroperasi dengan baik. Selain itu juga untuk menjaga kemutakhiran sistem jika sewaktu-waktu terjadi perubahan lingkungan sistem atau modifikasi rancangan software. 4. Perbaikan Sistem Yaitu melakukan perbaikan jika dalam operasi terjadi kesalahan (bugs) dalam program atau kelemahan rancangan yang tidak terdeteksi saat tahap pengujian sistem. 5. Peningkatan Sistem Yaitu melakukan modifikasi terhadap sistem ketika terdapat potensi peningkatan sistem setelah sistem berjalan beberapa waktu, biasanya adanya potensi peningkatan sistem tersebut terlihat oleh manajer kemudian diteruskan kepada spesialis informasi untuk dilakukan modifikasi sesuai keinginan manajer. Jenis-Jenis Pemeliharaan : Pemeliharaan Korektif Pemeliharaan Adaptif Pemeliharaan Perfektif Pemeliharaan Preventif Siklus Hidup Pemeliharaan Sistem (SMLC): Pengkonversian dan pelepasan ke operasi Mengupdate dokumentasi Melakukan pemeriksaan pascaimplementasi Prosedur Pemeliharaan sistem : SDLC dan SWDLC Definisi data standar Bahasa pemrograman standar Rancangan Moduler Model yang dapat digunakan kembali Dokumentasi standar Kontrol sentral Case Tools Untuk memelihara Sistem : Forward engineering Reverse Engineering Reengineering Restrukturing Maintenance Expert Systems 8

115 Mengatur Pemeliharaan sistem : Menetapkan kegiatan pemeliharaan Mengawali dan merekam kegiatan pemeliharaan sistem tidak terjadwal HELP DESK Mengevaluasi aktivitas pemeliharaan system Alat-Alat Pemliharaan Sistem Hardware Yang dibutuhkan sesuai dengan kebutuhan system Software yang di butuhkan sesuai dengan kebutuhan system Mengatur Pemeliharaan sitem Tentukan jadwal maintenance pada system yang kita miliki Update software yang compatible terhadap system kita Gunakan tenaga ahli yang terpercaya untuk Mengembangkan Perubahan Sistem manajemen Salah satu konsep yang dibahas,, dan dianalisis paling sering dalam beberapa tahun terakhir telah terjadi perubahan organisasi dan konsep terkait resistensi terhadap perubahan dan manajemen perubahan. Perubahan telah banyak didefinisikan sebagai membuat perbedaan materi dalam sesuatu dibandingkan dengan keadaan sebelumnya, atau mengubah sesuatu, atau hanya menjadi berbeda. Semua definisi ini dapat diterapkan untuk mengubah seperti itu terjadi dalam organisasi dan bisnis. Perubahan organisasi bisa berarti perubahan teknologi infrastruktur (misalnya, bergerak dari lingkungan mainframe untuk komputasi terdistribusi), strategi pemasaran (target basis pelanggan baru), atau manajemen dan praktek pengambilan keputusan. Perubahan organisasi bukanlah hal baru dengan lanskap bisnis Amerika. Sejak abad kesembilan belas dan Revolusi Industri, perusahaan harus berurusan dengan perubahan dalam skala yang semakin cepat. Semakin besar perkembangan teknologi dan semakin besar jumlah produk dan informasi yang dihasilkan, semakin diperlukan menjadi bagi perusahaan untuk memberikan manajemen yang efektif dan mengembangkan praktek organisasi yang solid Para profesional bisnis yang paling dihormati di Amerika Serikat telah orang-orang yang paling mampu memanfaatkan perubahan dalam bisnis dan perekonomian. Sebagai contoh, pada akhir abad kesembilan belas, Andrew Carnegie sangat memperluas kerajaannya dengan membeli usaha yang sangat ia bergantung pada untuk bisnis baja-nya, membuat satu perusahaannya contoh sukses pertama dari integrasi vertikal. Dimulai pada 1990-an, perubahan datang pada tingkat yang secara eksponensial lebih cepat karena faktor-faktor seperti persaingan yang meningkat dalam ekonomi global, memperluas pasar, cara-cara baru melakukan bisnis (seperti e-commerce), dan tugas di mana-mana menjaga dengan yang terbaru teknologi. Guru manajemen Peter F. Drucker mengabdikan bukunya Manajemen Tantangan dari 21 abad ke topik yang sangat. Akibatnya, perusahaan harus merevisi (atau menyusun) misi perusahaan dan tujuan, praktek manajemen, dan fungsi bisnis sehari-hari. Perusahaan secara rutin mulai merancang ulang strategi bisnis, sering menggantikan bagan 9

116 organisasi tradisional hirarki dengan struktur datar berpusat di sekitar diberdayakan tim. Tujuan utama bagi kebanyakan organisasi adalah untuk perubahan iklim dan budaya perusahaan. iklim Suatu organisasi dapat didefinisikan oleh bagaimana karyawan melihat alasan mendasar organisasi. karena, khususnya, misi perusahaan secara keseluruhan dan tujuan dan bagaimana pentingnya pengertian karyawan kesejahteraan adalah tujuan-tujuan tersebut. Iklim perusahaan kemudian melahirkan budaya organisasi yang terdiri dari apa karyawan lihat sebagai kepercayaan manajemen dan sistem nilai. Kedua hal, iklim dan budaya, kemudian menentukan bagaimana setiap manajer dan karyawan bentuk kinerja nya sendiri, biasanya dalam rangka paling berhasil mencapai tujuan perusahaan dan mudah-mudahan memastikan keberhasilan sendiri serta perusahaan. Faktor-faktor ini mempengaruhi setiap aspek dari pekerjaan setiap orang, termasuk proses pengambilan keputusan, pola komunikasi dalam organisasi, dan tanggung jawab individu dan tanggung jawab perusahaan. INDIKATOR PERUBAHAN Ada empat indikator utama dari perubahan pekerjaan-tempat utama.. Mereka adalah perubahan struktur organisasi, produk atau jasa baru, manajemen baru, dan teknologi baru. Struktur Organisasi bisa berubah melalui perampingan besar, outsourcing, akuisisi, atau merger. Tindakan ini sering disertai dengan PHK, khususnya sebagai posisi tertentu menjadi berlebihan.. Sebuah produk atau jasa baru memiliki implikasi untuk perubahan dalam produksi, penjualan, dan layanan pelanggan.. Selain itu, dengan mengubah produk atau jasa organisasi mungkin menghadapi pesaing baru atau pasar baru.. manajemen baru, seperti perubahan dalam CEO atau presiden, sering membawa masa transisi di mana para manajer tingkat atas cenderung untuk mengubah proses bisnis yang ada dan kebijakan personil. Akhirnya, teknologi baru dapat membuat perubahan besar bagi organisasi. Teknologi dapat mengubah proses produksi atau kondisi kerja (yaitu, telecommuting), dan perubahan ini mungkin mempengaruhi keterampilan yang karyawan menggunakan pada pekerjaan. 10

117 MODUL PERKULIAHAN Testing dan Implementasi SI Modul Standar untuk digunakan dalam Perkuliahan di Universitas Mercu Buana Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh Fasilkom Program Tim Dosen Studi Sistem 15 Informasi Abstract Distribusi Perangkat Lunak Kompetensi Memahami Distribusi Perangkat Lunak 1

118 Pendistribusian Proyek Pengujian Dalam suatu proyek tes kadang-kadang ada pihak dan orang-orang di luar organisasi testing yang harus turut terlibat. Bahkan dalam suatu proyek tes perangkat lunak harus melibatkan pihak atau orang-orang dari luar organisasi. Cara tersebut diatas dapat dilakukan dengan cara : 1. Melibatkan vendor : perusahaan yang menyediakan produk yang akan dintegrasikan pada produk yang sedang dikembangkan. 2. Melibatakan organisasi testing independen. 3. Melibatkan kantor pemasaran (terutama kantor di luar negeri untuk melakukan testing lokalisasi) 4. Melibatkan pemakai/pelanggan (beta testing) Tahap mendistribusikan proses pengujian 1. Pemilihan rekanan, berdasarkan kebutuhan akan testing yang bersifat khusus. 2. Perencanaan 3. Pengelolaan proses testing yang dilakukan secara ekster-nal seperti bila kita melaku-kannya secara internal. Pemilihan rekanan Ada dua alasan untuk memilih rekanan: 1. Memanfaatkan kemampuan/ kelebihan yang dimiliki rekanan. 2. Untuk mengurangi beban pekerjaan. Pihak yang dapat dijadikan rekanan dalam proyek (Vendor/Pemasok, Third-Party Testers, Sales Office) Pemasok / Vendor Ada 3 faktor utama utk melibatkan vendor dlm proses testing : Irreplaceability, Coupling, Capability Third-Party Testers 1. Sumber daya testing dari pihak ketiga adalah setiap organisasi yang menawarkan jasa testing kepada pelanggannya. 2. Jasa ini dpt diberikan secara off site, on site, atau keduanya. 2

119 3. Berdasarkan caranya mengelola proyek testing, organisasi pihak ketiga yang menawarkan jasa testing dapat dibedakan menjadi 2, yaitu: Temporary Agency (Agen Sementara) : menyediakan ahli testing. Perusahaan Testing Pihak Ketiga : membuat perencanaan suatu proyek testing dan pengelolaannya. Keuntungan pemanfaatan Third-Party Tester 1. Memiliki keahlian dalam bidang pengelolaan proyek testing dan memiliki pengalaman untuk melakukan testing secara teknis. 2. Dapat menyelesaikan proyek testing lebih cepat. Kantor Pemasaran 1. Kantor pemasaran yg tersebar di seluruh dunia dpt dimanfaat-kan untuk melakukan testing yang berhubungan dengan lokalisasi suatu sistem. 2. Kelemahannya: tidak dapat melakukan proses testing yang rumit atau yg bersifat terlalu teknis. Perencanaan sebuah proyek uji yang terdistribusi 1. Menilai Kemampuan 2. Biaya: biaya tetap dan biaya waktu dan material 3. Menyusun, mengkoordinasi, dan membagi program testing. 4. Pengelolaan Logistik 5. Pemetaan Kasus Testing Pemetaan kasus Testing 1. Memetakan kasus testing yang dilakukan oleh pihak ketiga pada pola yang sesuai dengan kebutuhan. 2. Dilakukan pada tahap koordinasi proyek testing. Pengelolaan testing yang terdistribusi 1. Memantau pelaksanaan testing. 2. Mengkomunikasikan status testing. 3. Menangani Pertimbangan2 Politis 4. Peka terhadap terjadinya Pertentangan kebiasaan/ kebudayaan. 3

120 5. Menanamkan dan menjaga unsur kepercayaan. 4

121 MODUL PERKULIAHAN Testing dan Implementasi SI Modul Standar untuk digunakan dalam Perkuliahan di Universitas Mercu Buana Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh Fasilkom Program Tim Dosen Studi Sistem 14 Informasi Abstract Oranisasi dalam Pengetesan Perangkat Lunak Kompetensi Memahami Organisasi Dalam Pengetesan Perangkat Lunak 1

122 2

123 3

124 4

125 5

126 6

127 7