isi makalah fahrul.docx

8/19/2019 isi makalah fahrul.docx

1/12

BAB II

(PEMBAHASAN)

2.1. Kajian Perangkat Lunak

Kajian perangkat lunak adalah suatu “filter” bagi proses

rekayasa perangkat lunak, yaitu kajian yang diterapkan pada

berbagai titik selama pengembangan perangkat lunak dan

berfungsi untuk mencari kesalahan yang kemudian akan

dihilangkan. Freedmandan Weinberg menyatakan bahwa kajianperlu dilakukan. Kerja teknis membutuhkan pengkajian seperti

pensil yang membutuhkan enghapus. !erbuat kesalahan adalah

hal yang sangat manusiawi. "lasan kedua kita memerlukan kajian

teknis adalah bahwa meskipun manusia sangat jeli dalam melihat

kesalahan mereka sendiri, cenderung masih dapat ditemukan

kesalahan yang akan teramati oleh orang lain. "da banyak tipe

kajian yang berbeda#beda yang dapat dilakukan sebagai bagian dari

rekayasa perangkat lunak. $asing#masing memiliki tempatnya

sendiri. resentasi desain perangkat lunak kepada pendengar yang

merupakan pelanggan, manajemen, dan staf teknik, adalah sebuah

bentuk kajian.

%&&& 'tandard (ictionary of &lectrical and &lectronics )erms

mendefinisikan cacat sebagai “suatu anomali produk.” (efinisi

untuk kesalahan adalah *

+a -acat pada sebuah perangkat keras atau komponen contohnya,

hubungan pendek atau kawat putus.


2/12

+b langkah, proses, atau definisi data yang salah pada sebuah

program komputer. (alam pemakaian umum, bentuk “error” dan

“bug” digunakan untuk mcngekspresikan arti tersebut.

)ujuan utama kajian teknis formal adalah untuk menemukan

kesalahan

selama proses, sehingga mereka benar#benar sudah tanpa cacat

setelah dilepas kepada pemakai akhir. Keuntungan utama kajian

teknis formal adalah penemuan kesalahan sejak awal sehingga

tidak berlanjut ke langkah selanjutnya dalam proses perangkar

lunak. )eknik kajian formal dapat memperlihatkan sampai sekitar

/0 persen efektif. dalam mengungkap kekurangan dalam desain.

(engan mendeteksi dan menghilangkan suatu persentase

kesalahan yang cukup besar tersebut, maka secara substansial

proses kajian akan mengurangi biaya langkah#langkah selanjumya

dalam fase pengembangan dan pemeliharaan.

$odel penguatan caca1 dapat digunakan untuk

menggambarkan pemunculan dan pendeteksian kesalahan selama

desain awal, desain detail, dan langkah pengkodean proses

rekayasa perangkat lunak. 'elama langkah tersebut kesalahan

dimunculkan secara kurang hati#hati. Kajian dapat gagal

mengungkap kesalahan yang dimunculkan sebelumnya dan

kesalahan pada langkah berikutnya, sehingga membuahkan

sejumlah kesalahan yang terlewatkan.

setiap langkah pengujian diasumsikan mengungkap dan

membetulkan 02 persen dari semua kesalahan yang masuk tanpa


3/12

mengenali kesalahan yang baru +asumsi yang optimistik. 'epuluh

kesalahan desain pendahuluan dikuatkan sampai 34 kesalahan, sebelum

pengujian dimulai. (ua belas cacat laten dilepaskan ke lapangan.

mengandaikan kondisi yang sama kecuali bahwa kajian desain dan kode

dilakukan sebagai bagian dari setiap langkah pengembangan. (alam

kasus ini, 52 kesalahan desain pendahuluan awal dikuatkan sampai 64

kesalahan sebelum pengujian dimulai. 7anya tiga cacat laten yang ada.

(engan melihat lagi biaya relatif yang berhubungan dengan penemuan

dan pembetulan kesalahan, biaya keseluruhan +dengan dan tanpa kajian

untuk contoh hipotetis dapat dibuat. !iaya total untuk pengembangandan pemeliharaan pada saat kajian dilakukan adalah 5*8 kali lebih sedikit

!ila tidak ada kajian yang dilakukan.

2.2 Kajian Teknik Forma

Kajian teknis formal (FTR) adalah aktivitas jaminan kualitas perangkat lunak yang

dilakukan oleh perekayasa perangkat lunak. Tujuan FTR adalah

(1) menemukan kesalahan dalam fungsi, logika, atau implementasinya dalam

berbagai representasi perangkat lunak.

() membuktikan bah!a perangkat lunak di ba!ah kajian memenuhi syarat.

(") memastikan bah!a perangkat lunak disajikan sesuai dengan standar yang sudah

ditentukan sebelumnya.

(#) men$apai perangkat lunak yang dikembangkan dengan $ara yang seragam.

(%) membuat proyek lebih dapat dikelola. &ebagai tambahan, FTR berfungsi sebagai

dasar pelatihan yang memungkinkan perekayasa yunior mengamati berbagai

pendekatan yang berbeda terhadap analisis perangkat lunak, desain, dan

implementasi.

FTR juga berfungsi untuk mengembangkan ba$kup dan kontinuitas karena sejumlah

orang mengenal baik bagian'bagian perangkat lunak yang tidak mereka ketahui


4/12

sebelumnya. FTR sebenarnya merupakan suatu kelas kajian yang men$akup

!alkthrough, pemeriksaan, kajian round'robin, dan penilaian teknis kelompok ke$il

lainnya terhadap perangkat lunak.

Tanpa memperhatikan fonnat FTR yang dipilih, setiap penemuan kajian harus

mematuhi batasan'batasan berikut ini

1.ntara tiga dan lima orang (khususnya) harus dilibatkan dalam kajian*

.+ersiapan a!al hams dilakukan, tetapi !aktu yang dibutuhkan harus tidak ebih dari

dua jam dari kerja bagi setiap person.

".durasi pertemuan kajian harus kurang dari dua jam.

-engan batasan tersebut jelas bah!a FTR berfokus pada bagian tertentu (dan ke$il)

dari keseluruhan bagian perangkat lunak. ontohnya, selain melakukan kajian

terhadap desain keseluruhan, !alkthrough juga dilakukan untuk setiap modul atau

kelompok ke$il modul. -engan fokus yang ebih sempit, FTR memiliki kemungkinan

yang ebih tinggi untuk menemukan kesalahan. Fokus FTR adalah pada produk kerja,komponen perangkat lunak (missal spesi/kasi kebutuhan, desain modul detail, daftar

kode sumber untuk suatu modul). ndividu yang telah mengembangkan produk kerja ,

produser memberitahu pimpinan proyek bah!a produk kerja telah selesai dan

membutuhkan kajian. +impinan proyek mengontak pimpinan kajian yang

mengevaluasi produk kerja untuk kesiapan, pembuatan salinan, dan

mendistribusikannya kepada dua atau tiga pengkaji sebagai persiapan a!al. 0asing'

masing pengkaji diharapkan menghabiskan !aktu antara satu dan dua jam unruk

mengkaji produk kelja tersebut, membuat $atatan, dan menjadi terbiasa dengan kerja

tersebut. &e$ara kongkuren, pimpinan kajian juga mengkaji produk kelja tersebut dan

membuat agenda untuk pertemuan kajian, di mana se$ara khusus telah dijad!alkan

unmk hari selanjutnya. +enemuan kajian dihadiri oleh pimpinan kajian, pengkaji, dan


5/12

produser. &alah satu dari pengkaji berperan sebagai pen$atat, yaitu seseorang yang

men$atat (dalam tulisan) semua masalah penting yang mun$ul selama pengkajian

+ada akhir kajian, semua peserta FTR yang hadir harus memutuskan apakah akan (1)

menerima produk kerja tanpa modi/kasi lebih lanjut, () menolak produk kerja

sehubungan dengan kesalahan yang ada (sekali dibetulkan, kajian lain harus

dilakukan), atau (") menerima produk kerja se$ara sementara (kesalahan minor telah

terjadi dan harus dikoreksi, tetapi kajian tambahan akan diperlukan). Keputusan

kemudian dibuat. &emua peserta FTR melengkapinya dengan tanda tangan yang

menunjukkan partisipasi mereka dalam kajian serta persetujuan mereka terhadap

penemuan tim kajian.

&elama FTR, seorang pengkaji (pen$atat) se$ara aktif men$atat semua

masalah yang sudah dimun$ulkan, yang kemudian dirangkum pada akhir pertemuan

sehingga dihasilkan da/ar masalah kajian. &ebagai tambahan, laporan rangkuman

kajian yang sederhana telah diselesaikan di mana rangkuman kajian merupakan

ja!aban dari tiga pertanyan berikut

1. pa yang dikaji

. &iapa yang melakukan

". +enemuan apa yang dihasilkan dan apa kesimpulannya

2aporan rangkuman kajian berupa formulir satu halaman -aftar masalah kajian

mempunyai dua tujuan (1) mengidenti/kasi area masalah pada produk, dan ()

berfungsi sebagai da/ar item kegiatan yang menjadi petunjuk bagi produser saat

koreksi dilakukan. -aftar masalah biasanya di1arnpirkan pada laporan.

3erikut ini serangkaian pedoman minimum untuk kajian teknis formal


6/12

1. Kajian produk, bukan produser. FTR melibatkan manusia dan ego. 3ila dilakukan

se$ara tepat, FTR memberi rasa hangat kepada semua pengkaji didalam melakukan

penyelesaian. 3ila dilakukan dengan tidak tepat, FTR dapat menimbulkan gesekan.

&emua kesalahan harus ditunjukkan dengan lembut

. 0enetapkan agenda dan menjaganya. 0alapetaka kun$i dari pertemuan

adalah semua bentuk pergeseran.

". 0embatasi perdebatan dan bantahan.

#. 0enetapkan area masalah, tetapi tidak tergoda untuk menyelesaikan setiap

masalah yang di$atat.

%. 0engambil $atatan rertulis. Kadang'kadang baik juga bagi pen$atat untuk

membuat $atatan pada !hiteboard, sehingga penyusunan kata dan prioritasnya

dapat dinilai oleh pengkaji lain pada saat infonnasi di$atat.

4. 0embatasi jumlah peserta dan me!ajibkan persiapan a!al

5. 0engalokasikan sumber'sumber daya dan jad!al !aktu untuk F TR

6. 0elakukan pelatihan bagi semua pengkaji

17. 0engkaji kajian a!al nda. Tanya ja!ab dapat menguntungkan dalam rangka

men$ari masalah dengan proses kajian itu sendiri.


7/12

2.! Pen"ekatan Forma ter#a"a$ S%A

kualitas perangkat lunak merupakan tugas setiap anggota &8 dan bah!a

kualitas dapat di$apai melalui analisis, desain, pengkodean, dan pengujian yang baik,

seperti juga melalui aplikasi kajian teknis formal, strategi pengujian bertingkat,

kontrol dokumentasi perangkat lunak yang lebih baik, dan perubahan yang dikenakan

kepadanya, serta aplikasi standar pengembangan perangkat lunak yang diterima.

+ada lebih dari dua dekade, segmen komunitas rekayasa perangkat lunak yang

ke$il tetapi vokal telah memperlihatkan bah!a dibutuhkan suatu pendekatan yang

lebih fonnal terhadap jaminan kualias perangkat lunak. -apat juga diperlihatkan

bah!a program komputer merupakan objek matematika. &intaksis dan semantik yang

teliti dapat dide/nisikan untuk setiap bahasa pemrograman, dan pendekatan yang

tepat dan mirip terhadap spesi/kasi kebutuhan perangkat lunak. juga dapat diperoleh.

&ekali model kebutuhan (spesi/kasi) telah dihadirkan dengan $ara yang tepat, maka

pembuktian matematis terhadap kebenarannya dapat diaplikasikan untuk

menunjukkan bah!a program menyesuaikan diri se$ara tepat dengan spesi/kasinya.

9saha untuk membuktikan kebenaran program bukan me'rupakan hal baru. -ijkstradan 2inger et alsatu di antara banyak yang lainnya, menganjurkan pembuktian

kebenaran program dan menghubungkannya dengan pemakaian konsep pemrograman

terstruktur . &ekarang ini, telah diusulkan sejumlah pendekatan yang berbeda'beda

terhadap pembuktian formal dari kebenaran.


8/12

2.&.'aminan Kuaita Statitik (S%A)

9aminan kualitas statistik mencerminkan tren yang sedang

tumbuh di seluruh industri untuk menjadi lebih kuantitatif terhadap

kualitas. ada perangkat lunak, jaminan kualitas statistik

mengimplikasikan langkah#langkah berikut ini*

5. %nformasi tentang cacat perangkat lunak dikumpulkan dandipilah#pilahkan.

6. melakukan suatu usaha untuk menelusuri masing#masing cacat

sampai ke penyebab pokoknya +misalnya ketidak#sesuaian dengan

spesifikasi, kesalahan desain, pelanggaran standar, buruknya

komunikasi dengan pelanggan.

8. (engan mengglnakan prinsip areto +:2 persen cacat dapat

ditelusuri sampai 62 persen dari semua kemungkinan penyebab,

mengisolasi yang 62 persen tersebut +;ital few

4. 'ekali penyebab ;ital few telah diidentifikasi, beralih untuk

membetulkan masalah yang menyebabkan cacat.

Konsep yang sederhana itu merepresentasikan suatu langkah

penting menuju penciptaan sebuah proses rekayasa perangkat


9/12

lunak yang adaptif, di mana perubahan dilakukan untuk

mengembangkan elemen#elemen proses yang memperkenalkan

kesalahan tersebut.


10/12

, adalah penyebab ;ital few

yang mencapai 08 persen dari semua kesalahan. Aamun perlu

dicatat bahwa %&', &(>, ?), dan &(?, hanya akan diseleksi sebagai

penyebab ;ital few jika terjadi kesalahan yang serius. 'ekali

penyebab ;ital few ditentukan, organisasi pengembang perangkat

lunak dapat mulai melakukan tindakan yang bersifat korektif.

-ontohnya, untuk mengkoreksi $--, pengembang perangkat lunak

akan mengimplementasi teknik spesifikasi aplikasi yang terfasilitasi+!ab ll untuk mengembangkan kualitas komunikasi dan spesifikasi

pelanggan. , pengembang mungkin

mernerlukan peranti -"'& untuk pemodelan data sena melakukan

kajian desain data yang lebih ketat. ada waktu penyebab ;ital few

dikoreksi, calon baru dimunculkan ke puncak susunan.

(alam hubungannya dengan pengumpulan infonnasi cacat,

pengembang

perangkat lunak dapat menghitung indeks kesalahan +error indeB #

&5 + bagi masing#masing langkah utama dalam proses rekayasaperangkat lunak C%&&34D. 'etelah analisis, desain, pengkodean,

pengujian, dan peluncuran, dikumpulkan

data#data berikut ini*


11/12

&i E jumlah kesalahan total yang ditemukan selama langkah ke i

dalam proses rekayasa perangkat lunak

'iE jumlah kesalahan serius

$i E jumlah kesalahan moderat

)i E jumlah kesalahan minor

' E ukuran produk +?-, pemyataan desain, halaman

dokumentasi pada langkah ke i

Ws, Wm, Wt E faktor pembobotan untuk kesalahan serius,

moderat, dan sepele, di mana harga yang disetujui adalah Ws E52,Wm E 8, Wt E 5. Faktor pembobotan untuk masing#masing fase

harus menjadi lebih besar pada saat pengembangan berjalan. 7al

ini mengBmtungkan sebuah organisasi yang berhasil menemukan

kesalahan pada saat awal.

ada masing#masing proses rekayasa perangkat lunak, indeks fase,

?,

dihitung sebagai*

%iEWs+'iG&i H Wm+$iG&iHWt+)iG&i

%ndeks kesalahan +&% dihimng dengan menghitung pengaruh

kumulatif atau pengaruh masing#masing %. Faktor pembobotan

yang ditemukan kemudian di dalam proses rekayasa perangkat

lunak lebih berat daripada faktor yang ditemukan pada saat lebih

awal.

&% E &+i B %i,G'

E +%5 H 6%5, H8%8 H i%iG'

%ndeks kesalahan dapat digunakan dalam hubungannya dengan

informasi yang

dikurnpulkan dalam )abel diatas untuk mengembangkan sebuah

indikasi keseluruhan dalam kualitas perangkat lunak.


12/12

"plikasi dari '@" statistik dan prinsip areto dapat dirangkum

dalam sebuah kalimat tunggal* Iunakan waktu "nda untuk

memusatkan perhatian pada hal#hal yang sungguh#sungguh berarti,tetapi yang pertama#tama yakinlah bahwa "nda memahami apa

yang sungguh#sungguh berarti itu. elaksana industri yang

berpengalaman setuju bahwa kebanyakan cacat yang benar#benar

sulit, dapat ditelusuri ke dalam jumlah terbatas akar penyebab.

Kenyataannya, sebagian besar pelaksana memiliki perasaan intuitif

terhadap penyebab “nyata” dari cacat perangkat lunak, tetapi

beberapa telah menggunakan waktunya untuk mengumpulkan data

yang mendukung perasaan mereka itu. (engan melakukan langkah

dasar dari '@" statistik, penyebab ;ital few untuk cacat dapat

diisolasi dan kemudian dilakukan koreksi yang memadai. (iskusi

yang komprchensif tentang '@" statistik tidak tennasuk dalam

ruang lingkup buku ini. embaca yang tcrtaBik pada lingkup

tersebut harus melihat

C'-7:/D, CK"30D, atau CK"A30D.

isi makalah fahrul.docx

Documents