Rekayasa Perangkat Lunak (RPL 2)

Rekayasa Perangkat Lunak :

LANGKAH DASAR DALAM PROSES DESAIN:

1.        Mendefinisikan tujuan sistem (defining system goal), tidak hanya berdasarkan informasi pemakai, akan tetapi juga berupa telaah dari abstraksi dan karakteristik keseluruhan kebutuhan informasi sistem.

2.        Membangun sebuah model konseptual (develop a conceptual model), berupa gambaran sistem secara keseluruhan yang menggambarkan satuan fungsional sebagai unit sistem.

3.        Menerapkan kendala2 organisasi (applying organizational contraints). Menerapkan kendala-kendala sistem untuk memperoleh sistem yang paling optimal. Elemen organisasi merupakan kendala, sedangkan fungsi-fungsi yang harus dioptimalkan adalah: performance, reliability, cost, instalation schedule, maintenability, flexibility, grouwth potensial, life expectancy. Model untuk sistem optimal dapat digambarkan sebagai sebuah model yang mengandung: kebutuhan sistem dan sumber daya organisasi sebagai input; faktor bobot terdiri atas fungsi-fungsi optimal di atas; dan total nilai yang harus dioptimalkan dari faktor bobot tersebut.

4.        Mendefinisikan aktifitas pemrosesan data (defining data processing activities).

Pendefinisian ini dapat dilakukan dengan pendekatan input-proses-output. Untuk menentukan hal ini diperlukan proses iteratif sbb:

a. Mengidentifikasn output terpenting untuk mendukung/mencapai tujuan sistem (system’s goal)

b. Me-list field spesifik informasi yang diperlukan untuk menyediakan output tersebut

c. Mengidentifikasi input data spesifikik yang diperlukan untuk membangun field informasi yang diperlukan.

d. Mendeskripsikan operasi pemrosesan data yang diterapkan untuk mengolah input menjadi output yang diperlukan.

e. Mengidentifikasi elemen input yang menjadi masukan dan bagian yang disimpan selama pemrosesan input menjadi output.

f.  Ulangi langkah a-e terus menerus samapi semua output yang dibutuhkan diperoleh.

g. Bangun basis data yang akan mendukung efektifitas sistem untuk memenuhi kebutuhan sistem, cara pemrosesan data dan karakteristik data.

h. Berdasarakan kendala-kendala pembangunan sistem, prioritas pendukung, estimasi cost pembangunan; kurangi input, output dan pemrosesan yang ekstrim

i.  Definisikan berbagai titik kontrol untuk mengatur aktifitas pemrosesan data yang menentukan kualitas umum pemrosesan data.

j.  Selesaikan format input dan output yang terbaik untuk desain sistem.

5.        Menyiapkan proposal sistem desain. Proposal ini diperlukan untuk manajemen apakah proses selanjutnya layak untuk dilanjutkan atau tidak. Hal-hal yang perlu disiapkan dalam penyusunan proposal ini adalah:

a. Menyatakan ulang tentang alasan untuk mengawali kerja sistem termasuk tujuan/objektif khusus dan yang berhubungan dengan kebutuhan user dan desain sistem.

b. Menyiapkan  model yang sederhana akan tetapi menyeluruh sistem yang akan diajukan.

c. Menampilkan semua sumber daya yang tersedia untuk mengimplementasikan dan merawat sistem.

d. Mengidentifikasi asumsi kritis dan masalah yang belum teratasi yang mungkin berpengaruh terhadap desain sistem akhir.

Sedangkan format dari proposal desain ini sangat berfariasi akan tetapi mengandung hal-hal di atas.

PENJELASAN GAMBAR STRATEGI PENGUJIAN PERANGKAT LUNAK

Proses pengujian perangkat lunak dapat digambarkan sebagai berikut: 

Gambar 7.5 Strategi Pengujian Perangkat Lunak

Spiral di atas menggambarkan bagaimana rekayasa sistem membangun sebuah perangkat lunak dimulai dari penentuan kebutuhan perangkat lunak, kemudian (spiral bergerak ke dalam) proses dilanjutkan ke dalam bentuk rancangan, dan akhirnya ke pengkodean (di pusat spiral). Strategi pengujian serupa dengan hal tersebut, namun bergerak dimulai dari pusat menuju keluar spiral. Dimulai dengan unit testing di pusat spiral di mana masing-masing modul/unit dari perangkat lunak yang diimplementasikan dalam source code menjadi sasaran pengujian. Kemudian bergerak keluar spiral, dilakukan integration testing dengan fokus pengujian adalah desain dan konstruksi arsitektur perangkat lunak. Bergerak lagi keluar, dilakukan validation testing dengan sasaran pengujian adalah kesesuaian dengan kebutuhan perangkat lunak yang telah ditentukan di awal. Terakhir pada lingkaran terluar spiral sampai pada system testing, di mana perangkat lunak dan keseluruhan elemen sistem diuji.

Unit Testing

Berfokus pada verifikasi unit terkecil dari perangkat lunak. Dengan menggunakan gambaran desain prosedural, jalur kontrol yang penting diuji untuk mengungkap kesalahan pada modul tersebut. Pengujian ini biasanya berorientasi white-box, dan dapat dilakukan secara paralel untuk modul bertingkat.

Interface modul diuji untuk memastikan bahwa informasi secara tepat masuk dan keluar dari program yang diuji. Struktur data lokal diuji untuk memastikan bahwa data yang tersimpan secara temporal tetap terjaga integritasnya selama keseluruhan algoritma dieksekusi. Kondisi batas diuji untuk memastikan bahwa modul beroperasi dengan tepat pada batas yang ditentukan untuk membatasi pemrosesan.

Pengujian terhadap jalur eksekusi merupakan tugas penting selama unit testing. Kasus uji harus dirancang untuk mengungkap kesalahan yang berkaitan dengan kesalahan komputasi, kesalahan komparasi, dan aliran kontrol yang tidak tepat. Basis path testing dan loop testing merupakan teknik yang efektif untuk mengungkap kesalahan tersebut.

Prosedur unit testing biasanya melibatkan adanya driver dan stub. Driver adalah suatu program utama yang menerima data kasus uji, melewatkan data tersebut ke modul yang akan diuji, kemudian menampilkan hasilnya. Sedangkan stub adalah subprogram dummy yang berfungsi untuk menggantikan modul yang merupakan subordinat dari modul yang akan diuji.

Integration Testing

Merupakan teknik sistematis untuk mengkonstruksi struktur program sambil melakukan pengujian untuk mengungkap kesalahan berkaitan dengan interfacing. Sasarannya adalah modul yang telah diuji dengan unit testing dan konstruksi program dari modul tersebut sesuai rancangan perangkat lunak.

Pengujian ini akan lebih efektif pada integrasi inkremental, karena kesalahan interfacing dapat lebih mudah dideteksi pada modul mana saja yang mengalaminya, berbeda dengan integrasi secara bersamaan langsung di mana modul-modul yang mengalami kesalahan interfacing sulit untuk dideteksi.

Ada dua pendekatan integrasi, yakni:

- Top-down, di mana modul diintegrasikan ke bawah melalui hirarki kontrol dimulai dari modul utama. Subordinat modul selanjutnya digabungkan ke dalam struktur secara depth-first atau breadth-first.

Proses integrasi dilakukan dalam 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 dengan modul yang sebenarnya

3.  Pengujian dilakukan pada saat masing-masing modul diintegrasikan

4.  Pada saat pengujian hampir berakhir untuk sebuah modul, stub yang lain diganti dengan modul yang sebenarnya

5.  Dilakukan pengujian regresi untuk memastikan bahwa kesalahan baru belum muncul

- Bottom-up, dimulai dari konstruksi dan pengujian modul atomik yang berada pada tingkat paling rendah pada struktur program. Pendekatan ini dapat mengeliminasi peran stub karena pemrosesan untuk modul subordinat selalu tersedia. Langkah-langkahnya sebagai berikut:

1.       Modul tingkat rendah digabungkan ke dalam cluster (build) yang melakukan subfungsi perangkat lunak tertentu

2.       Driver dibuat untuk mengkoordinasi input dan output kasus uji

3.       Cluster diuji

4.       Driver diganti dan cluster digabungkan pada struktur di atasnya pada hirarki program Setiap kali sebuah modul ditambahkan, maka perangkat lunak akan berubah yang dapat menyebabkan masalah pada fungsi-fungsi yang telah bekerja sebelumnya. Pengujian integrasi merupakan eksekusi ulang dari beberapa subset yang telah dilakukan untuk memastikan bahwa perubahan tidak menimbulkan efek samping yang tidak diinginkan. Pengujian regresi dapat dilakukan secara manual atau dengan menggunakan alat capture playback otomatis. Pengujian regresi berisi tiga jenis kasus uji yang berbeda, yakni:

·         Sampel representatif 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

Ada pendekatan khusus dari integration testing yang sering digunakan untuk perangkat lunak “shrink wrapped” yang disebut dengan Smoke Testing. Pendekatan Smoke Testing mencakup aktivitas berikut ini:

·  Komponen perangkat lunak yang telah dikodekan diintegrasikan ke dalam build

·  Sekumpulan pengujian dirancang untuk menunjukkan kesalahan yang akan menghalangi build untuk menjalankan fungsinya dengan baik

·  Build diitegrasikan dengan build-build lainnya dan keseluruhan produk diuji dengan smoke testing secara rutin per harinya

Pendekatan ini memiliki beberapa keuntungan untuk proyek pengembangan yang kompleks dan bersifat time-critical, yakni:

- Meminimalkan resiko integrasi

- Meningkatkan kualitas produk akhir

- Menyederhanakan diagnosa kesalahan dan koreksi

- Memudahkan penilaian kemajuan pengembangan perangkat lunak

Untuk tiap fase pengujian pada integration testing, digunakan kriteria-kriteria berikut:

·  Integritas antarmuka. Antarmuka internal dan eksternal diuji pada saat masing-masing modul ditambahkan ke dalam struktur

·  Validitas fungsional. Pengujian dirancang untuk mengungkap kesalahan fungsional yang dilakukan

·  Isi informasi. Pengujian dirancang untuk mengungkap kesalahan yang berhubungan dengan struktur data global atu lokal yang digunakan

·  Kinerja. Pengujian dirancang untuk memeriksa batasan kinerja yang dibuat selama perancangan perangkat lunak          

 Validation Testing

Validation testing dilakukan setelah perangkat lunak selesai dirangkai sebagai suatu kesatuan dan semua kesalahan interfacing telah ditemukan dan dikoreksi. Validasi dikatakan berhasil jika perangkat lunak berfungsi sesuai dengan kebutuhan konsumen.

Validasi perangkat lunak diperoleh melalui sederetan pengujian Black-Box yang memperlihatkan kesesuaian dengan kebutuhan perangkat lunak. Semua kasus uji dirancang untuk memastikan apakah semua persyaratan fungsional telah dipenuhi, semua persyaratan kinerja tercapai, semua dokumentasi telah benar, dan persyaratan lainnya (transportabilitas, kompatibilitas, kemampuan pulih dari kesalahan, dan maintainabilitas) dipenuhi.

Adalah sangat tidak mungkin bagi pengembang perangkat lunak untuk meramalkan bagaimana konsumen benar-benar menggunakan perangkat lunak. Untuk mengatasi hal ini, dapat dilakukan acceptance testing untuk memungkinkan konsumen memvalidasi semua persyaratan. Dengan adanya penggunaan langsung oleh end-user, acceptance testing dapat mencakup test drive informal sampai deretan pengujian yang dieksekusi secara sistematis dan terencana.

Dua jenis acceptance testing yang biasa dilakukan oleh perusahaan pengembang perangkat lunak, yakni:

1.Alpha test, yakni pengujian yang dilakukan pada perangkat lunak oleh end-user dengan adanya supervisi dan kontrol dari pengembang perangkat lunak

2.Beta test, yakni pengujian yang dilakukan pada perangkat lunak oleh end-user tanpa adanya supervisi dan kontrol dari pengembang perangkat lunak. Jika ditemukan masalah, maka konsumen pemakai akan melaporkannya kepada pengembang perangkat lunak tersebut

System Testing

Pengujian yang sasaran utamanya adalah pada keseluruhan Sistem Berbasis Komputer, tidak hanya kepada perangkat lunak. Ada beberapa tipe dari system testing di antaranya:

1.Recovery testing merupakan pengujian sistem yang memaksa perangkat lunak untuk gagal dengan berbagai cara dan memeriksa apakah proses perbaikan dilakukan dengan tepat. Bila perbaikannya otomatis, maka inisialisasi ulang, mekanisme checkpoint, perbaikan data, dan restart masing-masing dievaluasi koreksinya. Bila tidak, maka waktu rata-rata perbaikan dievaluasi untuk menentukan apakah masih dapat ditolerir atau tidak

2.Security testing berusaha untuk membuktikan apakah mekanisme perlindungan yang dibangun pada sebuah sistem akan benar-benar dapat melindungi dari pengaruh yang salah

3.Stress testing dirancang untuk melawan program pada keadaan abnormal. Pengujian ini mengeksekusi sistem dalam kondisi kuantitas sumber daya yang abnormal

4.Performance testing dirancang untuk menguji kinerja perangkat lunak yang telah terintegrasi pada sistem pada saat run-time. Pengujian ini sebenarnya terjadi pada setiap tahapan, mulai dari unit testing pada modul, sampai kepada system testing ketika perangkat lunak telah terintegrasi pada sistem. Pengujian ini sering dikolaborasikan dengan stress testing dan menggunakan instrumen perangkat lunak dan perangkat keras untuk mengukur penggunaan sumber daya dengan cara yang tepat sehingga dapat mengungkap situasi yang menyebabkan kegagalan sistem.

 Strategi Pengujian Perangkat Lunak Berorientasi Objek

Strategi pengujian untuk perangkat lunak beriorientasi objek serupa dengan strategi pengujian yang telah dibahas sebelumnya. Namun terdapat beberapa perbedaan dengan beberapa strategi yang telah dibahas sebelumnya, yakni:

1.  Pada unit testing

Bagian terkecil yang diuji pada unit testing adalah kelas atau objek, tidak seperti unit testing konvensional yang fokus pada detail algoritmik dari perangkat lunak Tidak menguji operasi yang ada secara terpisah, seperti halnya unit testing konvensional, karena operasi-operasi pada satu kelas diuji bersamaan pada satu kelas

2.  Pada integration testing

Memiliki dua strategi yakni thread-based testing dan use-based testing

·  Thread-based testing yang mengintegrasikan sekumpulan kelas yang dibutuhkan untuk merespon suatu input atau event pada sistem. Setiap thread diintegrasikan dan diuji secara individual, kemudian dilakukan pengujian regresi untuk memastikan tidak ada efek samping yang muncul

·  Use-based testing yang menguji kelas independen (kelas yang menggunakan sangat sedikit kelas server) kemudian kelas yang menggunakan layanan kelas tersebut, kemudian dilanjutkan sampai keseluruhan perangkat lunak dibangun

Tahapan cluster testing di mana sekumpulan kelas yang berkolaborasi diuji untuk menemukan kesalahan pada saat berinteraksi

Debugging

Debugging bukan merupakan pengujian, namun merupakan konsekuensi dari pengujian yang berhasil. Jika sebuah kasus uji berhasil menemukan kesalahan, maka proses debugging bertujuan untuk menghilangkan kesalahan tersebut.

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

·  Gejala dan penyebab dari bug bisa saja sangat jauh, gejala dapat muncul pada bagian tertentu dari program dan penyebabnya bisa saja berada pada bagian lain yang sangat jauh dari tempat munculnya gejala

·  Gejala dapat hilang ketika kesalahan yang lain diperbaiki

·  Gejala dapat ditimbulkan oleh sesuatu yang tidak salah (mis. pembulatan yang tidak akurat)

·  Gejala dapat disebabkan oleh kesalahan manusia yang sulit untuk ditelusuri

·  Gejala dapat disebabkan oleh masalah timing

·  Kemungkinan sulit untuk memproduksi kondisi input secara akurat

·  Gejala dapat terjadi tiba-tiba

·  Gejala dapat disebabkan oleh sesuatu yang didistribusikan melewati sejumlah tugas yang bekerja pada prosesor yang berbeda-beda

Terdapat tiga jenis pendekatan debugging antara lain:

1.   Brute Force

Merupakan teknik yang paling sering digunakan dan paling tidak efisien dalam mengisolasi penyebab kesalahan. Dengan prinsip “biarkan komputer menemukan kesalahan”, maka seluruh sumber daya komputer digunakan dengan tujuan untuk menemukan penyebab kesalahan

2.   Backtracking

Merupakan pendekatan yang dimulai dari penemuan gejala kemudian menelusuri balik hingga ke penyebab

3.   Cause Elimination

Dimanifestasikan oleh induksi atau deduksi dan menggunakan konsep partisi biner. Data yang berhubungan dengan kesalahan yang muncul dikumpulkan untuk mengisolasi penyebab. Kemudian dibuat sebuah hipotesis dan data digunakan untuk membuktikan hipotesis tersebut. Daftar serangkaian penyebab yang mungkin dibuat dan dilakukan pengujian untuk mengeliminasi penyeba-penyebab tersebut. Jika pengujian menunjukkan kebenaran hipotesis untuk suatu penyebab, maka data diperbaiki untuk mengisolasi bug

Sekali bug ditemukan, bug harus diperbaiki. Namun, perbaikan pada bug dapat memunculkan kesalahan lain, maka ada beberapa pertimbangan sebelum bug dihilangkan antara lain:

Apakah penyebab bug ada pada bagian lain dari program?

Apakah “bug yang lain" mungkin terjadi pada saat perbaikan dilakukan?

Apakah yang telah dilakukan untuk mencegah bug pada tempat pertama?

PERANCANGAN DAN KUALITAS PERANGKAT LUNAK

McGlaughin [McG91] mengusulkan 3 karakteristik yang berfungsi sebagai pedoman bagi evaluasi sebuah perancangan yang baik :

1.Perancangan harus mengimplementasikan keseluruhan kebutuhan eksplisit yang dibebankan dalam model analisis, dan harus mengakomodasi semua kebutuhan implisit yang diinginkan oleh pelanggan.

2.Perancangan harus menjadi panduan yang dapat dibaca, mudah dipahami bagi mereka yang akan membuat kode dan yang pengujian serta memelihara perangkat lunak.

3.Perancangan harus memberikan sebuah gambaran lengkap mengenai perangkat lunak, yang menekankan data, dan domin perilaku dari perangkat lunak.

Perancangan perangkat lunak adalah disiplin manajerial dan teknis yang berkaitan dengan pembuatan dan pemeliharaan produk perangkat lunak secara sistematis,

termasuk pengembangan dan modifikasinya, yang dilakukan pada waktu yang tepat dan dengan mempertimbangkan faktor biaya.

Tujuan perancangan perangkat lunak adalah untuk memperbaiki kualitas produk perangkat lunak, meningkatkan produktivitas, serta memuaskan teknisi perangkat lunak.

Produk perangkat lunak adalah perangkat  lunak yang digunakan oleh berbagai pengguna, bukan untuk pengguna pribadi.

♦  Hal-hal yang perlu diperhatikan dalam pengembangan sebuah produk perangkat lunak :

•       kebutuhan dan batasan-batasan yang diinginkan pengguna harus ditentukan dan dinyatakan secara tegas,

•       produk perangkat lunak harus dirancang sedemikian rupa sehingga mampu mengakomodasi paling tidak kepentingan tiga pihak berikut : pelaksana implementasi, pengguna, dan pemelihara produk,

•       penulisan  source code  harus dilakukan dengan hati-hati dan senantiasa melalui tahap uji,

•       dilengkapi dengan dokumen-dokumen pendukung seperti : prinsip pengoperasian, user’s manual, instruksi instalasi, dokumen pemeliharaan,

•       menyiapkan bantuan pelatihan.

PemastianKualitasPerangkatLunak(software quality assurance) adalah aktivitas yang berlangsung selama pembangunan perangkat lunak dalam menjaga kualitas perangkat lunak

Kualitas Perangkat Lunak :

Kesesuaian dengan tuntutan fungsional dan kinerja yang dinyatakan secara eksplisit, standar pengembangan terdokumentasi dan ciri implisit yang diharapkan dari semua Perangkat lunak yang dikembangkan secara profesional

Tiga hal penting dari definisi kualitas:

• Tuntutan perangkat lunak (software requirement) adalah dasar dari pengukuran kualitas
• Standard yang digunakan menentukan sejumlah kriteria yang menunjukkan bagaimana suatu perangkat lunak direkayasa
•  Ada sejumlah tuntutan implisit  yang tetap tidak terungkap, tetapi tetap perlu diperhatikan

Faktor-faktor kualitas:

• Barry Boehm, 1975:portability, reliability, efficiency, human engineering, understandibility, modifiability, and testability
•  Carlo Ghezziet. al., 1991: correctness, reliability, robustness, performance, user friendliness, verifiability, maintainability, reusability, portability, understandibility, interoperability, productivity, timeliness, and visibility

HUBUNGAN PEMELIHARAAN PERANGKAT LUNAK BILA DI TINJAU DARI SIKLUS PENGEMBANGAN PERANGKAT LUNAK

Pemeliharaan perangkat lunak jika ditinjau dari daur siklus pengembangan perangkat lunak dapat dikelompokkan sebagai berikut:

·         Perluasan dan analisis merupakan perwujudan kembali dari fase analisis pada daur siklus pengembangan

·         Pembenaran merupakan perwujudan kembali fase analisis, perencanaan dan penerapan

Aktifitas pemeliharaan yang pertama terjadi karena asumsi yang salah pada saat uji coba yaitu kesalahan-kesalahan tersembunyi pada perangkat lunak yang cukup besar.

BUATLAH PROGRAM SEDERHANA( MISALNYA MENGHITUNG LUAS SEGI TIG,PERSEGI PANJANG,DLL), LALU UJILAH PROGRAM TERSEBUT DENGAN MENGGUNAKAN TEKNIK PENGUIAN PERANGKAT LUNAK YG ANDA KETAHUI !!

a. Label1, Caption = Alas
b. Label2, Caption = Tinggi
c. Label3, Caption = Luas

d. Textbox1, Name = txt_alas
e. Textbox2, Name = txt_tinggi
f. Textbox3, Name = txt_luas
g. Command Button1, Name = cmd_proses; Caption = Proses
h. Command Button2, Name = cmd_close; Caption = Close

3. Deklarasi data dengan coding sbb:

Dim alas As Double 'tipe data variabel alas adalah double
Dim tinggi As Double 'tipe data variabel tinggi adalah double
Dim luas As Double 'tipe data variabel luas adalah double

4. Membuat coding cmd_proses

Private Sub cmd_proses_Click()
alas = txt_alas.Text 'variabel alas mengambil nilai dari textbox alas
tinggi = txt_tinggi.Text 'variabel tinggi mengambil nilai dari textbox tinggi
luas = 0.5 * alas * tinggi 'rumus luas segitiga
txt_luas.Text = luas 'memasukkan textbox luas ke dalam nilai luas
End Sub

5. Membuat coding cmd_close

Private Sub cmd_close_Click()
End
End Sub

a. Pseudocode Luas Segitiga :

a. Mulai

b. Berikan variabel a  untuk alas

c. Berikan variabel t untuk tinggi

d. Berikan variabel L untuk luas

c. Hitung Luas Segitiga dengan rumus ½ a.t

d. Tampilkan Luas Segitiga

e. Selesai

b.   Algoritma Luas Segitiga :

a.        mulai

b.       tentukan variabel (alas,tinggi,Luas)

c.        readln(alas,tinggi)

d.        Luas := ½ * (a * t)

e.       write(luas)

f.         selesai

c. Flowchart Luas Segitiga ;

 

d. Contoh Source Program Luas Segitiga     (C++)