Presentasi sedang didownload. Silahkan tunggu

Presentasi sedang didownload. Silahkan tunggu

Spesifikasi Perangkat Lunak

Presentasi serupa


Presentasi berjudul: "Spesifikasi Perangkat Lunak"— Transcript presentasi:

1 Spesifikasi Perangkat Lunak

2 Latar Belakang 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 Latar Belakang .. 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 Latar Belakang .. 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 Perlunya 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 Perlunya 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 Perlunya 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 Perlunya SRS ... SRS yang baik mengurangi biaya pengembangan Contoh
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 Perlunya 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 * 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 Proses Kebutuhan 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 Proses Kebutuhan.. needs Analysis Specification Validation
Requirements

12 Proses Kebutuhan .. 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 Proses 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 Proses .. 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 Karakteristik 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

16 Karakteristik Kebenaran Kelengkapan Cukup jelas
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

17 Karakteristik Dapat diverifikasi Konsisten
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

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

19 Kebutuhan Fungsional 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

20 Kebutuhan Kinerja 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

21 Batasan Rancangan 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

22 Antarmuka Eksternal Semua interaksi perangkat lunak dengan orang, perangkat keras, dan PL Antarmuka pengguna yang paling penting Ini juga harus bisa diverifikasi

23 Bahasa Spesifikasi 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

24 Struktur dari SRS Pendahuluan Deskripsi keseluruhan
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

25 Struktur dari SRS Kebutuhan khusus Kriteria Diterima
Antarmuka eksternal Kebutuhan fungsional Kebutuhan kinerja Batasan rancangan Kriteria Diterima Sebaiknya ditentukan di depan. Standarisasi SRS ini dibuat oleh IEEE.

26 Pendekatan Use Case untuk kebutuhan Fungsional
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

27 Dasar Use Case 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

28 Dasar 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

29 Dasar 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

30 Dasar 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

31 Dasar 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

32 kebutuhan dengan Gunakan Kasus
UCS menentukan kebutuhan fungsional req lain yang diidentifikasi secara terpisah Sebuah SRS lengkap akan berisi kasus penggunaan ditambah kebutuhan lain Catatan - untuk kebutuhan sistem adalah penting untuk mengidentifikasi UCS yang sistem sendiri mungkin aktor Mengembangkan Gunakan Kasus UCS membentuk media yang baik untuk brainstorming dan diskusi Oleh karena itu dapat digunakan dalam elisitasi dan analisis masalah juga UCS dapat dikembangkan dalam cara bertahap penyempurnaan tingkat Banyak mungkin, tapi empat alami muncul

33 Mengembangkan Langkah 1: Mengidentifikasi aktor dan tujuan Siapkan daftar aktor-tujuan Memberikan gambaran singkat dari UC ini mendefinisikan ruang lingkup sistem Kelengkapan juga dapat dievaluasi Langkah 2: Tentukan Sukses Skenario utama Untuk setiap UC, memperluas skenario utama ini akan memberikan perilaku normal dari sistem Dapat terakhir untuk memastikan bahwa kepentingan semua pemangku kepentingan dan aktor terpenuhi

34 Mengembangkan Langkah 3: Identifikasi kondisi kegagalan
kondisi kegagalan yang mungkin untuk UCS Daftar Untuk setiap langkah, mengidentifikasi bagaimana mungkin gagal Langkah ini menyingkap situasi khusus Langkah 4: Tentukan penanganan kegagalan Mungkin bagian paling sulit Menentukan perilaku sistem untuk kondisi kegagalan aturan bisnis baru dan aktor mungkin muncul

35 Data Flow Modeling Banyak digunakan; berfokus pada fungsi yang dilakukan dalam sistem Dilihat sistem sebagai jaringan data mengubah data melalui mana mengalir Menggunakan diagram aliran data (DFD) dan dekomposisi fungsional dalam pemodelan Metodologi SSAD menggunakan DFD untuk mengatur informasi, dan analisis panduan

36 diagram aliran data Sebuah DFD menunjukkan aliran data melalui sistem
Dilihat sistem sebagai transformasi input ke output Transformasi dilakukan melalui transformasi DFD menangkap bagaimana transformasi terjadi dari input ke output sebagai memindahkan data melalui transformasi Tidak terbatas pada perangkat lunak

37 aliran data diagram DFD
Mentransformasi diwakili oleh lingkaran bernama / gelembung Bubbles dihubungkan dengan panah pada yang bernama perjalanan Data Sebuah persegi panjang merupakan sumber atau tenggelam dan pencetus / konsumen data (sering di luar sistem)

38 DFD Konvensi Eksternal file ditampilkan sebagai garis lurus berlabel
Perlu untuk arus beberapa data dengan proses diwakili oleh * (sarana dan) ATAU hubungan diwakili oleh Semua proses dan anak panah harus dinamai Proses harus mewakili transformasi, panah harus mewakili beberapa data

39 aliran data diagram Fokus pada apa yang mentransformasikan terjadi, bagaimana mereka dilakukan adalah tidak penting Biasanya input utama / output ditampilkan, kecil diabaikan dalam pemodelan ini Tidak loop, berpikir bersyarat, ... DFD TIDAK peta kendali, tidak ada desain algoritmik / berpikir Sink / Source, eksternal file

40 Menggambar DFD untuk sistem
Mengidentifikasi input, output, sumber, sink untuk sistem Cara kerja Anda secara konsisten dari input ke output, dan mengidentifikasi beberapa tingkat tinggi untuk menangkap mengubah transformasi penuh Jika terjebak, arah sebaliknya Ketika tingkat tinggi mengubah ditetapkan, maka masing-masing menyempurnakan mengubah dengan transformasi lebih rinci

41 Menggambar DFD untuk sistem
Jangan pernah menampilkan logika kontrol, jika berpikir dalam hal loop / keputusan, berhenti & me-restart setiap panah dan gelembung; cermat mengidentifikasi input dan output dari masing-masing mengubah Label Manfaatkan + & * Cobalah menggambar DFD alternatif

42 diratakan DFD DFD dari sistem mungkin sangat besar
Dapatkah mengatur itu secara hierarkis Mulailah dengan DFD tingkat atas dengan beberapa gelembung kemudian menarik DFD untuk setiap gelembung Pertahankan I / O saat "meledak" sebuah gelembung sehingga konsistensi diawetkan Membuat gambar diratakan DFD proses penyempurnaan top-down, dan memungkinkan pemodelan sistem yang besar dan kompleks

43 Kamus Data Dalam DFD panah diberi label dengan item data
data kamus mendefinisikan data yang mengalir di DFD Menunjukkan struktur data, struktur menjadi lebih terlihat saat meledak Dapat menggunakan ekspresi reguler untuk mengekspresikan struktur data

44 Contoh Kamus DataUntuk DFD Timesheet
Weekly_timesheet - employee_name + id + [regular_hrs + overtime_hrs] * Pay_rate = [jam | hari | mingguan] + dollar_amt Employee_name = terakhir + pertama + tengah Id = angka + digit + angka + digit

45 DFD menggambar - kesalahan umum
berlabel data mengalir Data Hilang mengalir asing data mengalir Konsistensi tidak dipelihara selama perbaikan proses Hilang Terlalu rinci atau terlalu abstrak Berisi beberapa informasi kontrol

46 Prototyping Prototyping adalah pendekatan lain untuk analisis masalah
Dibahas itu sebelumnya dengan proses - mengarah ke model proses prototyping

47 Prototyping kebutuhan Validasi Banyak ruang untuk kesalahpahaman
memungkinkan Kesalahan Mahal untuk memperbaiki cacat req kemudian Harus mencoba untuk menghapus sebagian kesalahan dalam SRS Paling umum kesalahan Penghapusan - 30% Inkonsistensi % % Bahkan salah Prototyping Ambiguitas %

48 Tinjauan Kebutuhan SRS ditinjau oleh sekelompok orang
Kelompok: penulis, klien, pengguna, perwakilan tim pengembang Harus termasuk klien dan pengguna Proses - proses pemeriksaan standar Efektivitas - bisa menangkap 40-80% dari kesalahan kebutuhan

49 Ringkasan Memiliki kualitas SRS yang baik sangat penting untuk M&P
Fase kebutuhan memiliki 3 sub fase utama analisis, spesifikasi dan validasi Analisis untuk memahami masalah dan pemodelan Metode yang digunakan: SSAD, OOA, Prototyping Karakteristik utama dari suatu SRS: kebenaran, kelengkapan, konsistensi, ketidakambiguan

50 Ringkasan Spesifikasi harus berisi fungsionalitas, kinerja, interface dan kendala desain Sebagian besar bahasa alami yang digunakan Use case adalah metode untuk menentukan fungsi, juga berguna untuk analisis Validasi - melalui review


Download ppt "Spesifikasi Perangkat Lunak"

Presentasi serupa


Iklan oleh Google