Blog Tentang Informasi Tutorial Desain Web Dan Info Terkini

REKAYASA PERANGKAT LUNAK

METODE DESAIN

1.1 DESAIN DATA

Desain data adalah aktivitas pertama ( dan beberapa sering mengatakan yang terpenting ) dari empat aktivitas desain yang dilakukan selama rekayasa perangkt lunak.
Proses desain data dirangkum oleh Wasserman[WAS80]:
Aktivitas utama selama desain data adalah memilih representasi logis dari objek data (struktur data) yang didefinisikan selama tahap definisi persyaratan dan spesifikasi. Proses pemilihan dapat melibatkan analisis algoritmik terhadap struktur alternative untuk menentukan desain yang pling efisien atau hanya melibatkan penggunaan serangkaian modul (sebuah paket) yang memberikan operasi yang diperlukan pada beberapa reprsentsi suatu objek.
Wasserman [WAS80] mengusulkan serangkaian prinsip yang dapat digunakan untuk menentkan dan mendesain data. Serangkaian prinsip itu adalah sebagai berikut;
1. Prinsip analisis sistematik yang di apliksikan pada fungsi dan perilaku seharusnya diaplikasikan juga pada data.
2. Semua struktur data dan operasi yang akan dilakukan pada masing – masing struktur data harus diidentifikasi.
3. Kamus data harus dibangun dan digunakn untuk menentukan baik data maupun desain program.
4. Keputusan desain data tingkat rendah harus ditunda sampai akhir proses desain.
5. Representasi struktur data hanya boleh diketahui oleh modul – modul yang harus menggunkan secara langsung data yang didisikan didalam struktur tersebut.
6. Pustaka struktur data danoperasi yang digunakan yang dapat diaplikasikan pada struktur data tersebut harus dikembangkan.
7. Desain perangkat lunak dan bahasa pemerograman harus mendukung spesifikasi dan realisasi dari tipe – tipe data abstrak.
1.2 DESAIN ARSITEKTUR
Desain arsitektur adalah untuk mengembangkan struktur program modular dan merepresentasikan hubungan control antar modul.
Metode desain yang disajikan pada bagian ini mendorong prekayasa perangkat lunak untuk berkosentrasi pada desain arsitektur sebelum mencemaskan masalah perpipaan.

1.2.1 KONTRIBUTOR
Desain arsitektur berakar dari konsep esain yang lebih awal yang menekankan pada modularitas [DEN73], desain topdown[WIR71],dan pemerograman terstruktur[DAH72,LIN70]. Steven, Myers, dan Constantine [STE74], adalah perintis desain perangkat lunak yang didasarkan pada aliran data melalui sebuah sistem.

1.2.2 AREA APLIKASI
Masing – masing metode desain mempunyai kelemahan dan kelebihan. Factor seleksi yang penting untuk suatu metode desain adalah luasnya apliksi dimana aplikasi dapat di aplikasikan. Desain berorientasi pada alira dat dapat menyetujui rentang area aplikasi yang luas.

1.3 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. Trnsisi 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.
Pada bagian ini kita akan mengamati 2 tipe aliran.
1.3.1 ALIRAN TRANSFORMASI
Informasi memasuki system bersama dengan jalur yang mentransformasikan data eksternal kedalam bentuk internal dan akan didefinisikan sebagai aliran masuk. Pada inti perangkat lunak terjadi transisi. Data yang masuk dilewatkan melalui pusat transformasi dan mulai bergerak sepanjang jalur yang sekarang mengarah keluar dari perangkat lunak. Data yang mengalir disepanjang jalur – jalur disebut aliran keluar. Keseluruhan aliran data terjadi dalam cara yang berurutan dan mengikuti satu atau hanya beberapa jalur”garis lurus”. Bil segmen dari diagram aliran data menunjukkan karakteristik tersebut, maka disitu ada aliran transformasi.
1.3.2 ALIRAN TRANSAKSI
Aliran transaksi ditandai dengan pergerakan data sepanjang jalur masuk yang mengkonversi informasi dunia eksternal kedalam suatu transaksi. Transaksi tersebut dievaluasi, dan berdasarkan nilai, aliran sepanjang satu daribeberapa jalur aksi diinisiasi. Pusat aliran informasi dari mana banyak jalur aksi berasal disebut pusat transaksi.

1.4 PEMETAAN TRANSFORMASI
Pemetaan transformasi adalah serangkaian langkah desain yang mengijinkn sebuah DFD dengan karakteristik aliran transformasi untuk dipetakan ke dalam template yang telah ditentukan sebelumnya untuk struktur program.
Langkah – langkah desain pemetaan transformasi:
1 kajilah model sistem fundamental.
2 Kajilah dan saringlah diagram aliran data untuk perangkat.
3 Tentukan apakah DFD memiliki karakteristik aliran transformasi dan transaksi.
4 Isolasi pusat transformasidengan mengkhususkan batas aliran masuk dan keluar.
5 Lakukan”pemfaktoran tingkat pertama”
6 Lakukan”pemfaktoran tingkat kedua”
7 Saringlah struktur program iterasi pertama dengan menggunakan heuristic desain bagi kualitas perangkat lunak yang telah ditingkatkan.

1.5 PEMETAAN TRANSAKSI
Pada banyak aplikasi perangkat lunak, item data tunggal memicu satu atau sejumlah aliran informasi yang mempengaruhi suatu fungsi yang diimplikasikan oleh pemicu item data. Item data yang disebut transaksi, dan karakteristik alirannya yang terkait.
Langkah – langkah desain pemetaan transaksi:
1. Kaji model sistem fundamental.
2. Kaji dan saring diagram aliran data untuk perangkat lunak.
3. Tentukan apakah DFD memiliki karakteristik aliran transformasi atau transaksi.
4. Identifikasi pusat transaksi dan karakteristik aliran sepanjang masing – masing jalur aksi.
5. Petakan DFD pada sebuah struktur program yang sesuai dengan pemerosesan transaksi.
6. faktorkan dan saringlah struktur transaksi dan struktur masing – masing jalur aksi.
7. saringlah strutur program iterasi pertama dengan menggunakan heuristic desain untuk kualitas perangkat lunak yang dikembangkan.

1.6 PASCA PEMEROSESAN DESAIN
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:
• Mengembangkan narasi pemerosesan untuk masing – masing modul.
• Menyediakan deskripsi interface untuk masing – masing modul.
• Menentukan struktur data local dan global.
• Mencatat semua batasan desain.
• Mengkaji desain.
• Mempertimbangkan “optimasi” (bila perlu dan dibenarkan).

1.7 OPTIMASI DESAIN ARSITEKTUR
Desainer perangkat lunak harus memperhatikan perkembangan representasi perangkat lunak yang akan memenuhi semua fungsi dan persyaratan kinerja dan penerimaan jasa berdasarkan pengukuran desain kualitas. Oleh karena itu cukup beralasan untuk mengusulkan pendekatan berikut ini untuk perangkat lunak kinerja – kritis.
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 “time hot” 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.

1.8 DESAIN INTERFACE
Desain interface memfokuskan diri pada 3 area perhtian:
1. Desain interface antara modul – modul perangkat lunak.
2. Desain interface antara perangkat lunak dan produser dan konsumen informasi bukan manusia lainnya (yakni entitas eksternal lainnya).
3. Desain interface antara pemakai dan komputer.


1.10.4 DESAIN INTERFACE PEMAKAI INTERNAL DAN EKSTERNAL
Desain interface program internal, yang kadang disebut desain interface intermodular, dikendalikn oleh data yang harus mengalir diantara modul – modul dan karakteristik bahasa pemerograman dimana perangkat lunak akan diimplementasikan. Secara umum, model analisis berisi banyak informasi yang dibutuhkan bagi desain interface intermodular.
Desain interface eksternal dimulai dengan evaluasi terhadap masing – masing entitas eksternal yang di representasikan pada DFD model analisis. Persayaratan data dan kontrol dari entitas eksternal ditentukan, dan dirancang interface eksternal yang sesuai. Desain interface eksternal bagi masing – masing sensor didasarkan item kontrol dan data spesifik yang dibutuhkan untuk sensor tersebut.
Baik desain interface eksternal maupun internal harus dirangkai dengan validasi data dan algoritma penanganan kesalahan dalam sebuah modul. Karena efeksamping menyebar melalui interface program, maka penting untuk mengecek semua aliran data dari modul ke modul (atau ke dunia luar) untuk memastikan bahwa data sesuai dengan batas yang telah ditentukan selama analisis persyaratan.

1.8.2 DESAIN INTERFACE PEMAKAI
Desain interface pemakai berkaitan dengan study terhadap manusia, juga terhadap isu – isu teknologi. Siapakah para pemakainya? Bagaimana pemakai belajar berinteraksi dengan sistem berbasis komputer yang baru? Bagaimana pemakai menginterpresentasikan informasi yang dihasilkanoleh sistem? Apakah yang diharapkan dari sistem tersebut? Itu hanya sebagian kecil dari banyak pernyataan yang harus diajukan dan dijawab sebagai bagian dari desain interface pemakai.

1.11 DESAIN INTERFACE MANUSIA-MESIN
1.11.1 MODEL – MODEL DESAIN INTERFACE
Ada empat model yang berbeda pada saat manusia-komputer/ human-komputer interface (HCL) akan didesain. Perekayasa perangkat lunak menciptakan sebuah model desain, perekayasa manusia ( atau 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 [RUB88].
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”[SHN87]. 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.

1.11.2 PEMODELAN DAN ANALISIS TUGAS
Pemodelan dan analisis tugas dapat diaplikasikan untuk memahami tugas – tugas yang sedang dilakukan oleh banyak orang (jika menggunakan pendekatan manual atau semi-otomatis) dan kemudian memetakannya kedalam serangkaian tugas yang mirip (tetapi tidak bener – benar identik) yang diimplementasikan dalam konteks HCI.
Perekayasa harus lebih dahulu menetapkan dan mengklarifikasi tugas – tugas. Salah satu pendekatan adalah elaborasi stepwise. Sebagai contoh, kita asumsikan sebuah perusahaan perangkat lunak kecil perlu membangun sistem computer-aided secara eksplisit untuk desainer interior.
Sekali tugas atau aksi yang ditentukan, maka desain interface dimulai. Langkah pertama dalam proses desain interface [NOR86] dapat dilaksanakan dengan menggunakan pendekatan berikut:
1. Tentukan tujuan untuk tugas itu.
2. Petakan masing – masing tujuan untuk serangkaian aksi khusus.
3. tentukan urusan aksi saat tindakan akan dieksekusi pada tingkat interface.
4. indikasi keadaan sistem
5. tentukan mekanisme kontrol.
6. perlihatkan bagaimana mekanisme kontrolmempengaruhi keadaan sistem.
7. indikasi bagaimana pemakai menginterpretasi keadaan sistem dari informasi yang diberikan melalui interface.

1.11.3 MASALAH – MASALAH DESAIN
Pada saat interface pemakai berkembang, hampir muncul empat masalah desain umum, yaitu: waktu respon sistem, fasilitas help pemakai, penanganan informasi kesalahan, dan pelabelan perintah.
waktu respon sistem mempunyai dua karakteristik penting: panjang dan variabilitas. Bila jarak (panjang) eaktu untuk respon sistem terlalu panjang, stres dan frustasi pemakai akan menjadi hal yang dapat dihindari. Tetapi, waktu respon yang sangat pendek juga dapat menggangu bila pemakai ditinggak interface.
Variabilitas mengacu pada penyimpangan terhadap waktu respon rata – rata, dan dalam banyak hal variabilitas lebih penting dari karakteristik waktu respon.
Ada dua tipe fasilitas help yang berbeda: integrated dan add-on[RUB88].fasilitas help integrated didesain kedalam perankat lunak sejak awal.peralatan itu sering menjadi sensitif konteks, yang memungkinkan pemakai memilih topik – topik yang relevan dengan kegiatan yang sedang dilakukan. Fasilitas help add-on ditambahkan ke perangkat lunak seetelah sistem tersebut dibangun.dalam banyak hal fasilitas tersebut benar – benar
Merupakan manual pemakai on-linebdengan kapabilitas query yang terbatas. Pemakai mungkin harus mencari daftar yang berisi ratusan topik untuk mendapatkan pedomn yang sesuai, sering membuat banyak kesalahan dan menerima informasi yang tidak relevan.
Ada sejumlah masalah desain [RUB88] yang harus ditekankn bila fasilitas help dipertimbangkan:
• Apakah help akan dapat diperoleh untuk smua fungsi sistem dan pada keseluruhan waktu selama interaksi sistem? Pilihan mencakup help hanya untuk suatu sub-kumpulan dari semua fungsi dan aksi, dan help untuk semua fungsi.
• Bagaimana pemakai memperoleh help? Pilihan meliputi menu help, kunci fungsi khusus, dan sebuah perintah help.
• Bagaimana help akan direpresentasikan? Pilihan mencakup sebuah jendela terpisah, reperensi untuk dokumen yang dicetak (kurang ideal), dan satu atau dua baris usulan yng dibuat pada suatu lokasi layar yang tetap.
• Bagaimana pemakai kembali keinteraksi normal?pilihan mencakup tombol return yang ditanpilkan pada layar dan kunci fungsi atau urutan kontrol.
• Bagaimana informasi help distruktur? Pilihan mencakup struktur “datar” dimana semua informasi diakses melalui sesuatu kata kunci, hirarki informasi bertingkat yang memberikn detail tambahan pada saat pemakai melangkah kedalam struktur tersebut, dan kegunaan hiperteks.
Secara umum setiap pesan atau peringatan kesalahan yang dihasilkan oleh sebuah sistem intraktif harus memiliki karakteristik sebagai berikut:
• Pesan harus menggambarkan masaalah dalam istilah yang dapat dipahami oleh pemakai.
• Pesan harus memberinasehat intruktif untuk membetulkan kesalahan.
• Pesan harus mengindikasikan kosekuensi negatif dari kesalahan.
• Pesan harus disertai oleh isarat visual atau audibel.
• Pesan harus tidak “menghakimi”, yaitu penyusunan kata tidak boleh menyalahkan pemakai.
Ada sejumlah isu desain yang muncul pada saat perintah diberikan sebagai sebuah mode interaksi:
• Apakah setiap pilihan menu akan memiliki perintah yang sesuai?
• Bagaimanakah bentuk yang akan diambil oleh perintah tersebut?
• Seberapa sulitkah mempelajari dan mengimgat perintah – perintah tersebut?
• Dapatkah dikostumasi atau disingkat oleh pemakai?

1.11.4 PERANTI IMPLEMENTASI
Proses desain interface pemakai adalah iteratif; yaitu, sebuah model desain dibuat,diimplementasikan sebagai sebuah prototipe, diuji oleh pemakai dan dimodifikasi berdasarkan pendapat mereka.
Dengan menggunakan perangkat lunak yang dikemas sebelumnya yang dapat digunakan secara langsung oleh desainer dan implementor atau pemakai interface, UIDS memberi mekanisme built-in [MYE89] untuk:
• Mengatur perangkat input.
• Memvalidasi input pemakai.
• Menangani kesalahan dan menampilkan pesan kesalahan.
• Memberi umpan balik.
• Menyediakan help dan prompt.
• Penanganan jendela dan field, scrolling pada jendela.
• Membangun koneksi antara perangkat lunak aplikasi dan interface.
• Mengisolasi aplikasi dari fungsi – fungsi managemen interface.
• Memungkinkan pemakai mengkostumasi interface.

1.11.5 EVALUASI DESAIN
Sekali prototipe interface pemakai operasional diciptakan, maka prototipe itu harus dievaluasi untuk menentukan apakah memenuhi kebutuhan pemakai.evaluasi dapat memenuhi spektrum formalitas yang terentang dari “ test drive” informal dimana seorang pemakai memberi umpan blik mendadak sampai study yang dirancang secara formal yang menggunakan metode statistik untuk mengevaluasi kuesioner yang dikerjakan oleh populasi pemakai akhir.
Bila sebuah model desain interface telah diciptakan, maka sejumlah kriteria evaluasi [MOR81] dapat diaplikasikan selama kajian desain awal:
1. Panjang dan kompleksitas spesifikasi tertulis dari sistem dan interfacenya.
2. Jumlah perintah atau aksi yang ditentukan dan jumlah rata – rata argumen per perintah atau per individual per aksi.
3. Jumlah aksi, perintah dan keadaan sistem yang diindikasikan oleh model desain, menunjukkan beban memori pada pemakai sistem.
4. Gaya interface, fasilitas help, dan protokol penanganan kesalahan memberikan suatu indikasi umum mengenai kompleksitas interface dan tingkat dimana interface akan diterima oleh pemakai.

1.12 PEDOMAN DESAIN INTERFACE
Ada tiga kategori pedoman desain HCI: interaksi umum, tampilan informasi, dan entry data.
1.12.1 INTERAKSI UMUM
Pedoman bagi interaksi umum sering melewati batasan kedalam tampilan informasi, entridata, dan kontrol sistem keseluruhan. Dengan demikian pedoman itu mencakup keseluruhan dan bila diabaikan akan menimbulkan resiko besar. Pedoman berikut berfokus pada interaksi umum:
• Konsisten
• Berikan umpan balik yang sangat berarti
• Mintalah verifikasi terhadap sembarang aksi destrutif yang signifikan
• Ijin kemudahan pembatalan sebagian besar aksi
• Kurangi jumlah informasi yang harus diingat diantara aksi – aksi
• Usahakan adanya efisiensi dalam dialog, gerakan, dan pemikiran
• Memaafkan kesalahan
• Kategorikan aktifitas menurut fungsi dan atur geografi layar secar sesuai
• Sediakan fasilitas help dan sensitif konteks
• Gunakan verbal aksi yang sederhana atau frase verbal pendek untuk menamai perintah

1.12.2 TAMPILAN INFORMASI
Bila informasi yang disajikan oleh HCI tidak lengkap, ambigu, atau tidak dapat dimengerti, makaapliksi tersebut akan gagal memenuhi kebutuhan pemakai. Infomsi “ditampilkan” dalam banyak cara yang berbeda: dengan teks, gambar dan suara; dengan penempatan, gerakan dan ukuran; dan dengan menggunakan warna, resolusi, dan bahkan penghilangan.pedoman berikut berfokus pada tampilan informasi:

• Menampilkan hanya informasi yang relevan dengan konteks yang ada
• Jangan membanjiri pemakai dengan data, gunakn format representasi yang memungkinkan asimilasi informasi yang cepat.
• Gunakan label – label yang konsisten, penyingkatan standar, dan warna yang dapat diprediksi
• Ijinkan pemakai untuk memelihara konteks visual
• Hasilkan pesan kesalahan yang berarti
• Gunakan huruf besar dan kecil, indentasi, dan pengelompokkan teks untuk membantu pemahaman.
• Gunakan jendela untuk menggolongkan tipe – tipe informasi yang berbeda
• Gunakan tampilan analog untuk mempresentasikan informasi yang lebih mudah diasimilasikan dengan bentuk representasi ini
• Pertimbangkan ketersediaan geografi layar tampilan dan gunakan secara efisien

1.12.3 INPUT DATA
Dalam banyak aplikasi, keybord menjadi medium input yang utama, tetapi mouse, digitizer, dan bahkan sistem pengenaln suara secara cepat menjadi alternatif yang efektif. Pedoman – pedoman berikut berfokus pada input data:
• Minimalkan jumlah aksi input pyang dibutuhkan dari pemakai.
• Jagalah konsistensi diantara tampilan informasi dan input data
• Ijinkan pemakai mengkostumasi input
• Interaksi harus fleksibel tetapi juga diatur kemode input yang disukai pemakai
• Non aktifkan perintah yang tidak sesuai didalam konteks aksi yang sedang berlangsung
• Biarkan pemakai mengontrol aliran interaktif
• Silakan help untuk membantu semua aksi input
• Hilangkan input “mickey mouse”





Rekayasa Perangkat Lunak, Bab 8 FRD Hal : 1
BAB 8
JAMINAN KUALITAS PERANGKAT LUNAK
Software Quality Assurance [SQA]
Jaminan kualitas perangkat lunak adalah aktivitas pelindung
yang diaplikasikan pada seluruh proses perangkat lunak.
SQA meliputi :
1. pendekatan manajemen kualitas
2. teknologi rekayasa perangkat lunak yang efektif (metode
dan peranti)
3. kajian teknik formal yang diaplikasikan pada keseluruhan
proses perangkat lunak
4. strategi pengujian multitiered (deret bertingkat)
5. kontrol dokumentasi perangkat lunak dan perubahan
6. prosedur untuk menjamin kesesuaian dengan standar
pengembangan perangkat lunak
7. mekanisme pengukuran dan pelaporan.


Kontrol Kualitas
Kontrol kualitas merupakan serangkaian pemeriksaan, kajian, dan
pengujian yang digunakan pada keseluruhan siklus pengembangan
untuk memastikan bahwa setiap produk memenuhi persyaratan
yang ditetapkan.
Konsep kunci kualitas kontrol adalah bahwa semua produk kerja
memiliki spesifikasi yang telah ditentukan dan dapat diukur
dimana kita dapat membandingkan output dari setiap proses.
Kalang (loop) menjadi penting untuk meminimalkan cacat yang
dihasilkan.
Rekayasa Perangkat Lunak, Bab 8 FRD Hal : 2



Jaminan Kualitas
Jaminan kualitas terdiri atas fungsi auditing dan pelaporan
manajemen.
Tujuan jaminan kualitas adalah :
untuk memberikan data yang diperlukan oleh manajemen untuk
menginformasikan masalah kualitas produk, sehingga dapat
memberikan kepastian & konfidensi bahwa kulitas produk dapat
memenuhi sasaran.



Biaya Kualitas
Biaya kualitas menyangkut semua biaya yang diadakan untuk
mengejar kualitas atau untuk menampilkan kualitas yang
berhubungan dengan aktivitas.
Studi tentang biaya kualitas dilakukan untuk memberikan garis
dasar bagi biaya kualitas yang sedang digunakan, untuk
mengidentifikasi kemungkinan pengurangan biaya kualitas serta
memberikan basis perbandingan yang ternormalisasi.


Biaya kualitas dapat dibagi ke dalam biaya-biaya yang dihubungkan
dengan :
a) Biaya pencegahan meliputi :
• Perencanaan
• Kajian teknis formal
• Perlengkapan pengujian
• Pelatihan
Rekayasa Perangkat Lunak, Bab 8 FRD Hal : 3


b) Biaya penilaian meliputi :
• Inspeksi in-proses dan interproses
• Pemeliharaan dan kalibrasi peralatan
• Pengujian


c) Biaya kegagalan
Biaya kegagalan adalah biaya yang akan hilang bila tidak ada cacat
yang muncul sebelum produk disampaikan kepada pelanggan.


Biaya kegagalan internal adalah
biaya yang diadakan bila kita mendeteksi suatu kesalahan dalam
produk sebelum produk dipasarkan.
Biaya kegagalan internal meliputi:
• Pengerjaan kembali
• Perbaikan
• Analisis mode kegagalan


Biaya kegagalan eksternal adalah
biaya yang berhubungan dengan cacat yang ditemukan setelah
produk disampaikan kepada pelanggan.


Biaya kegagalan eksternal meliputi:
• Resolusi keluhan
• Penggantian dan pengembalian produk
• Dukungan help line
• Kerja jaminan


Biaya relatif mendapatkan dan membetulkan cacat bertambah
secara dramatis pada saat kita melangkah dari pencegahan ke
pendeteksian dan dari kegagalan internal ke kegagalan eksternal.
Rekayasa Perangkat Lunak, Bab 8 FRD Hal : 4


P em be n tu kan D esain K ode U ji
P e n gem ba n ga n
U ji
S istem
O perasi
L a pa n ga n
1 0 00
10 0
1 0
1
Biaya Relatif Pembentukan Kesalahan
1
w aktu
3 - 6
w aktu
1 0
w aktu
1 5 - 40
w aktu
3 0 - 70
w aktu
4 0 - 10 0 0
w aktu
Gambar 8.1 Biaya Relatif pembetulan kesalahan






JAMINAN KUALITAS PERANGKAT LUNAK
Kualitas perangkat lunak didefinisikan sebagai:
Konformansi terhadap kebutuhan fungsional dan kinerja yang
dinyatakan secara eksplisit, standar perkembangan yang
didokumentasikan secara eksplisit, dan karakteristik implisit yang
diharapkan bagi semua perangkat lunak dikembangkan secara
profesional.


definisi tersebut berfungsi untuk menekankan tiga hal penting,
yaitu:
1. Kebutuhan perangkat lunak merupakan fondasi yang
melaluinya kualitas diukur.
2. Standar yang telah ditentukan menetapkan serangkaian
kriteria pengembangan yang menuntun cara perangkat lunak
direkayasa.
Rekayasa Perangkat Lunak, Bab 8 FRD Hal : 5
3. Ada serangkaian kebutuhan implisit yang sering dicantumkan
(misalnya kebutuhan akan kemampuan pemeliharaan yang
baik).


Kelompok SQA berfungsi sebagai perwakilan in-house pelanggan,
yaitu orang yang akan melakukan SQA harus memperhatikan
perangkat lunak dari sudut pandang pelanggan.


Kelompok SQA harus dapat menjawab pertanyaan-pertanyaan
dibawah ini untuk memastikan bahwa kualitas perangkat lunak
benar-benar terjaga.
• Apakah perangkat lunak cukup memenuhi faktor
kualitas
• Sudahkah pengembangan perangkat lunak dilakukan
sesuai dengan standar yang telah ditetapkan
sebelumnya?
• Sudahkah disiplin teknik dengan tepat memainkan
perannya sebagi bagian dari aktivitas SQA?






Aktivitas SQA
Jaminan kualitas perangkat lunak terdiri dari berbagai tugas yang
berhubungan dengan dua konstituen yang berbeda :
– perekayasa perangkat lunak yang mengerjakan kerja
teknis
– kelompok SQA yang bertanggung jawab terhadap
perencanaan jaminan kualitas, kesalahan, penyimpanan
rekaman, analisis, dan pelaporan.
Rekayasa Perangkat Lunak, Bab 8 FRD Hal : 6



Tugas kelompok SQA adalah
membantu tim rekayasa perangkat lunak dalam pencapaian produk
akhir yang berkualitas tinggi.
Aktivitas yang dilakukan (atau difasilitasi) oleh kelompok SQA
yang independen:
􀂙 Menyiapkan rencana SQA untuk suatu proyek. Rencana
tersebut mengindentifikasikan hal-hal berikut:
• Evaluasi yang dilakukan
• Audit dan kajian yang dilakukan
• Standar yang dapat diaplikasikan pada proyek
• Prosedur untuk pelaporan & penelusuran kesalahan
• Dokumen yang dihsilkan oleh kelompok SQA
• Jumlah umpan balik yang diberikan pada tim proyek
perangkat lunak
􀂙 Berpartisipasi dalam pengembangan deskripsi proses
pengembangan proyek.
􀂙 Mengkaji aktivitas rekayasa perangkat lunak untuk
memverifikasi pemenuhan proses perangkat lunak yang sudah
ditentukan.
􀂙 Mengaudit produk kerja perangkat lunak yang ditentukan
untuk membuktikan kesesuaian dengan produk kerja yang
ditentukan tersebut sebagai bagian dari proses perangkat
lunak.
􀂙 Memastikan bahwa deviasi pada kerja dan produk perangkat
lunak didokumentasikan & di- tangani sesuai dgn rosedur
pendokuementasian.
Rekayasa Perangkat Lunak, Bab 8 FRD Hal : 7
􀂙 Mencatat ketidak-sesuaian dan melaporkannya kepada
manajemen senior.
􀂙 Mengkoordinasi kontrol dan manajemen perubahan, dan
membantu mengumpulkan dan menganalisis metrik perangkat
lunak.



KAJIAN PERANGKAT LUNAK
Kajian perangkat lunak merupakan salah satu aktivitas SQA yang
terpenting.
Kajian perangkat lunak adalah suatu filter bagi proses rekayasa
perangkat lunak, yaitu kajian yg diterapkan pd berbagai titik
selama pengembangan PL & berfungsi untuk mencari kesalahan yg
kemudian akan dihilangkan.
Kajian perangkat lunak berfungsi untuk “memurnikan” produk
kerja perangkat lunak yang terjadi sebagai hasil dari analisis,
desain, dan pengkodean.



KAJIAN TEKNIK FORMAL
(Formal Technic Review - FTR )
FTR adalah aktivitas jaminan kualitas perangkat lunak yang
dilakukan oleh perekayasa perangkat lunak.
Kajian teknik formal atau walktrough adalah pertemuan kajian
yang disesuaikan dengan kebutuhan yang terbukti sangat efektif
untuk menemukan kesalahan.
Rekayasa Perangkat Lunak, Bab 8 FRD Hal : 8
Keuntungan utama kajian teknis formal adalah penemuan kesalahan
sejak awal sehingga tidak berlanjut ke langkah selanjutnya dalam
proses perangkat lunak.
Tujuan FTR adalah
1. Menemukan kesalahan dlm fungsi, logika, / implementasinya
dlm berbagai representasi PL;
2. Membuktikan bahwa perangkat lunak di bawah kajian
memenuhi syarat;
3. Memastikan bahwa PL disajikan sesuai dgn standar yg
sudah ditentukan sebelumnya;
4. Mencapai perangkat lunak yg dikembangkan dengan cara yang
seragam;
5. Membuat proyek lebih dapat dikelola.
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 backup dan kontinuitas
karena sejumlah orang mengenal baik bagian-bagian perangkat
lunak yang tidak mereka ketahui sebelumnya.
Masing-masing FTR dilakukan sebagai suatu pertemuan dan
akan berhasil hanya bila direncanakan, dikontrol dan dihadirkan
dengan tepat. Dalam paragraf berikut, panduan yang mirip dengan
walktrough disajikan sebagai kajian teknis formal representatif.
Rekayasa Perangkat Lunak, Bab 8 FRD Hal : 9
TABEL 8.1 Perbandingan Biaya Pengembangan
Kesalahan yang ditemukan Jumlah Unit Biaya Total
Kajian dilakukan
Selama desain
Sebelum pengujian
Selama pengujian
Setelah peluncuran
22
36
15
3
1.5
6.5
15
67
33
234
315
201
783
Kajian tidak dilakukan
Sebelum pengujian
Selama pengujian
Setelah peluncuran
22
82
12
6.5
15
67
143
1230
804
2177



Pertemuan Kajian
Tanpa memperhatikan format FTR yang dipilih, setiap pertemuan
kajian harus mematuhi batasan-batasan berikut ini :
• Antara 3 & 5 orang (khususnya) harus dilibatkan dalam
kajian;
• Persiapan awal harus dilakukan, tetapi waktu yang
dibutuhkan harus tidak lebih dari 2 jam dari kerja bagi
setiap person
• Durasi pertemuan kajian harus kurang dari 2 jam
Pertemuan kajian dihadiri oleh pimpinan kajian, pengkaji, dan
prosedur. Salah satu dari pengkaji berperan sebagai pencatat,
yaitu seseorang yang mencatat semua masalah penting yang muncul
selama pengkajian.
FTR dimulai dengan pengenalan agenda dan pendahuluan dari
prosedur. Bila ada masalah kesalahan ditemukan akan dicatat.
Rekayasa Perangkat Lunak, Bab 8 FRD Hal : 10
Pada akhir kajian, semua peserta FTR yang hadir harus
memutuskan apakah akan
1. menerima produk kerja tanpa modifikasi lebih lanjut,
2. menolak produk kerja sehubungan dengan kesalahan yangada
(sekali dbetulkan, kajiann lain harus dilakukan), atau
3. menerima produk kerja secara sementara (kesalahan minor
telah terjadi & harus dikoreksi, tetapi kajian tambahan akan
diperlukan).
Keputusan kemudian dibuat.
Semua peserta FTR melengkapinya dengan tanda tangan yang
menunjukkan partisipasi mereka dalam kajian serta persetujuan
mereka terhadap pertemuan tim kajian.


Pelaporan Kajian dan Penyimpanan Rekaman

Selama FTR, seorang pengkaji (pencatat) secara aktif mencatat
semua masalah yang sudah dimunculkan, yang kemudian dirangkum
pada akhir pertemuan sehingga dihasilkan daftar masalah kajian.
Sebagai tambahan, laporan rangkuman kajian yang sederhana telah
diselesaikan di mana rangkuman kajian merupakan jawaban dari
tiga pertanyaan berikut:
1. Apa yang dikaji ?
2. Siapa yang melakukan?
3. penemuan apa yang dihasilkan dan apa kesimpulannya?
Daftar masalah kajian mempunyai dua tujuan:
1. Mengidentifikasi area masalah pada produk,
2. Daftar item kegiatan yang menjadi petunjuk bagi prosedur saat
koreksi dilakukan.
Rekayasa Perangkat Lunak, Bab 8 FRD Hal : 11
Daftar masalah biasanya dilampirkan pada laporan.


Pedoman Kajian

Pedoman untuk melakukan kajian teknis formal harus dilakukan
sebelumnya, didistribusikan kepada semua pengkaji, disetujui, dan
kemudian dilaksanakan. Kajian yang tidak terkontrol sering dapat
menjadi lebih buruk daripada bila tidak ada kajian sama sekali.
Berikut ini serangkaian pedoman minimum untuk kajian teknis
formal:
1. Kajian produk, bukan produser.
2. Menetapkan agenda dan menjaganya.
3. Membatasi perdebatan dan bantahan.
4. Menetapkan area masalah, tetapi tidak tergoda untuk
menyelesaikannya setiap masalah yang dicatat.
5. Mengambil catatan tertulis.
6. Membatasi jumlah peserta dan mewajibkan persiapan awal.
7. Mengembangkan daftar bagi masing-masing produk kerja
yang akan dikaji.
8. Mengalokasikan sumber-sumber daya dan jadwal waktu
untuk FTR.
9. Melakukan pelatihan bagi semua pengkaji.
10. Mengkaji kajian awal Anda.


PENDEKATAN FORMAL TERHADAP SQA

Kualitas perangat lunak merupakan tugas setiap orang &
kualitas dapat dicapai melalui analisis, desain, pengkodean, dan
Rekayasa Perangkat Lunak, Bab 8 FRD Hal : 12
pengujian yang baik serta aplikasi standar pengembangan
perangkat lunak yang diterima.
Pada lebuh dari dua dekade, segmen komunitas rekayasa
perangkat lunak yang kecil tetapi vokal telah memperlihatkan
bahwa dibutuhkan suatu pendekatan yang lebih formal terhadap
jaminan kualitas perangkat lunak.
Pembuktian matematis terhadap kebenarannya dapat
diaplikasikan untuk menunjukkan bahwa program menyesuaikan diri
secara tepat dengan spesifikasinya

.
JAMINAN KUALITAS STATISTIK (SQA)

Jaminan kualitas statistik mencerminkan trend yang sedang
tumbuh di seluruh industri untuk menjadi lebih kuantitatif
terhadap kualitas.
Pada perangkat lunak, jaminan kualitas statistik mengimplikasikan
langkah-langkah berikut ini:
1. Informasi tentang cacat perangkat lunak dikumpulkan dan
dipilah-pilahkan.
2. Melakukan suatu usaha untuk menelusuri masing-masing
cacat sampai ke penyebab pokoknya.
3. Dengan menggunakan prinsip Pareto (80 persen cacat dapat
ditelusuri sampai 20 persen dari semua kemungkinan
penyebab), mengisolasi yang 20 persen tersebut (vital few)
4. Sekali penyebab vital few telah diidentifikasi, beralih untuk
membetulkan maslah yang menyebabkan cacat.
Banyak kesalahan ditemukan pada waktu perangkat lunak
sedang dalam proses pengembangan. Cacat yang lain ditemukan
setelah perangkat lunak diluncurkan kepada pemakai akhir.
Meskipun ratusan kesalahan yang berbeda diluncurkan, semuanya
dapat ditelusuri dari satu (atau lebih) penyebab berikut ini :
Rekayasa Perangkat Lunak, Bab 8 FRD Hal : 13
• Spesifikasi yang tidak lengkap atau keliru (IES)
• Kesalahan interpretasi komunikasi pelanggan (MMC)
• Deviasi intersioanl dari spesifikasi (IDS)
• Pelanggaran standar pemrograman (VPS)
• Kesalahan dalam representasi data (EDRIMI)
• Kesalahan dalam logika desain (EDL)
• Interface modul yang tidak konsisten (IMI)
• Pengujian yang tidak lengkap atau keliru (IET)
• Dokumentasi yang tidak lengkap atau tidak akurat (IID)
• Kesalahan dalam penerjemahan bahasa pemrograman desain
(PLT)
• Antarmuka manusia dengan komputer yang tidak konsisten
atau mengandung ambiguitas (HCI)
• Dan msih banyak lagi (MIS)


RELIABILITAS PERANGKAT LUNAK


Reliabilitas perangkat lunak, tidak seperti faktor kualitas
yang lain, dapat diukur, diarahan, dan diestimasi dengan
menggunakan data pengembangan historis. Reliabilitas perangkat
lunak didefinisikan dalam bentuk statistik sebagai “kemungkinan
operasi program komputer bebas kegagalan di dalam suatu
lingkungan tertentu dan waktu tertentu”.
Kapan saja reliabilitas perangkat lunak dibicarakan, selalu
muncul pertanyaan yang sangat penting : Apa yang dimaksudkan
dengan bentuk “kegagalan?” dalam konteks dan banyak diskusi
mengenai kualitas dan reliabilitas perangkat lunak, kegagalann
adalah ketidaksesuaian dengan kebutuhan perangkat lunak.
Kegagalan hanya akan mengganggu atau bahkan merupakan
bencana. Satu kegagalan dapat diperbaiki dalam beberapa detik
Rekayasa Perangkat Lunak, Bab 8 FRD Hal : 14
sementara kesalahan yang lain mungkin membutuhkan waktu
pembetulan berminggu-minggu atau bahkan berbulan-bulan.
Pembetulan satu kegagalan kenyataannya dapat menghasilkan
kesalahan lain yang baru yang mungkin akan membawa lagi
kesalahan yang lain lagi.


Pengukuran Reliabilitas dan Availabilitas


Kerja awal dalam reliabilitas perangkat lunak berusaha
mengekstrapolasi matematika teori reliabitas perangkat keras.
Sebagian besar model reliabilitas yang berhubungan dengan
perangkat keras didasarkan pada kegagalan sehubungan dengan
keusangan (wear), bukan kesalahan karena cacat desain. Dalam
perangkat keras, kegagalan sehubungan dengan keusangan fisik
(misalnya pengaruh suhu, korosi, kejutan) lebih banyak terjadi
daripada kegagalan karena isu. Akan tetapi, yang terjadi pada
perangkat lunak adalah hal yang sebaliknya. Kenyataannya, semua
kegagalan perangkat lunak dapat ditelusuri ke dalam desain atau
masalah implementasi; keusangan tidak tercakup.
Masih ada perdebatan yang terjadi di seputar hubunan
antara konsep kunci dalam reliabilitas perangkat keras dan
kemampuan aplikasinya terhadap perangkat lunak.
Meskipun ada hubungan yang tidak dapat dibantah, namun
sangat penting untuk memprtimbangkan beberapa konsep
sederhana yang berlaku untuk kedua sistem elemen tersebut.
Bila kita andaikan suatu sistem yang berbasis komputer,
pengukuran reliabilitas secara sederhana adalah berupa mean time
between failure (MTBF), dimana :
MTBF = MTTF + MTTR
Rekayasa Perangkat Lunak, Bab 8 FRD Hal : 15
(Akronim MTTF adalah mean time to failure dan MTR berarti
mean time to repair.)
Banyak peneliti berpendapat bahwa MTBF merupakan
pengukuran yang jauh lebih berguna daripada pengukuran
cacat/KLOC. Secara sederhana dapat dikatakan bahwa seorang
pemakai akhir lebih memperhatikan kegagalan, bukan jumlah cacat.
Karena masing-masing cacat yangada pada sebuah program tidak
memiliki tingkat kegagalan yang sama, maka penghitungan cacat
total hanya memberikan sedikit indikasi tentang reliabilitas
sistem.
Contohnya adalah sebuah program yang telah beroperasi
selama 14 bulan. Banyak cacat mungkin tidak terdeteksi dalam
jumlah waktu yang lama sampai pada akhirnya cacat itu ditemukan.
MTBF dari cacat yang tidak jelas seperti itu dapat berlangsung
sampai 50, bahkan 100 tahun. Cacat yang lain, yang juga belum
ditemukan, dapat memiliki tingkat kegagalan 18 atau 24 bulan.
Meskipun setiap kategori pertama cacat (yang memiliki MTBF
panjang) dihilangkan, pengaruhnya pada reliabilitas perangkat
lunak tidak dapat diabaikan.
Availabilitas perangkat lunak adalah kemungkinan sebuah
program beroperasi sesuai dengan kebutuhan pada suatu titik yang
diberikan pada suatu waktu dan didefinisikan sebagai :
Availabilitas = MTTF / (MTTF + MTTR) x 100 %
Pengukuran reliabilitas MTBF sama sensitifnya dengan MTTF dan
MTTR. Pengukuran availabilitas jauh lebih sensitif daripada
MTTR, yang merupakan pengukuran tidak langsung terhadap
kemampuan pemeliharaan perangkat lunak.
Rekayasa Perangkat Lunak, Bab 8 FRD Hal : 16


Keamanan Perangkat Lunak dan Analisis Risiko

Leveson membicarakan pengaruh perangkat lunak dalam sistem
kritis keamanan ketika menulis :
Sebelum perangkat lunak digunakan di dalam sistem kritis
keamanan, perangkat lunak itu sering dikontrol oleh alat
mekanik konvensional (tidak dapat diprogram) dan elektronik.
Teknik keamanan sistem didesain untuk mengatasi kegagalan
acak dalam sistem-sistem tersebut. Kesalahan perancangan
oleh manusia dapat sepenuhnya dihindari atau dihilangkan
sebelum perangkat lunak tersebut diluncurkan dan
dioperasikan.
Ketika perangkat lunak diguanakn sebagai bagian dari sistem
kontrol, kompleksitasnya dapat bertambah dengan satu urutan
besaran atau lebih. Kesalahan desain yang tidak kentara yang
disebabknan oleh kesalahan manusia – sesuatu yang dapat
diunkapkan dan dikurangi dalam kontrol konvensional berbasis
perangkat keras – menjadi lebih sulit ditemukan pada waktu
perangkat lunak digunakan.
Keamanan perangkat lunak dan analisis risiko adalah aktivitas
jaminan kualitas perangkat lunak yang berfokus pada identifikasi
dan penilaian risiko potensial yang mungkin berpengaruh negatif
terhadap perangkat lunak dan menyebabkan seluruh sistem
menjadi gagal. Jika risiko dapat diidentifikasi pada awal proses
rekayasa perangkat lunak, maka ciri-ciri desain perangkat lunak
dapat ditetapkan sehingga akan mengeliminasi atau mengontrol
risiko potensial.
Rekayasa Perangkat Lunak, Bab 8 FRD Hal : 17
Proses analisis dan modeling dilakukan sebagai bagian dari
keamanan perangkat lunak. Awalnya, risiko diidentifikasi dan
dipilah-pilahkan berdasarkan kekritisan dan risiko. Sebagai
contoh, beberapa risiko yang berkaitan dengan kontrol peluncuran
berbasis komputer untuk automobil mungkin:
• Menyebabkan percepatan yang tidak terkontrol tidak dapat
dihentikan
• Tidak lepas ketika pedal rem ditekan
• Tidak nyambung ketika skalar diaktifkan
• Perlahan-lahan kehilangan atau menambah kecepatan
Setelah risiko tingkat sistem diidentifikasi, maka digunakan
teknik analisis untuk menandai kehebatan dan probabilitas event.
Supaya efektif, perangkat lunak harus dianalisis dalam konteks
keseluruhan sistem. Sebagai contoh, kesalahan input pemakai yang
tidak kentara (manusia sebagai komponen sistem) dapat
diperbesar oleh kesalahan perangkat lunak, sehingga menghasilkan
data kontrol yang memposisikan sebuah perangkat lunak, sehingga
menghasilkan data kontrol yang memposisikan sebuah perangkat
mekanik secara tidak tepat. Jika ada serangkaian kondisi
lingkungan eksternal (dan hanya jika mereka ditemui), maka posisi
perangkat mekanik yang tidak tepat dapat menyebabkan kegagalan
fatal. Teknik analisis seperti analisis pohon kegagalan, logika realtime
, atau model Petrinet , dapat digunakan untuk memprediksi
rantai event yang dapat mengakibatkan risiko dan kemungkinan di
mana setiap event akan terjadi untuk menciptakan rantai.
Analisis pohon kesalahan membangun model grafis dan
kombinasi event yang konkuren dan berurutan yang dapat
menyebabkan suatu event atau sistem yang penuh risiko. Dengan
menggunakan pohon kesalahan yang dikembangkan dengan baik,
Rekayasa Perangkat Lunak, Bab 8 FRD Hal : 18
maka dimungkinkan untuk meneliti kosekuensi urutan kegagalan
yang terinterelasi yang terjadi pada komponen sistem yang
berbeda. Logika real-time (RTL) membangun sebuah model sistem
dengan menentukan event dan aksi yang sesuai. Model eventaction
dapat dianalisis dengan menggunakan operasi logika untuk
menguji tuntutan keamanan seputar komponen sistem dan timingnya.
Model Petrinet dapat digunakan untuk menentukan kesalahan
yang paling berisiko.
Sekali risiko diidentifikasi dan dianalisis, maka keamanan
yang berhubungan dengan kebutuhan untuk perangkat lunak dapat
ditetapkan. Spesifikasi dapat berupa sederetan event yang tidak
diinginkan dan sistem yang diinginkan merespon event tersebut.
Peran perangkat lunak dalam mengatur event yang tidak diinginkan
kemudian diindikasi.
Meskipun reliabilitas perangkat lunak berhubungan erat satu
sama lain dengan lainnya, namun sangat penting untuk memahami
perbedaan tipis yang ada di antara mereka. Reliabilitas perangkat
lunak menggunakan analisis statistik untuk menentukan
kemungkinan terjadinya kegagalan perangkat lunak. Tetapi
kegagalan tidak perlu menghasilkan risiko atau kecelakaan.
Kemanan perangkat lunak mengamati bagaimana kegagalan
menimbulkan keadaan yang dapat menyebabkan kecelakaan.
Kegagalan tidak perlu dipertimbangkan di dalam ruang hampa,
tetapi dievaluasi dalam konteks keseluruhan sistem berbasis
komputer.
Diskusi komprehensif tentang analisis risiko dan keamanan
perangkat lunak tidak masuk dalam ruang lingkup buku ini. Pembaca
yang tertarik untuk mengetahui lebih jauh tentang hal tersebut
sebaiknya membaca buku yang ditulis oleh Leveson .
Rekayasa Perangkat Lunak, Bab 8 FRD Hal : 19


RENCANA SQA

SQA plan menjadi peta jalan untuk membangun jaminan kualitas
perangkat lunak. Dikembangkan oleh kelompok SQA dan tim
proyek, rencana itu berfungsi sebagai template bagi aktifitas
SQA yang dibangun untuk setiap proyek perangkat lunak.
Gambar 8.5 memperlihatkan sebuah outline untuk rencana
SQA yang disetujui oleh IEEE . Bagian awal menggambarkan
tujuan dan ruang lingkup dokumen dan menunjukkan aktivitas
proses perangkat lunak yang diungkap oleh jaminan kualitas.
Semua dokumen yang dicatat oleh rencana SQA didaftar dan
semua standar yang dapat diapliksikan dicatat. Bagian Manajemen
dari rencana tersebut menggambarkan tempat SQA pada struktur
organisasi; tugas-tugas dan aktivitas SQA dan penempatannya di
seluruh proses perangkat lunak; dan peran organisasional serta
tanggung jawab relatif terhadap kualitas produk.
Bagian Dokumentasi menggambarkan (dengan refernsi)
masing-masing produk kerja yang dihasilkan sebagai bagian dari
proses perangkat lunak; mencakup hal-hal berikut :
• Dokumen proyek (misalnya, rencana proyek)
• Model (misalnya, hirarki kelas ERD)
• Dokumen teknis (misalnya, spesifikasi, rencana pengujian)
• Dokumen pemakai (misalnya file0file help)
Sebagai tambahan, bagian ini menentukan serangkaian produk
kerja minmum yang dapat diterima untuk mencapai kualitas yang
tinggi.
Rekayasa Perangkat Lunak, Bab 8 FRD Hal : 20
Standar, Praktik dan Konversi mencatat semua
standar/praktik yang diterapkan selama proses perangkat lunak
(misalnya, standar dokumen, stadar pengkodean, dan pedoman
kajian). Semua proyek, proses, dan metrik produk yang
dikumpulkan sebagai bagian dari usaha rekayasa perangkat lunak
juga harus dicatat.
Bagian Kajian dan Audit dari rencana mengidentifiaksi kajian
dan audit yang akan dilakukan oleh tim rekayasa perangkat lunak,
kelompok SQA, dan pelanggan. Bagian ini memberikan gambaran
yang luas terhadap pendekatan bagi masing-masig kajian dan audit.
I. Tujuan Rencana
II. Referensi
III. Manajemen
1. Organisasi
2. Tugas
3. Tanggung jawab
IV. Dokumentasi
1. Tujuan
2. Dokuen rekayasa perangkat lunak yang diperlukan
3. Dokumen-dokumen lain
V. Standar, Praktis dan Konversi
1. Tujuan
2. Konvensi
VI. Tinjauan dan Audit
1. Tujuan
2. Tinjauan
a. Kebutuhan perangkat lunak
b. Desain
c. Verifikasi dan validasi perangkat lunak
d. Audit fungsional
e. Audit fisik
f. Audit in-process
g. Manajemen
Rekayasa Perangkat Lunak, Bab 8 FRD Hal : 21
VII. Pengujian
VIII. Pelaporan Masalah dan Tindakan Koreksi
IX. Peranti, Teknik, dan Metodologi
X. Kontrol Kode
XI. Kontrol Media
XII. Kontrol Pemasok
XIII. Pengumpulan, Pemeliharaan, dan Penyimpanan Catatan
XIV. Pelatihan
XV. Manajemen Risiko
Gambar 8.5 Rencana kualitas jaminan perangkat lunak standar
ANSI/IEEE 730 – 1984 dan 983-1986
Bagian pengujian merujuk rencana dan prosedur pengujian
perangkat lunak (Bab17). Bagian ini juga menentukkan kebutuhan
penyimpanan rekaman pengujian. Pelaporan Masalah dan Tindakan
Korektif menentukan prosedur untuk pelaporan, pelacakan, dan
pembetulan kesalahan serta cacat, juga mengidentifikasi tanggung
jawab organisaional untuk akyivitas-aktivitas tersebut.
Bagian akhir rencana SQA adalah mengidentifikasi peranti dan
metode yang mengandung aktifitas dan tugas-tugas SQA; merujuk
manajemen konfigurasi perangkat lunak untuk mengontrol
perubahan; menetapkan pendekatan manajemen kontrak;
membangun metode perakitan, perlindungan dan pemeliharaan
semua catatan; mengidentifikasi pelatihan yang dibutuhkan untuk
memenuhi kebutuhan rencana, serta menetapkan metode-metode
untuk mengidentifikasi, menilai, memonitor, dan mengontrol risiko.


STANDAR KUALITAS ISO 9000

Sistem jaminan kualitas dapat didefinisikan sebagai strukutr,
tanggung jawab, prosedur, proses dan sumber-sumber daya
Rekayasa Perangkat Lunak, Bab 8 FRD Hal : 22
organisasi untuk mengimplementasi manajemen kualitas. ISO 9000
menjelaskan elemen jaminan kualitas dalam bentuk yang umum
yang dapat diaplikasikan pada berbagai bisnis tanpa memandang
produk dan jasa yang ditawarkan.
Agar terdaftar dalam satu model sistem jaminan kualitas
yang ada pada ISO 9000, sistem kualitas dan operasi perusahaan
diperiksa oleh auditor bagian ketiga untuk memeriksa
kesesuaiannya dengan standar dan operasi efektif. Bila registrasi
itu berhasil, perusahaan diberi sertifikat dari badan registrasi
yang diwakili oleh auditor. Audit pengawasan tegah tahuan terus
dilakukan untuk memastikan kesesuaiannya dengan standar yang
sudah ditetapkan.


Pendekatan ISO terhadap Sistem Jaminan Kualitas

Model jaminan kualitas ISO 9000 memperlakukan perusahaan
sebagai jaringan proses yang saling terhubung (interkoneksi).
Suatu sistem kualitas, supaya sesuai dengan ISO, prosesprosesnya
harus menekankan pada area yang telah diidentifikasi
pada standar ISO, dan harus didokumentasi dan dipraktikan
sebagimana dikelaskan. Pendokuemnatsian proses membantu
organisasi untuk memahami, mengontrol, dan mengembangkan
jaringan proses yang mungkin dapat mendatangkan keuntunagn
terbesar bagi organisasi yang merancang dan
mengimplementasikan kualitas yang sesuai dengan ISO.
ISO 9000 menggambarkan elemen sebuah sistem jaminan
kualitas secara umum. Elemen-elemen tersebut mencakup
struktur, prosedur, proses, organisasi, dan sumber day ayang
dibutuhkan untuk mehimplementasi rencana kualitas, kontrol
kualitas, jaminan, kualitas, dan pengembangan kualiats. Tetapi ISO
Rekayasa Perangkat Lunak, Bab 8 FRD Hal : 23
9000 tidak menggambarkan bagaimanan organisasi seharusnya
mengimpelemnatsi elemen-elemen kualitas tersebut. Sebagai
konsekuensi, ada tantangan dalam mendesain dan
mengimplementasi suatu sistem jaminan kualitas yang memenuhi
standar dengan produk, layanan dan budaya perusahaan.


Standar ISO 9001

ISO 9001 adalah standar kualitas yang berkalu untuk rekayasa
perangkat lunak. Standar tersebut berisi 20 syarat yang harus
ada untuk mencapai sistem jaminan kualitas yangefektif. Karena
standar ISO 9001 dapat diaplikasikan pada semua disiplin
rekayasa / engineering, maka dikembangkan sekumpulan khusus
pedoman ISO untuk membantu menginterpretsi standar untuk
digunakan pada proses perangkat lunak.
Dua puluh syarat yang digambarkan oleh ISO 9001
menekankan topik-topik berikut :
1. Tanggung jawab manajemen
2. Sistem kualitas
3. Kajian kontrak
4. Kontrol desain
5. Kontrol data dan dokumen
6. Pembelian
7. Kontrol terhadap produk yang disuplai oleh pelanggan
8. Identifikasi dan kemampuan penelusuran produk
9. Kontrol proses
10. Pemeriksaan dan pengujian
11. Kontrol pemeriksaan, pengukuran, dan perlengkapan
pengujian
12. Pemeriksaan dan status pengujian
Rekayasa Perangkat Lunak, Bab 8 FRD Hal : 24
13. Kontrol ketudaksesuaian produk
14. Tindakan preventif dan korektif
15. Penanganan, penyimpanan, pengepakan, preservasi, dan
penyampaian
16. Kontrol terhadap catatan kualitas
17. Audit kualitas internal
18. Pelatihan
19. Pelayanan
20. Teknik statistik
Untuk dapat didaftar dalam ISO 9001, organisasi perangkat lunak
harus membuat kebijakan dan prosedur yang memberi tekanan
pada masing-masing syarat tersebut dan kemudian dapat
menunjukkan bahwa prosedur dan fungsi itu telah diikuti. Untuk
penjelsan leih lanjt, pembaca yang tertarik dengan informasi
mengnenai ISO 9001.
Tag : MATA KULIAH
0 Komentar untuk "REKAYASA PERANGKAT LUNAK"

INFO NEWS UPDATE

loading...
Back To Top