METODE DESAIN RPL

AKTIFITAS DESAIN DALAM RPL

1. Desain Data (Data Design)
2. Desain Arsitektur (Architectural Design)
3. Desain Antar Muka (Interface Design)
4. Desain Prosedural (Procedural Design)

• Desain Data

Desain data adalah aktivitas pertama dan terpentig dari empat aktivitas desain yang dilakukan selama rekayasa perangkat lunak. Proses pemilihan struktur dalam menentukan desain yang paling efisien sesuai kebutuhan.

Tujuan: Untuk mendapatkan struktur data yang baik sehingga diperoleh program yang lebih modular dan mengurangi kompleksitas pengembangan software.

Prinsip Mendesain Data

• Prinsip analisis sistematika yang diaplikasikan pada fungsi dan perilaku harusnya juga diaplikasikan pada data.
• Semua struktur data dan operasi yang akan dilakukan pada masing-masing struktur data harus didentifikasi.
• Kamus data harus dibangun dan digunakan untuk menentukan baik data maupun desain program.
• Keputusan desain data tingkat rendah harus ditunda sampai akhir proses desain.
• Representasi struktur data hanya boleh diketahui oleh modul-modul yang menggunakan secara langsung data yang diisikan didalam struktur tersebut.
• Pustaka struktur data dan operasi yang berguna yang dapat diaplikasikan pada struktur data tersebut harus dikembangkan.
• Desain perangkat lunak dan bahasa pemrograman harus mendukung spesifikasi dan realisasi dari tipe-tipe data abstrak.
• Desain Arsitektur

Desain arsitektur adalah untuk mengembangkan struktur program modular dan merepresentasikan hubungan kontrol antar modul. Metode desain yang disajikan pada bagian ini mendorong prekayasa perangkat lunak untuk berkosentrasi pada desain arsitektur sebelum mencemaskan masalah perpipaan.

Faktor seleksi yang penting untuk suatu metode desain adalah luasnya apliksi dimana aplikasi dapat diaplikasikan. Desain berorientasi pada aliran data dapat menyetujui rentang area aplikasi yang luas.

• Proses Desain Arsitektur

Desain yang berorientasi pada aliran data merupakan suatu metode desain arsitektur yang mengijinkan transisi yang baik dari model analisis ke deskripsi desain dari struktur program.

Transisi dari aliran informasi (yang ditujukan sebagai diagram aliran data) kestruktur dilakukan bagian dari proses 5 langkah:

1. Tipe aliran informasi dibangun.
2. Batas aliran diindikasikan.
3. DFD dipetakan didalam struktur program.
4. Hirarki kontrol ditentukan dengan pemfaktoran.
5. Struktur resultan disaring atau diperhalus dengan menggunakan pengukuran desain dan heuristik.

• Pasca Pemrosesan Desain

1. Aplikasi dari pemetaan transaksi dan transformasi yang berhasil kemudian ditambahkan pada dokumentasi tambahan yang dibutuhkan sebagai bagian dari desain arsitektur. Setelah struktur dikembangkan dan disaring, tugas – tugas berikut harus dilakukan:
   1. Mengembangkan narasi pemerosesan untuk masing – masing modul.
   2. Menyediakan deskripsi interface untuk masing – masing modul.
   3. Menentukan struktur data local dan global.
   4. Mencatat semua batasan desain.
   5. Mengkaji desain.
   6. Mempertimbangkan “optimasi” (bila perlu dan dibenarkan).

• Optimasi Desain Arsitektur

1. Desainer perangkat lunak harus memperhatikan perkembangan representasi perangkat lunak yang akan memenuhi semua fungsi dan persyaratan kinerja dan penerimaan jasa berdasarkan pengukuran desain kualitas.
   Usul pendekatan berikut ini untuk perangkat lunak kinerja – kritis dalam optimasi desain arsitektur:
   1. Kembangkan dan saringlah struktur program tanpa memperhatikan optimasi kinerja – kritis.
   2. Gunakan peranti CASE yang mensimulasi kinerja run – time untuk menisolasi area inesifiensi.
   3. selama iterasi desain selanjutnya, pilihlah modul yang dicurigai dan dengan hati – hati kembangkanlah prosedur (algoritma – algoritma) untuk efisiensi waktu.
   4. Kodekan sebuah bahasa pemerograman yang sesuai.
   5. Instrumentasikan perangkat lunak untuk mengisolasi modul yang menjelaskan utilisasi proses yang berat.
   6. Bila perlu, Desain ulang atau kodekan kembali bahasa yang tergantung pada mesin untuk meningkatkan efisiensi.

• Desain Interface

1. Memberikan suatu gambaran mengenai struktur program kepada perekayasa perangkat lunak. Fokus Desain Interface :
   1. Desain interface antar modul
   2. Desain interface antara perangkat lunak dan entitas eksternal (produser & konsumen)
   3. Desain interface manusia dengan komputer

• Desain Interface Manusia-Mesin

1. Ada empat model yang berbeda pada saat manusia-komputer/ human-komputer interface (HCL) akan didesain. Perekayasa perangkat lunak menciptakan sebuah model desain, perekayasa perangkat lunak membangun model pemakai, pemakai akhir mengembangkan citra mental yang sering disebut user’s model atau perception, dan implementer sistem menciptakan system image.
   Model desain dari keseluruhan sistem menggabungkan data, arsitektur, interface, dan representasi prosedural dari perangkat lunak.
   Model pemakai menggambarkan profil para pemakai akhir dari sistem. Untuk membangun interface pemakai yang efektif, semua desain harus dimulai dengan suatu pemahaman terhadap pemakai yang dimaksudkan, meliputi profil, usia, jenis kelamin.
   Para pemakai juga dapat dikategorikan sebagai:
   – Orang baru
   – Pemakai intermiten yang banyak pengetahuan
   – Pemakai yang banyak pengetahuan dan sering
   Persepsi sistem (model pemakai) merupakan citra sistem yang ada dikepala seorang pemakai akhir. Sebgai contoh, bila pemakai pengelola kata tersebut, persepsi sistem akan menuntun respon tersebut.
   Citra sistem merangkai manifestasi bagian luar dari sistem berbasis computer (tampilan luar dan “rasa” interface), dengan semua informasi yang mendukung (buku-buku, manual, pita video) yang menggambarkan sintaksis dan semantik sistem.

• Desain Prosedural

1. Tujuan: untuk menetapkan detail algoritma yang akan dinyatakan dalam suatu bahasa tertentu.
   Desain prosedural dilakukan setelah diselesaikannya perancangan desain data, arsitektur, dan antar muka software.

• CodingProgram Design Language (PDL)
  à adalah pseudocode atau suatu bahasa keseluruhan yang sintaksnya dari bahasa tertentu (pemrograman terstruktur).

TUGAS RPL

Membuat Use Cace, Aktivity dan Sequence Model

1. Use case Kamus Kesehatan

gambar Use case Kamus Kesehatan

2. Activity Model Kamus

gambar activity Kamus

3. Activity Model Tips Kesehatan

gambar activity model Tips Kesehatan

4. Activity Model About

gambar activity model About

5. Sequance Model Kamus

gambar sequance model Kamus

6. Sequance Model Tips Kesehatan

gambar sequance model Tips Kesehatan

7. Sequance Model About

8. Diagram class Kamus

9. Diagram Tips Kesehatan

gambar sequance model About

IMPLEMENTASI PERANGKAT LUNAK

Pengertian

Tahap implementasi pengembangan perangkat lunak adalah: Suatu proses pengubahan spesifikasi sistem menjadi sistem yang dapat dijalankan. Pada kegiatan-kegiatan proses perancangan yang spesifik terdapat lima bagian diantaranya:

Perancangan arsitektural merupakan subsistem-subsistem yang membentuk sistem dan hubungan mereka diindentifikasikan dan didokumentasikan.

Spesifikasi abstrak untuk setiap subsistem, spesifikasi abstrak dari layanan dan batas operasinya harus ditentukan.

Perancangan interface untuk setiap subsistem, interface dengan subsistem dirancang dan didokumentasikan. Spesifikasi interface harus sudah jelas karena memungkinkan subsistem dipakai tanpa mengetahui operasi sistem.

Perancangan komponen layanan dialokasikan pada komponen yang berbeda dan interface komponen-komponen dirancang.

Perancangan struktur data struktur data yang dipakai pada implementasi sistem dirancang secara rinci dan dispesifikasi.

gambar tahapan implementasi pada Siklus Hidup Pengembangan Sistem

Makna & Tujuan Implementasi

• Merupakan tahap besar di akhir produksi PL
• Tahap ini merupakan proses pembuatan kode program berdasarkan platform dan kesepakatan dengan customer.
• Merupakan tahap transformasi dari hasil desain ke dalam program yang dpt dijalankan pada komputer yang akan digunakan di dalam sistem.
• Baik buruknya implementasi sangat tergantung pada baik buruknya hasil final dari tahap desain.
• Melibatkan pengintegrasian semua komponen rancangan sistem termasuk PL, konversi ke sistem operasi.

Proses Implementasi
Proses implementasi melibatkan:
1. Perencanaan
2. Pengeksekusian

Rencana Implementasi
Merupakan formulasi rinci dan representasi grafik mengenai cara pencapaian implementasian sistem yang akan dilaksanakan
Tim implementasi yg terlibat:
•Manajer dan beberapa staff
•Profesional sistem yang merancang sistem
•Perwakilan Vendor
•Pemakai Primer
•Pengcode/programmer
•Teknisi

gambar rancangan Implementasi
Hal Penting Dalam Implementasi
1. Persiapan Tempat

Persiapan tempat Yang perlu dipersiapkan : Ruang (sesuai dengan platform teknologi yang akan digunakan – Micro, mini atau mainframe) Listrik, Telpon, koneksi lainnya, ventilasi, AC, Keset anti debu, karpet, rak, penyangga barang, meja, penyimpan disk/pita, lemari kabinet, tempat personil, lokasi printer, dudukan printer dan furniture yang dirancang secara ergonomis Pengujian Burn in (simulasi operasi pada vendor).
2.Pelatihan Personil

Pelatihan Personil “Tidak ada sistem yang bekerja secara memuaskan jika para pemakai dan orang lain yang berinteraksi dengan sistem tersebut tidak dilatih secara benar” “Pelatihan Personil tidak hanya meningkatkan keahlian/ketrampilan pemakai, namun juga memudahkan penerimaan mereka terhadap sistem baru”.

Pelatihan Personil Yang perlu diberi pelatihan : Personel teknis yang akan mengoperasikan dan memelihara sistem tsb. Berbagai pekerja dan supervisor yang akan berinteraksi langsung dengan sistem untuk mengerjakan tugas dan membuat keputusan Manajer Umum (Pihak luar yang berinteraksi dengan sistem) Pelatihan meningkatkan kepercayaan diri, meminimi- sasi kerusakan, kesalahan pada tahap awal operasi.
3.Cakupan Pelatihan

Tutorial, mengajarkan cara menjalankan sampai pelatihan untuk mengajarkan pokok-pokok sistem baru.
4.Program Pelatihan

Pelatihan In house Pelatihan yang disediakan oleh vendor Jasa pelatihan luar
5.Teknik dan Alat Bantu Pelatihan

Teleconferencing Perangkat lunak pelatihan interaktif Pelatihan dengan instruktur Pelatihan magang Manual prosedur Buku teks.
6.Software untuk pelatihan interaktif

CBT (Computer-Based Training) ABT (Audio-Based Training) VBT (Video-Based Training) VOD (Video-Optical Disk).
7.Persiapan / pembuatan dokumen

Menyiapkan Dokumen Dokumentasi adalah materi tertulis/video/audio yang menjabarkan cara beroperasinya sebuah sistem (termasuk pokok- bahasan-pokok bahasan yang harus dikuasai oleh pemakai) Tujuan Dokumentasi : Pelatihan Penginstruksian Pengkomunikasian Penetapan standart kinerja Pemeliharaan sistem Referensi historis
8.Konversi File & Sistem

Dokumentasi
Tujuan dokumentasi:
1.Pelatihan
2.Penginstruksian
3.Pengkomunikasian
4.Penetapan standar kinerja
5.Pemeliharaan sistem
6.Referensi historis
Empat area utama dokumentasi:
1.Dokumen pemakai
2.Dokumen Sistem
3.Dokumen Perangkat lunak
4.Dokumen operasi

Konversi
1.Konversi Langsung
Sistem yang lama langsung digantikan dengan sistem yang baru
2.Konversi Paralel
Sistem lama masih dijalankan sambil menjalankan sistem baru.
3.Konversi Phase-in
Sistem lama digantikan secara berangsur angsur sedikit demi sedikit.
4.Konversi Pilot
Dilakukan secara segmentasi bagian per bagian

Metode Konversi Langsung
Konversi ini baik dilakukan jika :
Sistem baru tidak menggantikan sistem lama
Sistem lama sepenuhnya tidak bernilai
Sistem baru bersifat kecil/sederhana
Rancangan sistem baru sangat berbeda dari sistem lama

Metode Konversi Pararel
Memberikan derajat proteksi yang tinggi dari kegagalan sistem baru
Biaya yang dibutuhkan cukup besar karena keduanya harus jalan bersama-sama

Metode Konversi Phase-in
Sistem baru di implementasikan sedikit demi sedikit untuk menggantikan sistem lama
Sistem harus disegmentasi
Perlu biaya tambahan utk membangun interface temporer dg sistem lama
Proses implementasi membutuhkan waktu yang panjang

Metode Konversi Pilot
Perlunya segmentasi organisasi
Resiko lebih rendah dibandingkan metode konversi langsung
Biaya lebih rendah dibanding metode paralel
Cocok digunakan apabila adanya perubahan prosedur, HardWare, dan SoftWare

Konversi File Data
Keberhasilan konversi sistem sangat tergantung pada seberapa jauh profesional sistem menyiapkan konversi file data yang diperlukan di dalam sistem baru.
Konversi/Modifikasi Meliputi:
Format file
Isi file
Media penyimpanan

Metode Dasar Konversi
Metode Dasar Konversi:
1.Konversi File Total
Dpt digunakan pada ke-4 metode konversi sistem
2.Konversi File Gradual
Lebih banyak digunakan utk metode paralel dan phase-in
Selama konversi file perlu diperhatikan prosedur kendali untuk memastikan integrasi data
Prosedur kendali utk masing2 file berbeda
Suatu transaksi diterima dan dimasukkan ke dalam sistem
Program mencari file master baru untuk record yang akan diupdate oleh transaksi tsb.jika record tsb ada maka pengupdatean record selesai.

Klasifikasi File
Klasifikasi file:
File Master
File Transaksi
File Index
File Tabel
File Backup

Tahapan Implementasi
Struktur dekomposisi, struktur data, dan identitas dipilih dan di kerjakan sampai prosedur desain mudah untuk ditata ulang dalam sebuah implementasi
Level abstraksi pada desain, misal class, modul, algoritma, struktur data, dan tipe data harus diwujudkan dalam implementasi
Antarmuka antara komponen sistem perangkat lunak harus diwujudkan secara jelas pada tahap implementasi
Kode program tersebut harus dapat di cek konsistensinya pada setiap objek dan operasinya secara langsung menggunakan kompilator.

Kriteria Lingkungan Pemrograman

1.Modularity (Modularitas)

2.Dokumentasi Nilai Pada Bahasa Pemrograman

3.Struktur Data Dalam Bahasa Pemrograman

4.Struktur Aliran Pengendali
5.Efisiensi

6.Integritas

7.Portability ( multiplatform )
8. Dukungan Dialog

9. Quality

10.Ketersediaan pustaka ( Library )

11.Ketersediaan Tool Pembangunan

12.Kebijakan Instansi

13.Kebutuhan Eksternal

Programming Style
Menulis sebuah program adalah seni dan merupakan proses yang kreatif
Gaya pemrograman pada programmer mempengaruhi tingkat kemudahan pembacaan program yang dibuatnya
Buku Code Complete
Mengulas tuntas suatu gaya pemrograman bahkan di dalamnya diberkan contoh variasi yang cukup banyak.
Gaya pemrograman yang baik sangat didukung dari tahap desain dan perencanaan implementasi yang baik

STRATEGI PENGUJIAN PERANGKAT LUNAK

STRATEGI PENGUJIAN PERANGKAT LUNAK

Dalam strategi pengujianperangkat lunak dapat digambarkan dengan ilustrasi berikut: Sebuah perangkat lunak dimulai daripenentuan kebutuhan perangkat lunak, kemudian prose dilanjutkan ke dalam bentukrancangan, dan akhirnya ke pengkodean. Strategi pengujian serupa dengan haltersebut, dimulai dengan unit testing di pusat spiral di mana masing-masingmodul/unit dari perangkat lunak yang diimplementasikan dalam source codemenjadi sasaran pengujian. Kemudian dilakukan integration testing dengan focuspengujian adalah desain dan kontruksi arsitektur perangkat lunak. Selanjutnyadilakukan validation testing dengan sasaran pengujian adalah kesesuaian dengankebutuhan perangkat lunak yang telah ditentukan di awal. Terakhir padalingkaran terluar spiral sampai pada system testing, di mana perangkat lunakdan keseluruhan sistem diuji.

DASAR-DASAR PENGUJIAN PERANGKAT LUNAK

Proses Testing

• System Testing

– Pengujian terhadap integrasi sub-system, yaitu keterhubungan antar sub-system

• Acceptance Testing

– Pengujian terakhirs sebelum sistem dipakai oleh user.

– Melibatkan pengujian dengan data dari pengguna sistem.

– Biasa dikenal sebagai “alpha test” (“beta test” untuk software komersial, dimana pengujian dilakukan oleh potensial customer)

• Proses Testing

gambar proses testing

Component testing

• Pengujian komponen-komponen program
• Biasanya dilakukan oleh component developer (kecuali untuk system kritis)

Integration testing

• Pengujian kelompok komponen-komponen yang terintegrasi untuk membentuk sub-system ataupun system
• Dialakukan oleh tim penguji yang independent
• Pengujian berdasarkan spesifikasi sistem

Rencana Pengujian

1. Proses testing : Deskripsi fase-fase utama dalam pengujian
2. Pelacakan Kebutuhan : Semua kebutuhan user diuji secara individu
3. Item yg diuji : Menspesifikasi komponen sistem yang diuji
4. Jadual Testing
5.  Prosedur Pencatatan Hasil dan Prosedur
6. Kebutuhan akan Hardware dan Software
7. Kendala-kendalaMis: kekuranga staff, alat, waktu dll.

gambar rencana pengujian

A. PendekatanStrategis ke Pengujian Perangkat lunak

Pengujianmerupakan rangkaian aktivitas yang dapat direncanakan sebelumnya dan dilakukansecara sistematis. Strategi uji coba perangkat lunak memudahkan para perancanguntuk menentukan keberhasilan system yg telah dikerjakan. Hal yg harusdiperhatikan adalah langkah-langkah perencanaan dan pelaksanaan harusdirencanakan dengan baik dan berapa lama waktu, upaya dan sumber daya ygdiperlukan Strategi uji coba mempunyai karakteristik sbb :

a. Pengujian mulai pada tingkat modul yg paling bawah,dilanjutkan dgn modul di atasnya kemudian hasilnya dipadukan

b. Teknik pengujianyang berbeda mungkin menghasilakn sedikit perbedaan (dalam hal waktu)

c. Pengujiandilakukan oleh pengembang perangkat lunak dan (untuk proyek yang besar) suatukelompok pengujian yang independen.

d. Pengujian dandebugging merupakan aktivitas yang berbeda, tetapi debugging termasuk dalamstrategi pengujian.

Validasi dan validasi

Verifikasi dan validasi merupakandua istilah yang sering dikaitkan dengan tahapan pengujian perangkat lunak.Verifikasi mengacu pada serangkaian aktivitas untuk memastikan bahwa perangkatlunak mengimplementasikan fungsi tertentu secara benar, sedangkan validasimengacu pada serangkaian aktivitas untuk memastikan bahwa perangkat lunak yangtelah dibuat sesuai denga kebutuhan konsumen.

Definisi V&V mencakupserangkaian aktivitas dari penjaminan kualitas perangkat lunak (SQA) yangmeliputi kajian teknis formal, audit kualitas dan control, monitoring kinerja,simulasi, studi feasibilitas, kajian dokumentasi, kajian basisdata, analisisalgoritma, pengujian pengembangan, pengujian kualifikasi, dan pengujianinstalasi.

Pengorganisasian Pengujian Perangkat Lunak

Proses pengujian sebuah perangkat lunaksebaiknya melibatkan pihak yang memang secara khusus bertanggung jawab untukmelakukan proses pengujian secara independen. Untuk itulah diperlukanIndependent Test Group (ITG).

Peran dari ITG adalah untuk menghilangkan“conflict of interest” yang terjadi ketika pengembang perangkat lunak berusahauntuk menguji produknya sendiri.

Walaupun seperti itu, sering terjadibeberapa kesalahan pemahaman berkaitan dengan peran ITG, antara lain:

a. Pengembangtidak boleh melakukan pengujian sama sekali. Pendapat ini tidak 100% benar,Karena dalam banyak kasus, pengembang juga melakukan proses unit testing danintegration test.

b. Perangkatlunak dilempar begitu saja untuk diuji secara sporadic. Hal tersebut adalahsalah karena pengemmbang dan ITG bekerja sama pada kesalahan proyek untukmemastikan pengujian akan dilakukan. Sementara pengujian dilakukan, pengembangharrus memperbaiki kesalahan yang ditemukan.

c. Pengujitidak terlibat pada proyek sampai tahap pengujian dimulai. Hal tersebut salahkarena ITG merupakan bagian dari tim proyek pengembangan perangkat lunak dimanaia terlihat selama spesifikasi proses dan tetap terlinat pada keseluruhanproyek besar.

B.Masalah-Masalah Strategis

Masalah-masalah berikut harus diselesaikanbila pengujian ingin berlangsung sukses:

1. Menspesifikasikan kebutuhan produkpada kelakuan yang terukur sebelum pengujian dimulai. Strategi pengujian yangbaik tidak hanya untuk menenmukan kesalahan, namun juga unutk menilai kualitasprogram.

2. Menspesifikasikan tujuan pengujiansecara eksperangkat lunakisit. Sasaran spesifik dari pengujian harus dinyatakandalam bentuk yang terukur

3. Mengidentifikasikan kategori useruntuk perangkat lunak dan membuat profilnya masing-masing. Beberapa kasus yangmenggambarkan scenario interaksi bagi masing-masing kategori dapat mengurangikerja pengujian dengan memfokuskan pengujian pada penggunaan actual produk.

4. Membangun rencana pengujian yangmenegaskan rapid cycle testing. Umpan balik yang muncul dari rapid cycletesting dapaat digunakan untuk mengontrol kualitas dan strategi pengujian yangsesuai.

5. Membangun perangkat lunak yang tangguhyang dirancang untuk menguji dirinya sendiri. Perangkat lunak dapatmendiagnosis jenis-jenis kesalahan tertentu dan mengakomodasi pengujianotomatis dan pengujian regresi.

6. Menggunakan tinjauan formal yang efektif sebagai filter sebekum pengujian.Kajian teknis formal dapat mengungkap kesalahan seefektif pengujian sehinggadapat mengurangi jumlah kerja pengujian.

7. Mengadakan tinjauan formal dapatmengungkap inkonsistensi, penghapusan, dan kesalahan seketika dalam pendekatanpengujian.

8. Membangun pendekatan yang meningkatsecara berkelanjutan untuk proses pengujian. Strategi pengujian harus terukur.Metric yang terkumpul selama pengujian harus digunakan sebagai bagian daripendekatan control proses statistical bagi pengujian perangkat lunak.

C. PengujianUnit

Unit testing (uji coba unit) fokusnya pada usahaverifikasi pada unit terkecil dari desain perangkat lunak, yakni modul. Ujicoba unit selalu berorientasi pada white box testing dan dapat dikerjakanparalel ayau beruntun dengan modul lainnya.

PertimbanganPengujian Unit

Interface modul diuji untuk memastikan bahwa informasisecara tepat mengalir masuk dan keluar dari inti program yang diuji. Strukturdata local diuji untuk memastikan bahwa data yang tersimpan secara temporaldapat tetap menjaga integritasnya selama semua langkah langkah di dalamsuatu algoritma dieksekusi. Kondisi batas diuji untuk memastikan bahwa modulberoperasi dengan tepat pada batas yang ditentukan untuk membatasipemrosesan. Semua jalur independen(jalur dasar) yang melalui struktur controldipakai sedikirnya satu kali. Dan akhirnya penanganan kesalan diuji.

Prosedur Pengujian Unit

sumber telah dikembangkan, ditunjang kembali dandiverifikasi untuk sintaksnya, maka perancangan test case dimulai. Peninjauankembali perancangan informasi akan menyediakan petunjuk untuk menentukan testcase. Karena modul bukan program yg berdiri sendiri maka driver (pengendali)dan atau stub perangkat lunaK harus dikembangkan untuk pengujian unit.

Driver adlprogram yg menerima data untuk test case dan menyalurkan ke modul yg diuji danmencetak hasilnya.

Stub melayanipemindahan modul yg akan dipanggil untuk diuji

D. Pengujian Integrasi

Pengujian terintegrasi adl teknik yg sistematis untukpenyusunan struktur program, pada saat dikerjakan uji coba untuk memeriksakesalahan yg nantinya digabungkan dengan interface. Metode pengujian:

1. Top down integration

Merupakan pendekatan inkrmental untuk penyusunanstruktur program. Modul dipadukan dgn bergerak ke bawah melalui kontrol hirarkidimulai dari modul utama. Modul subordinat ke modul kontrol utama digabungkanke dalam struktur baik menurut depth first atau breadth first.

Proses integrasi:

a. Modul utama digunakan sebagai test driver danstub yg menggantikan seluruh modul yg secara langsung berada di bawah modulkontrol utama.

b. Tergantung pada pendekatan perpaduan yg dipilih(depth / breadth)

c. Uji coba dilakukan selama masing-masing moduldipadukan

d. Pada penyelesaian masing-masing uji coba stub yglain dipindahkan dgn modul sebenarnya.

e. Uji coba regression yaitu pengulangan pengujianuntuk mencari kesalahan lain yg mungkin muncul.

2. Buttom up integration

Pengujian buttom up dinyatakan dgn penyusunan ygdimulai dan diujicobakan dgn atomic modul (modul tingkat paling bawah pdstruktur program). Karena modul dipadukan dari bawah ke atas, proses ygdiperlukan untuk modul subordinat yg selalu diberikan harus ada dan diperlukanuntuk stub yg akan dihilangkan.

Strategi pengujian

a. Modul tingkat bawah digabungkan ke dalam clusteryg memperlihatkan subfungsi perangkat lunak

b. Driver (program kontrol pengujian) ditulisuntuk mengatur input test case dan output

c. Clusterdiuji

d. Driver diganti dan cluster yg dikombinasikandipindahkan ke atas pada struktur program

E. Pengujian Validasi

Setelah semua kesalahan diperbaiki maka langkahselanjutnya adalah validasi terting. Pengujian validasi dikatakan berhasil bilafungsi yg ada pada perangkat lunak sesuai dgn yg diharapkan pemakai. Validasiperangkat lunak merupakan kumpulan seri uji coba black box yg menunjukkansesuai dgn yg diperlukan.

Kemungkinan kondisi setelah pengujian:

1. Karakteristikperformansi fungsi sesuai dgn spesifikasi dan dapat diterima

2. Penyimpangandari spesifikasi ditemukan dan dibuatkan daftar penyimpangan.

Pengujian BETA dan ALPHA

Apabila PERANGKAT LUNAK dibuat untuk pelanggan makadapat dilakukan aceeptance test sehingga memungkinkan pelanggan untukmemvalidasi seluruh keperluan. Test ini dilakukan karena memungkinkan pelanggan menemukan kesalahan yg lebih rinci danmembiasakan pelanggan memahami PERANGKAT LUNAK yg telah dibuat.

Pengujian Alpha

Dilakukan pada sisi pengembang oleh seorang pelanggan.Perangkat Lunak digunakan pada setting yg natural dgn pengembang “yg memandang”melalui bahu pemakai dan merekam semua kesalahan dan masalah pemakaian

Pengujian Beta

Dilakukan pada satu atau lebih pelanggan oleh pemakaiakhir perangkat lunak dalam lingkungan yg sebenarnya, pengembang biasanya tidakada pada pengujian ini. Pelanggan merekan semua masalah (real atau imajiner) ygditemui selama pengujian dan melaporkan pada pengembang pada interval waktutertentu.

F. Pengujian Sistem.

Pada akhirnya PERANGKAT LUNAK digabungkan dgn elemensystem lainnya dan rentetan perpaduan system dan validasi tes dilakukan. Jikauji coba gagal atau di luar skope dari proses daur siklus pengembangan system,langkah yg diambil selama perancangan dan pengujian dapat diperbaiki.Keberhasilan perpaduan PERANGKAT LUNAK dan system yg besar merupakan kuncinya.

Sistem testing merupakan rentetan pengujian ygberbeda-beda dgn tujuan utama mengerjakan keseluruhan elemen system ygdikembangkan.

Recovery Testing

Adalah system testing yg memaksa PERANGKAT LUNAKmengalami kegagalan dalam bermacam-macam cara dan apakah perbaikan dilakukandgn tepat.

Security Testing

Adalah pengujian yg akan melalukan verifikasi darimekanisme perlindungan yg akan dibuat oleh system, melindungi dari hal-hal ygmungkin terjadi.

Strees Testing

Dirancang untuk menghadapi situasi yg tidak normalpada saat program diuji. Testing ini dilakukan oleh system untuk kondisi seperti volume data yg tidak normal (melebihiatau kurang dari batasan) atau fekuensi.

G. Debugging

Debugging bukan merupakanpengujian, namun merupakan konsekuensi dari pengujian yang berhasil. Jikasebuah kasus uji berhasil menemukan kesalahan, maka proses debugging bertujuanuntuk menghilangkan kesalahan tersebut.

Debugging merupakan proses yangsulit untuk dilakukan karena adanya beberapa karakteristik bug seperti:

1. Gejala dan penyebab dari bug bisa sajasangat jauh, gejala dapat muncul pada bagian tertentu dari program danpenyebabnya bisa saja berada pada bagian lain yang sangat jauh dari tempatmunculnya gejala.

2. Gejala dapat hilang ketika kesalahanyang lain diperbaiki

3. Gejala dapat ditimbulkan oleh sesuatuyang tidak salah(mis. Pembulatan yang tidak akurat).

4. Gejala dapat disebabkan oleh masalahtiming.

5. Kemungkinan sulit untuk memproduksikondisi onput secara akurat.

6. Gejala dapat terjadi tiba-tiba.

7. Gejala dapat disebabkan oleh sesuatuyang didistribusikan melewati sejumlah tugas yang bekerja pada prosesor yangberbeda-beda.

gambar debaging

Terdapat 3 jenis pendekatandebugging, antara lain:

a. Brute Force

Merupakan teknik yang paling seringdigunakan dan paling tidak efisien dalam mengisolasi penyebab kesalahan. Denganprinsip “biarkan computer menemukan kesalahan”, maka seluruh sumber dayacomputer digunakan dengan tujuan untuk menemukan penyebab kesalahan

b. Backtracking

Merupakan pendekatan yang dimulaidari penemuan gejala kemudian menelusuri balik hingga ke penyebab.

c. Cause Elimination

Dimanifestasikan oleh induksi ataudeduksi dan menggunakan konsep partisi biner. Data yang berhubungan dengankesalahan yang muncul dikumpulkan untuk mengisolasi penyebab. Kemudian dibuatsebuah hipotesis dan data digunakan untuk membuktikan hipotesis tersebut.Daftar rangkaian penyebab yang mungkin dibuat dan dilakukan pengujian untukmengeliminasi penyebab-penyebab tersebut. Jika pengujian menunjukkan kebenaranhipotesis untuk suatu penyebab, maka data diperbaiki untuk mengisolasi bug.Sekali bug ditemukan, bug harus diperbaiki. Namun, perbaikan pada bug dapatmemunculkan kesalahan lain, maka ada beberapa pertimbangan sebelum bugdihilangkan antara lain:

1) Apakah penyebab bug ada pada bagianlain dari program?

2) Apakah “bug yang lain” mungkin terjadipada saat perbaikan dilakukan?

3) Apakah yang telah dilakukan untukmencegah bug pada tempat pertama?