isi makalah fahrul.docx

Upload: fahrul-arul

Post on 07-Jul-2018

217 views

Category:

Documents


0 download

TRANSCRIPT

  • 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.

  • 8/19/2019 isi makalah fahrul.docx

    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

  • 8/19/2019 isi makalah fahrul.docx

    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

  • 8/19/2019 isi makalah fahrul.docx

    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

  • 8/19/2019 isi makalah fahrul.docx

    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

  • 8/19/2019 isi makalah fahrul.docx

    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.

  • 8/19/2019 isi makalah fahrul.docx

    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/19/2019 isi makalah fahrul.docx

    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

  • 8/19/2019 isi makalah fahrul.docx

    9/12

    lunak yang adaptif, di mana perubahan dilakukan untuk

    mengembangkan elemen#elemen proses yang memperkenalkan

    kesalahan tersebut.

  • 8/19/2019 isi makalah fahrul.docx

    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*

  • 8/19/2019 isi makalah fahrul.docx

    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.

  • 8/19/2019 isi makalah fahrul.docx

    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.