1 / 69

Analisis K ebutuhan dan Spesifikasi Perangkat Lunak

Analisis K ebutuhan dan Spesifikasi Perangkat Lunak. Latar Belakang. Masalah skala merupakan isu kunci untuk PL Untuk skala kecil, sangat mudah untuk memahami dan menentukan kebutuhan

bevis
Download Presentation

Analisis K ebutuhan dan Spesifikasi Perangkat Lunak

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Analisis Kebutuhan dan 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 kebutuhanberakhir dengan dokumen spesifikasi kebutuhan perangkat lunak (SRS) • SRS menentukan apa yang harusdilakukansistem yang diusulkan

  4. Latar Belakang .. • Sulitnya memahami kebutuhan • Visualisasi sistem yang akandibangunadalah sulit • Kemampuan dari sistem yang akandibanguntidak jelas, maka kebutuhan tidak jelas • kebutuhan berubah sewaktu-waktu • ... • Penting untuk melakukan analisis danspesifikasi kebutuhan yang tepat

  5. PerlunyaSRS • 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. PerlunyaSRS ... • Membantu pengguna memahami keperluannya. • pengguna tidak selalu tahu keperluan mereka • harus menganalisisdan memahami potensi • tujuannya adalah tidak hanya untuk mengotomatisasi sistem manual, tetapi juga untuk menambahkan nilai melalui TI • Proses kebutuhanmembantu memperjelas keperluan • SRS menyediakan referensi untuk validasi dari produk akhir • Pemahaman yang jelastentang apa yang diharapkan. • Validasi - “PL memenuhi SRS"

  7. PerlunyaSRS... • SRS yang bermututinggi penting untuk PL yang bermututinggi • Kesalahan kebutuhan akandiwujudkan 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. PerlunyaSRS ... • SRS yang baik mengurangi biaya pengembangan • Kesalahan SRS mahal untuk diperbaiki kemudian • Perubahan kebutuhanmemerlukanbiaya besar(hingga 40%) • SRS yang baik dapat meminimalkan perubahan dan kesalahan • Penghematan substansial; upaya ekstra yang dihabiskan selama fasekebutuhan 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. PerlunyaSRS... • Contoh ... • Setelah fase kebutuhan65% kesalahankebutuhan terdeteksi dalam perancangan, 2% dalam pemrograman, 30% dalam pengujian penerimaan, 3% selama operasi • Jika 50 kesalahan kebutuhan tidak dihilangkan dalam fasekebutuhan, total biaya 32,5 * 5 + 1 * 15 + 15 * 50 + 1,5 * 150 = 1152 jam • Jika 100 orang-jam tambahan diinvestasikan dalamfasekebutuhanuntuk menangkap 50 cacatini, 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 keperluanpengguna menjadiSRS • Proses iniharusmenggalikeperluandan kebutuhan dan menetapkannyadenganjelas • KegiatanDasar • analisis masalah atau kebutuhan • spesifikasi kebutuhan • validasi • Analisis melibatkan elisitasi/penggalian dan yang paling sulit

  11. ProsesKebutuhan.. needs Analysis Specification Requirements Validation

  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 sertakebutuhannya • Membagi dan menaklukkan adalah strategi dasarnya • urai menjadi bagian-bagian kecil, fahami setiap bagian serta hubungan antara bagian-bagian • volume informasi yang dihasilkan besar • mengorganisasiinformasi adalah kunci • Teknik seperti diagram aliran data, diagram objek dll yang digunakan dalam analisis

  14. kebutuhan Proses .. • Transisi dari analisis kespesifikasi sulit • dalam spesifikasi, perilaku eksternal yang ditentukan • selama analisis, struktur dan ranah dipahami • struktur analisis membantu dalam spesifikasi, namun transisitersebut belum final • metode analisis yang mirip dengan perancangan, tetapi tujuan dan ruang lingkup yang berbeda • analisis berkaitan dengan ranah masalah, sedangkan perancanganberkenaandengan ranah solusi

  15. Analisis Permasalahan • Tujuan: untuk memperoleh pemahaman tentang keperluan, kebutuhan, dan batasanpada perangkat lunak • Analisis melibatkan • mewawancarai klien dan pengguna • membaca manual • mempelajari sistem saat ini • membantu klien/pengguna memahamikemungkinan-kemungkinan baru • Seperti menjadi konsultan • Harus memahami kerja dari klien, organisasi dan pengguna

  16. Analisis Masalah ... • Beberapa masalah • Memperoleh informasi yang diperlukan • Brainstorming: berinteraksi dengan klien untuk membahassifat sistemyang diinginkan • Pengaturaninformasi, karenabanyak informasiakan dikumpulkan • Memastikan kelengkapan • Memastikan konsistensi • Menghindari rancanganinternal

  17. Analisis Masalah ... • Masalah interpersonal penting • Keterampilan komunikasi sangat penting • Prinsip dasar: masalah partisi • Partisi • Objek - analisis berorientasiobjek • Fungsi - analisis struktural • Kejadian di sistem - partisi kejadian • Proyeksi - mendapatkan sudut pandang yang berbeda • Membahas beberapa teknik analisis yang berbeda

  18. Karakteristik dari SRS • Apa yang harus menjadi karakteristik SRS yang baik? Beberapa karakteristikutama • Lengkap • Tidakambigu • Konsisten • Dapat diverifikasi • Diberi peringkat untuk kepentingan dan/atau stabilitas

  19. Karakteristik • Kebenaran • Setiap kebutuhan secara akurat mewakili beberapa fitur yang diinginkan dalam sistem akhir • Kelengkapan • Semua fitur yang diinginkan/karakteristik ditetapkan • Paling sulituntuk dipenuhi • Kelengkapan dan kebenaran sangat terkait • Cukup jelas • Setiap kebutuhanmemiliki tepat satu arti • Tanpa halini akan timbulbanyakkesalahan • Pentingkarenabahasa alami sering digunakan

  20. Karakteristik • 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 prioritasidalam konstruksi • Untuk mengurangi risiko akibat perubahan kebutuhan

  21. Komponen SRS • Apa yang harus terdapatdalamSRS? • Menjelaskan ini akan membantu memastikan kelengkapan • Sebuah SRS harus menentukan kebutuhan • Fungsi • Kinerja • Kendalarancangan • Antarmuka eksternal

  22. Kebutuhan Fungsional • Intidokumen SRS; ini membentuk sebagian dari spesifikasi • Menetapkan semua fungsionalitasyang sistem harus dukung • Keluaranatas masukan yang diberikan dan hubungan antara mereka • Semua operasi yang akandilakukansistem • Harus menetapkan perilaku untuk masukanyang tidak valid juga

  23. 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 (bisadiverifikasi) • Misalnya waktu responharus xx 90% dari waktukeseluruhan

  24. KendalaRancangan • Faktor-faktor dalam lingkungan klien yang membatasi pilihan • Beberapa batasan • Standar kepatuhan dan kompatibilitas dengan sistem lain • Keterbatasan Perangkat Keras • Keandalan, toleransi kegagalan, kebutuhancadangan. • Keamanan

  25. Antarmuka Eksternal • Semua interaksi perangkat lunak dengan orang,perangkat keras, dan PL • Antarmuka pengguna yang paling penting • Ini juga harus bisadiverifikasi

  26. Bahasa Spesifikasi • Bahasa harus mendukung karakteristikSRS yang diinginkan • Bahasa formal tepat dan jelas tapi sulit • Bahasa alamiyang paling banyak digunakan, dengan beberapa struktur untuk dokumen • Bahasa formal digunakan untuk fitur khusus atau dalam sistem yang sangat kritis

  27. Struktur dari SRS • Pendahuluan • Tujuan, sasarandasar dari sistem • Lingkup, apa yang sistem akanlakukandantidak lakukan • Ikhtisar • Deskripsi keseluruhan • Perspektif Produk • FungsiProduk • Karakteristik Pengguna • Asumsi • Kendala

  28. Struktur dari SRS • Kebutuhan khusus • Antarmuka eksternal • Kebutuhan fungsional • Kebutuhan kinerja • Batasanrancangan • Kriteria Diterima • Sebaiknyaditentukan didepan. • Standarisasi SRS ini dibuatoleh IEEE.

  29. Pendekatan Use Caseuntuk kebutuhan Fungsional • Pendekatan tradisional untuk spesifikasi fungsi- menentukan fungsi masing-masing • Use caseadalah teknik baru untuk menentukan perilaku (fungsi) • Yaknihanya 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. DasarUse Case • Sebuah use casemenentukankontrak antara pengguna dan sistem tentang perilaku • Pada dasarnya berbentuk tekstual; diagram hanya untuk mendukung • Juga berguna dalam elisitasi kebutuhan karenapengguna menyukaidan memahami bentuk cerita dan bereaksi dengan mudah terhadapitu

  31. Dasar • Aktor: seseorang atau sebuah sistem yang berinteraksi dengan sistem yangdiusulkan 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 orangnyasama) • Aktordapat berupaorang atau sistem • AktorPrimer: 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. Dasar • Skenario: satu set tindakan yang dilakukan untuk mencapai tujuan padabeberapa kondisi • Aksiditentukan sebagai urutan langkah-langkah • Langkah adalah tindakan logis yang lengkap dilakukan baik oleh aktor atau sistem • Skenario suksesutama – bila sesuatu berjalannormal dan tujuan tercapai • Skenario alternatif: Ketika sesuatu salah dan tujuan tidak dapat dicapai

  33. Dasar • Sebuah UC adalah kumpulan banyak skenario sepertiitu • Skenario mungkin menggunakanuse caselain dalam langkah • Tujuan sub-tujuan UC dapat dilakukan oleh UClain • UC dapat diatur secara hierarkis

  34. 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-halitumemberikan gambaran • Deskripsi bergayaceritayang mudah dipahami oleh pengguna dan analis • UC tidak membentuk SRS lengkap, hanya bagian fungsionalitasnya

  35. Contoh Use case 1: Beli saham Aktor Utama: Pembeli Tujuan pemangkukepentingan: Pembeli: ingin membeli saham Perusahaan: ingin informasi transaksi penuh Prakondisi: Pengguna sudah memiliki akun

  36. Contoh • Skenario SuksesUtama • Pengguna memilih untuk membeli saham • Sistem mendapatkan nama situs web daripengguna untuk perdagangan • Menetapkan Koneksi • Pengguna menelusuri dan membeli saham • Sistem penyadapan tanggapan dari situs dan portofolio update pengguna • Sistem menunjukkan stading pengguna portofolio baru

  37. Contoh Alternatif • 2a: Sistem memberikan pesan kesalahan, meminta saran baru untuk situs, memberikan pilihan untuk membatalkan • 3a: kegagalan Web. • 1-Sys laporan kegagalan untuk pengguna, punggung sampai ke langkah sebelumnya. • 2-Pengguna keluar atau mencoba lagi • 4a: crash Komputer • 4b: situs web tidak membeli ack • 5a: situs web tidak kembali informasi yang dibutuhkan

  38. Contoh 2 • Gunakan Kasus 2: Beli produk • Primer aktor: pembeli / pelanggan • Tujuan: membeli produk beberapa • Prekondisi: Pelanggan sudah login

  39. Contoh 2 Skenario Utama• Pelanggan menelusuri dan memilih item • Pelanggan pergi ke kasir • Pelanggan mengisi pilihan pengiriman • Sistem menyediakan informasi harga penuh • Pelanggan mengisi informasi kartu kredit • Sistem mengotorisasi pembelian • Sistem menegaskan penjualan • Sistem mengirimkan email konfirmasi

  40. Contoh 2 Alternatif • 6a: otorisasi kartu kredit gagal • Memungkinkan pelanggan untuk masuk kembali informasi • 3a: pelanggan Reguler • Sistem menampilkan terakhir 4 digit kartu kredit tidak ada • Meminta pelanggan untuk OK itu atau mengubahnya • Bergerak ke langkah 6

  41. Contoh - Sebuah situs lelang • Gunakan Case1: Masukan item untuk lelang • Primer Aktor: Penjual • Prekondisi: Penjual telah login • Skenario Utama Sukses: • Penjual posting item (kategorinya, keterangan, image, dll) untuk lelang • Sistem menunjukkan harga masa lalu barang serupa kepada penjual • Sistem menentukan harga penawaran awal dan tanggal ketika lelang akan menutup • Sistem menerima item dan posting itu • Pengecualian Skenario: - 2 a) Tidak ada item terakhir dari kategori ini * Sistem memberitahu penjual situasi ini

  42. Contoh - situs lelang • Gunakan Case2: Buatlah tawaran • Primer Aktor: Pembeli • Prekondisi: Pembeli telah login • Skenario Utama Sukses: • dan memilih beberapa itemPembeli pencarian atau menelusuri • Sistem menunjukkan peringkat penjual, tawaran awal, tawaran saat ini, dan tawaran tertinggi; meminta pembeli untuk melakukan penawaran • Pembeli menentukan harga penawaran, harga max tawaran, dan kenaikan • Sistem menerima tawaran; dana Blok dalam account penawar • Sistem update harga tawaran penawar lain di mana diperlukan, dan update catatan untuk item

  43. Pengecualian Skenario: • - 3 a) Harga penawaran lebih rendah dari tertinggi saat ini • * Sistem penawar menginformasikan dan meminta untuk rebid • - 4 a) penawar yang tidak memiliki cukup dana dalam account-nya • * Sistem membatalkan tawaran, meminta user untuk mendapatkan lebih banyak dana

  44. Contoh-situs lelang • Gunakan Case3: lelang Lengkap item • Primer Aktor: Sistem Lelang • Prekondisi: Tanggal terakhir untuk penawaran telah tercapai • Skenario Utama Sukses: • penawar tertinggi Pilih; mengirim email kepada penawar yang dipilih dan penjual menginformasikan harga penawaran akhir, mengirim email ke penawar lain juga penawar Debit dan kredit rekening penjual akun • Transfer dari jumlah komisi penjual rekening ke rekening organisasi • blok dana lainnya penawar • Hapus item dari situs; catatan pembaruan • Pengecualian Skenario: Tidak ada

  45. Contoh - ringkasan tingkat Use Case • Gunakan Kasus 0: Lelang item • Primer Aktor: Sistem Lelang • Lingkup: Lelang organisasi melakukan • Prekondisi: Tidak ada • Skenario Utama Sukses: • Penjual melakukan menempatkan item untuk lelang • Berbagai bidder melakukan penawaran • Pada tanggal akhir Lengkapi melakukan lelang item • Dapatkan umpan balik dari penjual; mendapatkan umpan balik dari pembeli; memperbarui catatan

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

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

  48. Mengembangkan • Langkah 3: Identifikasi kondisi kegagalan • kondisi kegagalan yang mungkin untuk UCSDaftar • 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

  49. Pendekatan Analisis Lainnya

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

More Related