APA ITU VERIFIKASI KEBUTUHAN ??

Presentasi berjudul: "APA ITU VERIFIKASI KEBUTUHAN ??"— Transcript presentasi:

1 APA ITU VERIFIKASI KEBUTUHAN ??
Verifikasi kebutuhan perangkat lunak adalah tahapan dari rekayasa perangkat lunak untuk memastikan produk yang dihasilkan dari aktivitas pengembangan sesuai dengan spesifikasi yang ditentukan atau dalam istilahnya “doing the thing right”.

2 Menurut Abram and Moore, 2001 aktivitas verifikasi dan validasi memiliki tujuan untuk memastikan:
Dokumen SKPL menjelaskan dengan benar keinginan terhadap kapabiiitas dan karakteristik yang memuaskan bagi pemangku kepenringan. SKPL diuraikan dengan benar sesuai dengan kebutuhan sistem, aturan bisnis, dan sumber- sumber lain yang berkaitan. Spesifikasi kebutuhan menyeluruh dan berkualitas tinggi. Representasi kebutuhan sudah konsisten dan tidak adanya konflik antarspefikasi satu dengan yang lainnya. SKPL menyediakan informasi yang cukup, berkualitas dan dapat dipercaya.

3 standar IEEE (IEEE, 1998) verifikasi dan validasi dari spesifikasi kebutuhan diharuskan memiliki kriteria antara lain: Tepat, spesifikasi kebutuhan dinyatakan benar apabila setiap pernyataan kebutuhan dengan sistem bisa saling bertemu dan dapat direalisasikan. Tidak rancu, spesifikasi kebutuhan tidak rancu jika dan hanya jika setiap pernyataan kebutuhan hanya memiliki satu interpretasi. Lengkap, semua spesifikasi kebutuhan sudah mencakup keseluruhan sistem yang dibutuhkan oleh pemangku kepentingan. Konsisten, tidak terdapat bagian ataupun sub bagian yang konflik antara satu dengan lainnya.

4 standar IEEE (IEEE, 1998) verifikasi dan validasi dari spesifikasi kebutuhan diharuskan memiliki kriteria antara lain: Diranking berdasarkan kepentingannya, Spesifikasi kebutuhan di Susun sesuai dengan prioritas pentingnya tiap bagian di dalam sistem. Dapat diverifikasi, hasil akhir dari pruduk dapat diukur sesuai dengan spesifikasi kebutuhan. Dapat dimodifikasi, spesifikasi kebutuhan dimungkinkan untuk dilakukan perubahan. Dapat dilacak, Spesifikasi dapat ditelusuri tiap bagiannya tahap demi tahap.

5 Apakah semua kebutuhan didalam SRS juga terdapat dalam model analisis?
Untuk mempermudah melakukan proses verifikasi dan validasi tersebut, Anda dapat menggunakan daftar pertanyaan untuk pengecekan terstruktur sebagaimana ditunjukkan pada Tabel 8.1. Item verifikasi ketepatan Apakah semua kasus penggunaan dapat direalisasikan melalui sequence diagram? Apakah semua kebutuhan didalam SRS juga terdapat dalam model analisis? Kerancuan Apakah terdapat penggunaan susunan kata seperti “mungkin”, memungkinkan”, “seharusnya”, “dapat”, “lebih baik”, “beberapa”, “seringkali” atau kata lain yang tidak mempunyai ukuran pasti. Apakah sudah menggunakan struktur standar Bahasa yang baku.

6 Apakah semua referensi didefinisikan sepenuhnya?
kelengkapan Apakah semua referensi didefinisikan sepenuhnya? Apakah semua pengertian yang tidak umum didefinisikan? Apakah semua kondisi dan hubungan keterikatan spesifikasi kebutuhan fungsional terdapat di dalam SRS? konsistensi Apakah setiap atriut didefinisikan sekali saja? Apakah setiap metode didefinisikan sekali saja? Dapat diverifikasi Apakah semua kuantitas spesifikasi dalam pengertian yang terukur? dapat dimodifikasi Sudahkan semua struktur yang berulang dihilangkan? Apakah struktur SRS sesuai dengan struktur model analisis? dapat dilacak Apakah setiap kebutuhan dapat ditelusuri pada kasus penggunaannya untuk direalisasikan?

7 aktivitas verifikasi dan validasi PERLU manajemen kerja yang meliputi:
Perencanaan dan pemeliharaan kebutuhan. Koordinasi dan interpretasi kemampuan dan kualitas usaha. Memberikan catatan ketidak-sesuaian dengan segera kepada pengguna ataupun kelompok pengembang. Mengidentifikasi kemungkinan masalah dari awal. Menyediakan evaluasi teknis dari kemampuan perangkat lunak dan kualitas pendukungnya.

8 aktivitas verifikasi dan validasi PERLU manajemen kerja yang meliputi:
Menilai dampak keseluruhan yang diakibatkan apabila terdapat perubahan spesifikasi kebutuhan. Menentukan sasaran kualitas dan kemampuan produk. Memberikan beragam antisipasi terhadap masalah dan bagaimana pemecahannya. Dapat menggunakan pilihan perangkat lunak yang mampu untuk menganalisis dan menguji secara efektif masalah-masalah pada sistem dan perangkat lunak. Memilih tahapan dan teknik yang diaplikasikan untuk mengukur dan memprediksi kualitas perangkat lunak.

9 fokus kegiatan dalam tahapan verifikasi meliputi:
1. Mengawali dengan evaluasi terhadap dokumentasi konsep. 2. Memulai perancanaan pengujian. 3. Mengawali analisis penelusuran perangkat lunak. 4. Mengawali evaluasi kebutuhan. 5. Mengawali analisis antarmuka atau tampilan. 6. Evaluasi penggunaan ulang perangkat lunak.

10 cakupan yang berkaitan dengan SKPL di antaranya adalah:
SKPL seharusnya dengan benar mendefinisikan semua kebutuhan perangkat lunak dan tidak dimungkinkan adanya multi-interpretasi. SKPL seharusnya tidak mendeskripsikan detail beberapa rancangan dan implementasinya. SKPL seharusnya tidak menambahkan hubungan-hubungan sistem dengan sistem di luarnya.

11 Sebagai contoh untuk pendekatan inspeksi terhadap model data ditunjukkan pada Gambar 8.1. Gambar tersebut menunjukkan dua model relasi entitas data relasional.

12 Boundary value analysis Control flow analysis Database analysis
13 langkah-langkah teknis yang dapat ditempuh untuk melakukan verifikasi perangkat lunak sebagai berikut: Analisis algoritma Decision truth table Mutation analisys Interface analisis Back to back testing Consistency analysis Interface testing Boundary value analysis Control flow analysis Database analysis Coverage analysis Data use analysis Error seeding

13 APA ITU VALIDASI ? Validasi dibutuhkan untuk memberikan kepastian bahwa rancangan dan dokumen dari sistem yang akan diimplementasikan telah sesuai dengan keinginan dan kebutuhan pemangku kepentingan baik pemesan, pengguna, maupun pihak pengembang.

14 validasi untuk memberikan kepuasan kepada pemangku kepentingan, yaitu:
Tepat Dirangking berdasarkan tingkat kepentingan dan stabilitas Lengkap Tidak rancu Dapat dimodiiikasi Konsisten Dapat diverifikasi Dapat dilacak

15 Apa itu PENGECEKAN SPESIFIKASI ?
Analis kebutuhan dapat dicek dalam beberapa hal tanpa melakukan konsultasi. Jika ditemukan adanya permasalahan ataupun kesalahan, terdapat beberapa langkah yang memungkinkan di antaranya dengan cara mengecek: Permasalahan Beberapa informasi salah namun sudah terwakili oleh informasi yang lainnya Kesalahan pada beberapa informasi penting Dua bagian atau spesifikasi terjadi konflik Beberapa informasi salah namun kurang signifikan di dalam pekerjaan

16 Apa itu Pengecekan Konten ?
Pengecekan spesifikasi kebutuhan adalah pengecekan konten. Pengecekan konten pada dasarnya memperhatikan apakah informasi dasar yang diperlukan dalam sebuah dokumen spesifikasi kebutuhan hadir

17 daftar konten yang dapat dicek ketika memverifikasi konten dari suatu dokumen spesifikasi kebutuhan:
Apakah dokumen mengandung konten atau informasi tentang: - Pelanggan, sponsor dan latar belakang, -Tujuan bisnis dan bukti pelacakanny,a - Data kebutuhan (basis data, format masukan/keluaran, status komuni-kasi, dan inisialisasi, - Batasan dan antarmuka sistem, - Kebutuhan level-ranah (kejadian-kejadian dan tugas-tugas), - Kebutuhan level-produk (kejadian-kejadian dan fitur-fitur),

18 (Lanjutan): - Kebutuhan level-rancangan (prototipe dan protokol komunikasi) - Spesifikasi dari fungsi yang tidak sepele, - Kasus-kasus ekstrem, kejadian khusus, dan kegagalan tugas, - Kebutuhan kualitas (unjuk kerja, usability, keamanan, dll), - Item yang dianggap sebagai produk dari proyek pengembangan perangkat lunak (deliverable) yang akan diserahkan pengembang kepada pelanggan lain (dokumentasi, pelatihan, dll), - Glosarium (deiinisi dari terminologi, dan lain-lain).

19 Berikut adalah struktur dari konten yang diharapkan ada dalam suatu dokumen spesifikasi kebutuhan:
Pendahuluan Perlakuan pada kasus yang khusus Tujuan sistem Kebutuhan data Kebutuhan kualitas Kebutuhan fungsional Penyerahan lainnya Daftar

20 Penilaian Risiko Hal lain yang juga diperlukan dalam validasi adalah pengecekan terhadap risiko. Risiko yang tinggi terhadap pelanggan menjadi risiko yang rendah bagi pengembang dan begitu sebaliknya.

21 Langkah yang perlu ditempuh untuk mengenali risiko dapat dilakukan dengan:
Staf pelanggan perlu meninjau ulang spesifikasi dan merangking tiap kebutuhan sesuai risikonya masing- masing. Risiko yang seringkali ada adalah pelanggan tidak mendapatkan apa yang diinginkan sampai dia mendapatkan apa yang dispesifikasikan. spesifikasi. Developer dapat melakukan hal sama untuk merangking tingkat risiko yang akan dihadapi. Risiko yang biasa terjadi mereka tidak bisa memastikan kesesuaian spesifikasi dengan pembiayaan proyek. Justifikasi dibuat untuk melihat sampai sejauh mana risiko yang mungkin dihadapi. Dengan menggunakan cek konten, pelanggan dapat mengidentifikasi bagian- bagian yang belum terdapat dalam

22 terdapat cara singkat untuk menanggulangi risiko yang tidak dapat ditoleransi , di antaranya:
Pilih model kebutuhan yang lain dengan risiko yang lebih rendah Melakukan elisitasi lagi kebutuhan yang lebih tepat, Mengisolasi risiko untuk mengurangi kegagalan jika kecelakaan terjadi. Menjaga risiko di bawah pengawasan sehingga pengembang mampu bertindak cepat jika kecelakaan ataupun kegagalan terjadi.

23 Apa itu PENGUJIAN ? Pengujian adalah cara terbaik untuk melakukan validasi kebutuhan. Sesuai dengan apa yang didapatkan pelanggan, apa yang diharapkan, dan dapat direalisasikan. Pengujian dapat menggunakan teknik-teknik elisitasi. Metode pengujian yang dapat diterapkan adalah: Simulasi Pilot Prototipe

24 PERKAKAS BANTU Perkakas Bantu SCR
Perkakas bantu SCR (Software Cost Reduction) (Heitmeyer et.al., 1997) dirancang untuk melakukan proses spesifikasi, verifikasi, dan validasi terhadap kebutuhan dengan menggunakan metode formal. Perkakas bantu ini memainkan peran penting dalam memastikan bahwa sistem telah memenuhi properti kritis yang telah ditetapkan

25 fungsi dari perkakas bantu scr
Mendemonstrasikan well-formedness Menemukan pelanggaran property Memverifikasi properti yang kritis Memvalidasi spesifikasi Mengonstruksi kasus pengujian Mendeteksi kesalahan dan kerentanan dalam program

26 Untuk mendukung hal-hal tersebut, perkakas bantu SCR diperlengkapi dengan fitur-fitur sebagai berikut: Specificarion Editor: Consistency Checker : editor untuk membuat atau melakukan modifikasi spesifikasi kebutuhan. mengecek format dari spesifikasi(misalnya : kesesuaian sintaks, definisi pada spesifikasi kebutuhan). Simulator : Verifier : untuk melakukan simulasi pada spesifikasi. untuk menganalisis Spesifikasi kebutuhan.

27 Perkakas Bantu QuARS Formal Method and Tool (FMT) Group memperkenalkan perkakas yang bernama Quality Analyzer of Requirements Specifications (QuARS),(Lami, 2005), (Bucchiarone et al, 2008). QuARS didasarkan pada model kualitas yang mengukur kemampuan untuk dapat diuji (testability), kelengkapan (completeuess), kemampuan untuk dapat dimengerti ( understandability), dan konsistensi (consistency) dari spesifikasi kebutuhan perangkat lunak yang ditulis dalam bahasa alamiah.

28 Arsitektur sistem QuARS dapat dilihat pada Gambar 8. 2
Arsitektur sistem QuARS dapat dilihat pada Gambar 8.2. komponennya adalah sebagai berikut: Syntactical Parser sebelumnya (memanfaatkan hasil dari Syntax dan Lexical Parser) dan menuliskannya ke dalam file log. Menggunakan aplikasi Minipar. Lexical Parser Dictionaries Lexical Parser mengidentifikasi kata dan frasa tertentu yang muncul dalam setiap kalimat. Dictionaries adalah komponen pasif dari kakas ini. Berisi terminologiterminologi yang dibutuhkan oleh komponen lainnya. Indicators Detector Indicators Detector merupakan komponen asli yang mendeteksi indikator-indikator yang telah ditetapkan

29 Perkakas Bantu ReqSAC ReqSAC (Requirements Specification Ambiguity Checker) (Hussain et.al., 2007) merupakan perkakas bantu yang dirancang untuk penilaian secara otomatis pada dokumen SKPL, untuk mendeteksi ada tidaknya kata-kata yang rancu pada dokumen SKPL.

30 Perkakas Bantu SMART Detector
Muliawan dan Siahaan (2011) memperkenalkan suatu perkakas bantu pendeteksi kerancuan. Perkakas bantu ini menganalisis spesifikasi kebutuhan perangkat lunak berdasarkan aturan SMART (Specific, Measureable, Attainable, Relizable, and Trackable) Requirements. Sistem ini memanfaatkan pemrosesan bahasa alamiah (Natural Language Processing -NLP). Selain itu, Sistem ini dibantu oleh kamus Wordnet sebagai repositori dari kata-kata yang tidak diinginkan.

31 Arsitektur sistem analisis kerancuan dengan aturan SMART