A NALISIS K EBUTUHAN DAN S PESIFIKASI P ERANGKAT L UNAK.

Presentasi berjudul: "A NALISIS K EBUTUHAN DAN S PESIFIKASI P ERANGKAT L UNAK."— Transcript presentasi:

1 A NALISIS K EBUTUHAN DAN S PESIFIKASI P ERANGKAT L UNAK

2 L ATAR B ELAKANG Masalah skala merupakan isu kunci untuk PL Untuk skala kecil, sangat mudah untuk memahami dan menentukan kebutuhan Untuk skala besar - sangat sulit, mungkin merupakan yang paling sulit, paling bermasalah dan rawan. Masukan: kebutuhan pengguna dalam pikiran orang lain. Keluaran: Pernyataan yang tepat dari sistem yang diinginkan dan dibutuhkan.

3 L ATAR B ELAKANG.. Mengidentifikasi dan menetapkan kebutuhan ( requirement ) selalu melibatkan interaksi orang Tidak bisa otomatis Kebutuhan (IEEE) = Sebuah kondisi atau kemampuan yang harus dimiliki oleh sistem Fase kebutuhan berakhir dengan dokumen spesifikasi kebutuhan perangkat lunak (SRS) SRS menentukan apa yang harus dilakukan sistem yang diusulkan

4 L ATAR B ELAKANG.. Sulitnya memahami kebutuhan Visualisasi sistem yang akan dibangun adalah sulit Kemampuan dari sistem yang akan dibangun tidak jelas, maka kebutuhan tidak jelas kebutuhan berubah sewaktu-waktu... Penting untuk melakukan analisis dan spesifikasi kebutuhan yang tepat

5 P ERLUNYA SRS SRS menetapkan dasar kesepakatan antara pengguna dan pemasok Pengguna harus puas, tapi pengguna tidak dapat memahami perangkat lunak Pengembang akan mengembangkan sistem, tetapi mungkin tidak tahu tentang masalah ranah SRS adalah media untuk menjembatani kesenjangan tersebut. dan menentukan kebutuhan pengguna dengan cara yang baik dan bisa mengerti

6 P ERLUNYA SRS... Membantu pengguna memahami keperluannya. pengguna tidak selalu tahu keperluan mereka harus menganalisis dan memahami potensi tujuannya adalah tidak hanya untuk mengotomatisasi sistem manual, tetapi juga untuk menambahkan nilai melalui TI Proses kebutuhan membantu memperjelas keperluan SRS menyediakan referensi untuk validasi dari produk akhir Pemahaman yang jelas tentang apa yang diharapkan. Validasi - “PL memenuhi SRS"

7 P ERLUNYA SRS... SRS yang bermutu tinggi penting untuk PL yang bermutu tinggi Kesalahan kebutuhan akan diwujudkan dalam PL akhir untuk memenuhi tujuan mutu, harus dimulai dengan SRS bermutu tinggi Cacat kebutuhan tidak sedikit 25% dari semua cacat dalam satu kasus; 54% dari semua cacat yang ditemukan setelah pengujian unit 80 cacat dalam A7 yang mengakibatkan permintaan perubahan 500 / 250 cacat dalam SRS yang sebelumnya disetujui.

8 P ERLUNYA SRS... SRS yang baik mengurangi biaya pengembangan Kesalahan SRS mahal untuk diperbaiki kemudian Perubahan kebutuhan memerlukan biaya besar (hingga 40%) SRS yang baik dapat meminimalkan perubahan dan kesalahan Penghematan substansial; upaya ekstra yang dihabiskan selama fase kebutuhan menghemat upaya beberapa kali lipat Contoh Biaya untuk memperbaiki kesalahan dalam kebutuhan, perancangan, pemrograman, pengujian penyerahan dan operasi adalah 2, 5, 15, 50, 150 orang-bulan

9 P ERLUNYA SRS... Contoh... Setelah fase kebutuhan 65% kesalahan kebutuhan terdeteksi dalam perancangan, 2% dalam pemrograman, 30% dalam pengujian penerimaan, 3% selama operasi Jika 50 kesalahan kebutuhan tidak dihilangkan dalam fase kebutuhan, total biaya 32,5 * 5 + 1 * 15 + 15 * 50 + 1,5 * 150 = 1152 jam Jika 100 orang-jam tambahan diinvestasikan dalam fase kebutuhan untuk menangkap 50 cacat ini, maka biaya pembangunan bisa dikurangi dengan 1152 orang-jam Pengurangan bersih dalam biaya adalah 1052 orang- jam

10 P ROSES K EBUTUHAN Urutan langkah-langkah yang perlu dilakukan untuk mengubah keperluan pengguna menjadi SRS Proses ini harus menggali keperluan dan kebutuhan dan menetapkannya dengan jelas Kegiatan Dasar analisis masalah atau kebutuhan spesifikasi kebutuhan validasi Analisis melibatkan elisitasi/penggalian dan yang paling sulit

11 Requirements 11 P ROSES K EBUTUHAN.. needs Analysis Specification Validation

12 P ROSES K EBUTUHAN.. Proses ini tidak linier, hal ini berulang dan paralel Tumpang tindih antara fase - beberapa bagian dapat dianalisis dan ditetapkan Spesifikasi sendiri dapat membantu analisis Validasi dapat menunjukkan kesenjangan yang dapat menyebabkan analisis lebih lanjut dan spesifikasi

13 P ROSES KEBUTUHAN... Fokus analisis adalah pada pemahaman sistem yang diinginkan serta kebutuhannya Membagi dan menaklukkan adalah strategi dasarnya urai menjadi bagian-bagian kecil, fahami setiap bagian serta hubungan antara bagian-bagian volume informasi yang dihasilkan besar mengorganisasi informasi adalah kunci Teknik seperti diagram aliran data, diagram objek dll yang digunakan dalam analisis

14 KEBUTUHAN P ROSES.. Transisi dari analisis ke spesifikasi sulit dalam spesifikasi, perilaku eksternal yang ditentukan selama analisis, struktur dan ranah dipahami struktur analisis membantu dalam spesifikasi, namun transisi tersebut belum final metode analisis yang mirip dengan perancangan, tetapi tujuan dan ruang lingkup yang berbeda analisis berkaitan dengan ranah masalah, sedangkan perancangan berkenaan dengan ranah solusi

15 A NALISIS P ERMASALAHAN Tujuan: untuk memperoleh pemahaman tentang keperluan, kebutuhan, dan batasan pada perangkat lunak Analisis melibatkan mewawancarai klien dan pengguna membaca manual mempelajari sistem saat ini membantu klien/pengguna memahami kemungkinan-kemungkinan baru Seperti menjadi konsultan Harus memahami kerja dari klien, organisasi dan pengguna

16 A NALISIS M ASALAH... Beberapa masalah Memperoleh informasi yang diperlukan Brainstorming : berinteraksi dengan klien untuk membahas sifat sistem yang diinginkan Pengaturan informasi, karena banyak informasi akan dikumpulkan Memastikan kelengkapan Memastikan konsistensi Menghindari rancangan internal

17 A NALISIS M ASALAH... Masalah interpersonal penting Keterampilan komunikasi sangat penting Prinsip dasar: masalah partisi Partisi Objek - analisis berorientasi objek Fungsi - analisis struktural Kejadian di sistem - partisi kejadian Proyeksi - mendapatkan sudut pandang yang berbeda Membahas beberapa teknik analisis yang berbeda

18 K ARAKTERISTIK DARI SRS Apa yang harus menjadi karakteristik SRS yang baik? Beberapa karakteristik utama  Lengkap  Tidak ambigu  Konsisten  Dapat diverifikasi  Diberi peringkat untuk kepentingan dan/atau stabilitas

19 K ARAKTERISTIK Kebenaran Setiap kebutuhan secara akurat mewakili beberapa fitur yang diinginkan dalam sistem akhir Kelengkapan Semua fitur yang diinginkan/karakteristik ditetapkan Paling sulit untuk dipenuhi Kelengkapan dan kebenaran sangat terkait Cukup jelas Setiap kebutuhan memiliki tepat satu arti Tanpa hal ini akan timbul banyak kesalahan Penting karena bahasa alami sering digunakan

20 K ARAKTERISTIK Dapat diverifikasi Harus ada cara yang efektif biaya untuk memeriksa apakah PL memenuhi kebutuhan Konsisten dua kebutuhan tidak bertentangan satu sama lain Peringkat untuk kepentingan / stabilitas Diperlukan prioritasi dalam konstruksi Untuk mengurangi risiko akibat perubahan kebutuhan

21 K OMPONEN SRS Apa yang harus terdapat dalam SRS? Menjelaskan ini akan membantu memastikan kelengkapan Sebuah SRS harus menentukan kebutuhan Fungsi Kinerja Kendala rancangan Antarmuka eksternal

22 K EBUTUHAN F UNGSIONAL Inti dokumen SRS; ini membentuk sebagian dari spesifikasi Menetapkan semua fungsionalitas yang sistem harus dukung Keluaran atas masukan yang diberikan dan hubungan antara mereka Semua operasi yang akan dilakukan sistem Harus menetapkan perilaku untuk masukan yang tidak valid juga

23 K EBUTUHAN K INERJA Semua batasan ( constraint ) kinerja pada sistem perangkat lunak Secara umum pada waktu respon, throughput, dll => dinamis Kebutuhan kapasitas => statis Harus dalam istilah terukur (bisa diverifikasi) Misalnya waktu respon harus xx 90% dari waktu keseluruhan

24 K ENDALA R ANCANGAN Faktor-faktor dalam lingkungan klien yang membatasi pilihan Beberapa batasan Standar kepatuhan dan kompatibilitas dengan sistem lain Keterbatasan Perangkat Keras Keandalan, toleransi kegagalan, kebutuhan cadangan. Keamanan

25 A NTARMUKA E KSTERNAL Semua interaksi perangkat lunak dengan orang, perangkat keras, dan PL Antarmuka pengguna yang paling penting Ini juga harus bisa diverifikasi

26 B AHASA S PESIFIKASI Bahasa harus mendukung karakteristik SRS yang diinginkan Bahasa formal tepat dan jelas tapi sulit Bahasa alami yang paling banyak digunakan, dengan beberapa struktur untuk dokumen Bahasa formal digunakan untuk fitur khusus atau dalam sistem yang sangat kritis

27 S TRUKTUR DARI SRS Pendahuluan Tujuan, sasaran dasar dari sistem Lingkup, apa yang sistem akan lakukan dan tidak lakukan Ikhtisar Deskripsi keseluruhan Perspektif Produk Fungsi Produk Karakteristik Pengguna Asumsi Kendala

28 S TRUKTUR DARI SRS Kebutuhan khusus Antarmuka eksternal Kebutuhan fungsional Kebutuhan kinerja Batasan rancangan Kriteria Diterima Sebaiknya ditentukan di depan. Standarisasi SRS ini dibuat oleh IEEE.

29 P ENDEKATAN U SE C ASE UNTUK KEBUTUHAN F UNGSIONAL Pendekatan tradisional untuk spesifikasi fungsi- menentukan fungsi masing-masing Use case adalah teknik baru untuk menentukan perilaku (fungsi) Yakni hanya berfokus pada spesifikasi fungsional Meskipun terutama untuk spesifikasi, dapat digunakan dalam analisis dan elisitasi Dapat digunakan untuk menentukan perilaku bisnis atau organisasi juga, meskipun kita akan fokus pada PL Cocok untuk sistem interaktif

30 D ASAR U SE C ASE Sebuah use case menentukan kontrak antara pengguna dan sistem tentang perilaku Pada dasarnya berbentuk tekstual; diagram hanya untuk mendukung Juga berguna dalam elisitasi kebutuhan karena pengguna menyukai dan memahami bentuk cerita dan bereaksi dengan mudah terhadap itu

31 D ASAR Aktor: seseorang atau sebuah sistem yang berinteraksi dengan sistem yang diusulkan untuk mencapai tujuan Contoh : Pengguna ATM (tujuan: mendapatkan uang), data operator entri; (tujuan: melakukan transaksi) Aktor adalah entitas logis, sehingga aktor penerima dan pengirim dibedakan (bahkan jika orangnya sama) Aktor dapat berupa orang atau sistem Aktor Primer: Aktor utama yang memulai UC UC adalah untuk memuaskan sasarannya Eksekusi yang sebenarnya dapat dilakukan oleh sistem atau orang lain atas nama aktor primer

32 D ASAR Skenario: satu set tindakan yang dilakukan untuk mencapai tujuan pada beberapa kondisi Aksi ditentukan sebagai urutan langkah-langkah Langkah adalah tindakan logis yang lengkap dilakukan baik oleh aktor atau sistem Skenario sukses utama – bila sesuatu berjalan normal dan tujuan tercapai Skenario alternatif: Ketika sesuatu salah dan tujuan tidak dapat dicapai

33 D ASAR Sebuah UC adalah kumpulan banyak skenario seperti itu Skenario mungkin menggunakan use case lain dalam langkah Tujuan sub-tujuan UC dapat dilakukan oleh UC lain UC dapat diatur secara hierarkis

34 D ASAR UC menentukan fungsi dengan menjelaskan interaksi antara aktor dan sistem Fokus pada perilaku eksternal UC terutama tekstual UC diagram menunjukkan UC, aktor, dan ketergantungan Hal-hal itu memberikan gambaran Deskripsi bergaya cerita yang mudah dipahami oleh pengguna dan analis UC tidak membentuk SRS lengkap, hanya bagian fungsionalitasnya

35 C ONTOH Use case 1: Beli saham Aktor Utama: Pembeli Tujuan pemangku kepentingan: Pembeli: ingin membeli saham Perusahaan: ingin informasi transaksi penuh Prakondisi: Pengguna sudah memiliki akun