REKAYASA KEBUTUHAN SOFTWARE

Slides:



Advertisements
Presentasi serupa
Candra Irawan Dimas Bhirawa Fahrizky Syahrial Andri Daisy Rahmad
Advertisements

Proses-proses Perangkat Lunak
Jaminan Kualitas Perangkat Lunak Software Quality Assurance [SQA]
ANALISIS SISTEM.
PEMODELAN ANALISIS Kuliah - 5
SIKLUS HIDUP SISTEM Pertemuan Ke-7.
REKAYASA PERANGKAT LUNAK (Software Engineering) Eka Ismantohadi
REKAYASA KEBUTUHAN SOFTWARE
MODEL PEMBELAJARAN BERBASIS PROYEK (PROJECT BASED LEARNING)
Konsep Manajemen Proyek
Manajemen Mutu Perangkat Lunak
PERENCANAAN PROSES PERANGKAT LUNAK
PENGEMBANGAN SISTEM.
REKAYASA PERANGKAT LUNAK REQUIREMENTS ANALYSIS FUNDAMENTALS
Perancangan sistem ( berbasis objek )
Konsep & Prinsip Analisis
ANALISIS DAN DESAIN SISTEM INFORMASI
MODEL PEMBELAJARAN PENEMUAN (DISCOVERY LEARNING)
Analisis Persyaratan Perangkat Lunak dan Spesifikasi
Magister Teknik Industri – Universitas Indonesia
SOFTWARE REQUIREMENTS
Kelompok 5 : Asdin Ines Lestari Neng Susanti Siti Robiahtul Adawiyah Vena Senja Maba SOFTWARE REQUIREMENTS.
TEKNIK TESTING DAN STRATEGI TESTING
LAPORAN TUGAS AKHIR ANALISIS BESARNYA PENGARUH KINERJA PELAYANAN (SERVICE PERFORMANCE) FRONTLINER DAN KEPUASAN NASABAH TERHADAP LOYALITAS NASABAH PRIORITAS.
PROCESS MODELS.
Manajemen Proyek Web.
Materi Sesi ke 8 Pengembangan Sistem Informasi Manajemen
ANALISIS DAN PERANCANGAN SISTEM (APS)
Rekayasa Perangkat Lunak Model Proses PL
1 DASAR-DASAR SISTEM INFORMASI DALAM BISNIS CHAPTER
REKAYASA PERANGKAT LUNAK
Konsep dan Prinsip Analisis
Chapter 7. Requirements Negotiation
Pengantar Analisis Bisnis & Kompetensi Analis Bisnis
ENTOT SUHARTONO, SKOM, MKOM
Sistem Pendukung Keputusan
KONSEP DAN PRINSIP ANALISIS
4 Managing Software Requirement Analisis Kebutuhan
Memahami Proses Pemasaran Dan Perilaku Konsumen
Penyimpanan dan Tatakelola Arsitektur
Jaminan Mutu dalam Kebutuhan Rekayasa
Persyaratan Rekayasa Proses
Rekayasa Perangkat Lunak Dosen : Citra Noviyasari, S.Si, MT
TUGAS PENGENDALIAN DAN PENJAMINAN MUTU
Disusun Oleh: Defri Kurniawan, M.Kom Teknik Informatika UDINUS
Pengembangan Sistem Informasi
JAMINAN KUALITAS PERANGKAT LUNAK (SOFTWARE QUALITY ASSURANCE)
Requirement Document.
Metode Pengembangan Arsitektur
Analisis Arsitektur Enterprise
Rekayasa Perangkat Lunak Dosen : Citra Noviyasari, S.Si, MT
Rekayasa Kebutuhan Software
PENGEMBANGAN SISTEM Muhammad Hidayat, SE.
BAB 2 KONSTRUKSI & BISINS PROSES
PERTEMUAN 2 Proses Pengembangan Perangkat Lunak
Pemodelan Proses Bisnis by : Sol’s
Analisis Persyaratan System
Pengembangan Kebutuhan Bisnis
Rekayasa Kebutuhan.
Pertemuan 8 Rekayasa Kebutuhan
ANALISA KEBUTUHAN PERANGKAT LUNAK
MODEL PEMBELAJARAN PENEMUAN (DISCOVERY LEARNING)
Review Materi IK305 Infrastruktur Teknologi Informasi
PENGEMBANGAN SISTEM.
Analisis Persyaratan Perangkat Lunak dan Spesifikasi
ADI PRIHANDONO, SKOM, MKOM
Metode Pengembangan Arsitektur
Analisis Arsitektur Enterprise
KEMENTERIAN PENDIDIKAN DAN KEBUDAYAAN BADAN PENGEMBANGAN SUMBER DAYA MANUSIA PENDIDIKAN DAN KEBUDAYAAN DAN PENJAMINAN MUTU PENDIDIKAN MODEL PEMBELAJARAN.
Pengembangan Sistem Informasi Erliyan Redy Susanto.
Transcript presentasi:

REKAYASA KEBUTUHAN SOFTWARE

Dasar – Dasar

Definisi software requirement adalah sebuah properti yang harus diperlihatkan /ditunjukkan oleh software untuk menyelesaikan suatu permasalahan yang ada di dunia nyata / bersifat riil. merupakan kombinasi rumit dari kebutuhan berbagai orang di bermacam – macam tingkat organisasi dan lingkungan di mana perangkat lunak akan dioperasikan. properti yang esensial dari semua software requirement adalah harus mampu diperiksa/diverifikasi.

Product and Process requirement Parameter produk adalah requirement pada software untuk dikembangkan (Contohnya “Software harus memeriksa prasyarat mata kuliah yang diambil mahasiswa”) Parameter proses adalah batasan – batasan dalam mengembangkan software. Contohnya pilihan teknik verifikasi. Process requirement juga bisa ditetapkan oleh organisasi pengembang, pelanggan atau pihak ketiga seperti badan regulator.

Requirement fungsional dan nonfungsional Requirments fungsional menjabarkan fungsi – fungsi yang akan dilaksanakan software. Contohnya memformat teks. Kadang – kadang disebut juga sebagai kapabilitas. Requirements non-fungsional memberikan batasan terhadap solusi yang akan dihasilkan. Disebut juga sebagai quality requirement. Requirement jenis ini masih bisa dibagi lagi menjadi performance requirements, maintainability requirements, safety requirements, reliability requirements atau salah satu software requirements lainnya.

Emergent Properties Beberapa requirement merupakan perwakilan dari emergent properties yaitu requirement yang tidak bisa ditangani oleh satu komponen saja. Keberhasilan dalam menanganinya juga bergantung pada interoperasi dari berbagai komponen yang ada. Emergent properties amat bergantung pada arsitektur sistem.

Quantifiable Requirements Software requirement harus bisa dinyatakan dengan jelas, tidak ambigu dan pada beberapa bagiannya yang sesuai, kuantitatif. Contoh requirement yang memenuhi syarat: Sebuah perangkat lunak dari suatu call central harus meningkatkan throughput sebanyak 20% dan sistemnya hanya menghasilkan kesalahan fatal dengan peluang kurang dari 1*10-8.

System Requirements dan Software Requirements Dalam topik ini sistem berarti kombinasi dari elemen – elemen yang berinteraksi untuk mencapai suatu tujuan yang terdefinisikan. Ini termasuk hardware, software, firmware, manusia, informasi, tehnik, fasilitas, layanan dan berbagai elemen pendukung lainnya System requirement adalah requirement untuk sistem secara keseluruhan. Dalam sebuah sistem yang mengandung komponen software, software requirement diperoleh dari system requirement.

Requirement Process

Process Models Bukan kegiatan berawal – berakhir secara diskrit tetapi dimulai dari awal suatu proyek dan terus diperhalus selama siklus hidup software. Mengidentifikasi software requirement sebagai konfigurasi item – item dan mengaturnya dengan praktik – praktik manajemen konfigurasi software yang sama dengan produk – produk lain dari proses – proses siklus hidup software tersebut. Perlu diadaptasikan sesuai dengan konteks organisasi dan proyek.

Process Actors Pengguna : kelompok yang kelak akan mengoperasikan software. Pelanggan : Kelompok inilah yang akan memberlakukan suatu software ke dalam suatu organisasi. Analis Pasar : Analis pasar diperlukan untuk mengetahui kebutuhan pasar. Regulator : Banyak bidang di mana aplikasi terkena regulasi misalnya perbankan dan transportasi umum. Karenanya software yang dioperasikan pada bidang – bidang semacam ini harus sesuai dengan ketentuan dari badan regulator yang berwenang. Perekayasa software : Kelompok ini memiliki hak yang sah untuk mengambil keuntungan dari pengembangan suatu software, termasuk menggunakan ulang beberapa komponennya untuk produk lain.

Process Quality and Improvement Membahas penilaian kualitas dan peningkatan dari suatu requirement process. Tujuannya adalah untuk menekankan peran kunci requirement process dari segi biaya dan masa berlaku suatu produk software dan kepuasan pelanggan.

Requirements Elicitation

Sumber – Sumber Requirements Tujuan. Tujuan bisa memberi motivasi bagi pembuatan software tetapi sayangnya sering diformulasikan secara samar. Karenanya perlu dinilai biaya dan nilainya secara jelas. Pengetahuan akan domain. Seseorang perekayasa software harus mengetahui domain dari aplikasi yang dikerjakannya. Pihak yang berkepentingan. Banyak software yang tidak memuaskan karena terlalu condong pada kepentingan pihak tertentu saja dan mengorbankan pihak lain. Hendaknya dipahami dan dicapai keseimbangan dari sudut pandang tiap pihak.

Sumber – Sumber Requirements Lingkungan operasional. Requirement akan disusun dari lingkungan di mana software akan bekerja. Misalnya batasan timing untuk real – time software atau kemampuan interoperasional Lingkungan organisasional. Seringakali suatu software dibuat untuk menunjang proses bisnis. Karenanya perlu diperhatikan struktur, budaya kerja dan situasi politik dari organisasi yang bersangkutan.

Elicitation Techniques Wawancara. Merupakan tehnik yang paling tradisional. Perlu diketahui batasan dan tata caranya. Skenario. Tehnik ini mampu memberikan konteks untuk menyusun requirement bagi pengguna. Memberikan kerangka kerja bagi perekayasa software dengan membolehkan pertanyaan seperti “Bagaimana jika…” atau “Bagaimana ini dikerjakan”. Prototipe. Tehnik ini bisa memberi kejelasan pada requirement yang masih kabur. Tehnik ini bertindak mirip dengan skenario karena bisa memberikan konteks di mana pengguna bisa tahu informasi apa yang harus diberikan.

Elicitation Techniques Pertemuan terfasilitasi. Tehnik ini baik untuk menghimpun pandangan berbagai pihak yang berkepentingan. Bisa pula timbul – saran atau ide yang membantu. Selain itu juga bisa mengenali konflik antar requirement. Tetapi pertemuan sebaiknya menggunakan jasa seorang fasilitator untuk mencegah / mengendalikan kemungkinan dominasi pihak tertentu. Observasi. Tehnik ini relatif mahal tapi wajib karena mungkin saja proses bisnis terlau kompleks dan canggih untuk dijelaskan secara lisan. Perekayasa software harus masuk ke dalam lingkungan kerja pengguna dan mengamati interaksi pengguna dengan software dan sesama pengguna lain.