REKAYASA PERANGKAT LUNAK 3 sks Sri Rezeki Candra Nursari reezeki2011.wordpress.com
Referensi Rekayasa Perangkat Lunak Pendekatan Praktisi, Roger S. Pressman, Ph.D, Andi Jogyakarta, 2012 Buku 1 Rekayasa Perangkat Lunak Pendekatan Praktisi, Roger S. Pressman, Ph.D, Andi Jogyakarta, 2012 Buku 2 Rekayasa Perangkat Lunak Analisa Kebutuhan Dalam, Daniel Siahaan, Andi Jogyakarta, 2012
Materi Perancangan, pembuatan, pengujian dan perawatan perangkat lunak serta pemrograman dengan bahasa tingkat tinggi. Siklus hidup perangkat lunak, Waterfall model, V model, Spiral model, Prototyping, prinsip dasar analisis kebutuhan, alur data, struktur data DSSD, Sistem Jackson, perangkat pembantu. Computer Aided Software Engineering (CASE) tools. Perancangan real time system. Analisis berorientasi objek, Pemodelan data, Metode formal, Pengantar perancangan dan implementasi
ANALISA KEBUTUHAN
ANALISIS KEBUTUHAN (Requirements Analysis) Analisis kebutuhan adalah serangkaian aktivitas yang dilakukan oleh berbagai pihak yang terkait dengan suatu proyek perangkat lunak, untuk menentukan persyaratan (requirements) yang dibutuhkan oleh user dan sistem, sehingga perangkat lunak yang dikembangkan berfungsi sebagaimana mestinya Hal ini tidak lepas dari proses rekayasa sistem (system engineering) dan proses rekayasa persyaratan (requirements engineering)
ANALISIS KEBUTUHAN (Requirements Analysis) Analisis kebutuhan merupakan proses menemukan, memperbaiki, memodelkan dan menspesifikasikan. Dengan kata lain bahwa analisa kebutuhan adalah sebuah proses untuk mendapatkan informasi, model, spesifikasi tentang perangkat lunak yang diinginkan klien/pengguna.
ANALISIS KEBUTUHAN (Requirements Analysis) Rekayasa persyaratan merupakan tahap yang sangat kritis dari proses perangkat lunak, karena kesalahan pada tahap ini akan menimbulkan masalah lain pada perancangan dan implementasi sistem. Hasilnya adalah dokumen persyaratan yang merupakan spesifikasi sistem.
ANALISIS KEBUTUHAN (Requirements Analysis) Persyaratan biasanya direpresentasikan pada dua tingkat perincian di dokumen ini. Pengguna akhir (end user) dan Pelanggan memerlukan pernyataan persyaratan tingkat tinggi; pengembang sistem memerlukan spesifikasi sistem yang lebih rinci
Proses Rekayasa Persyaratan Ada empat fase utama pada proses rekayasa persyaratan : 1. Studi kelayakan 2. Elisitasi dan analisis persyaratan 3. Spesifikasi persyaratan 4. Validasi Persyaratan
Fase Utama Pada Proses Rekayasa 1. Studi Kelayakan Persyaratan Studi ini seharusnya murah dan cepat. Yang dilakukan : Dibuat perkiraan mengenai apakah user yang diidentifikasi puas menggunakan perangkat lunak dan teknologi perangkat keras yang dipakai Memutuskan apakah sistem yang diusulkan efektif dalam hal biaya dari sudut pandang bisnis. Dana apakah sistem dapat dikembangkan dengan keterbatasan anggaran yang tersedia. Hasilnya Laporan Kelayakan - menginformasikan keputusan apakah kita akan terus dengan analisis yang lebih rinci, atau tidak
Fase Utama Pada Proses Rekayasa Persyaratan 2. Elisitasi dan Analisis Persyaratan Merupakan proses penurunan persyaratan sistem melalui observasi sistem yang ada. Proses ini melibatkan satu atau lebih model dan prototipe sistem. Hasil fase ini akan membantu analisis memahami sistem yang akan dispesifikasi.
Fase Utama Pada Proses Rekayasa Persyaratan 3. Spesifikasi Persyaratan Merupakan kegiatan menerjemahkan informasi yang dikumpulkan pada kegiatan analisis menjadi dokumen yang mendefinisikan serangkaian persyaratan. Ada 2 persyaratan :» Persyaratan user : pernyataan abstrak» Persyaratan sistem : deskripsi yang lebih rinci mengenai fungsionalitas yang akan diberikan
Fase Utama Pada Proses Rekayasa Persyaratan 4. Validasi Persyaratan Kegiatan ini memeriksa apakah persyaratan dapat direalisasikan, konsisten, dan lengkap. Pada proses ini, kesalahan pada dokumen persyaratan akan ditemukan dan diperbaiki.
Rekayasa Persyaratan Ada dua jenis persyaratan : 1. Persyaratan user (user requirements) pernyataan, dalam bahasa natural ditambah diagram, mengenai apa yang kita harapkan disediakan oleh sistem dan batasan operasinya 2. Persyaratan sistem (system requirements) menentukan layanan dan batasan sistem secara rinci. Dokumen persyaratan sistem (spesifikasi fungsional) harus tepat. Dokumen ini bisa berlaku sebagai kontrak antara pembeli dan pengembang perangkat lunak
Rekayasa Persyaratan 1. Persyaratan user (user requirements) Mendeskripsikan persyaratan fungsional dan nonfungsional sehingga dapat dipahami oleh user sistem yang tidak mempunyai pengalaman teknis yang rinci. Persyaratan user harus ditulis dengan bahasa natural, format dan diagram yang sederhana Persyaratan user lebih baik dipisah dari persyaratan sistem yang lebih rinci pada dokumen persyaratan. Jika tidak, pembaca persyaratan user yang non-teknis akan kewalahan dengan rincian yang hanya relevan bagi teknisi
Rekayasa Persyaratan 2. Persyaratan sistem (system requirements) Merupakan deskripsi yang lebih rinci dari persyaratan user. Persyaratan ini berfungsi sebagai dasar kontrak untuk implementasi sistem, sehingga harus merupakan spesifikasi yang lengkap dan konsisten dari sistem secara keseluruhan Hal-hal yang mengenai persyaratan sistem : Persyaratan ini digunakan oleh perekayasa perangkat lunak sebagai titik awal perancangan sistem. Spesifikasi persyaratan sistem dapat mencakup model-model sistem yang berbeda seperti model objek atau aliran data (DFD). Persyaratan sistem harus menyatakan apa yang harus dilakukan sistem, bukan bagaimana sistem tersebut diimplementasikan. Arsitektur awal sistem bisa didefinisikan untuk membantu struktur spesifikasi persyaratan. Persyaratan sistem disusun menurut subsistem-subsistem yang membangun sistem. Sistem harus berinter operasi dengan sistem lain yang ada. Hal ini membatasi perancangan dan batasan ini menimbulkan persyaratan untuk sistem yang baru
Rekayasa Persyaratan 2.Persyaratan sistem (system requirements) Bahasa natural seringkali dipakai untuk menulis spesifikasi persyaratan sistem, tapi dapat muncul masalah ketika bahasa natural digunakan untuk spesifikasi yang lebih rinci, yang dapat menimbulkan kesalahpahaman. Masalah ini muncul di proses perangkat lunak tahap berikutnya, dan pada saat itu, masalah tersebut sudah terlalu mahal untuk ditangani Untuk permasalahan di atas, dapat digunakan pendekatan lain, seperti bahasa persyaratan khusus, seperti bahasa natural terstruktur dan bahasa deskripsi rancangan
Produk perangkat lunak Produk perangkat lunak tersebut: Generik dibuat untuk dijual ke suatu kumpulan pengguna yang berbeda Bespoke (custom) dibuat untuk suatu pengguna tunggal sesuai dengan spesifikasinya.
Faktor analisa kebutuhan Ada 3 faktor yang harus dipenuhi ketika melakukan analisa kebutuhan ini yaitu : Lengkap artinya semua yang diharapkan oleh klien telah didapatkan oleh pihak yang melakukan analisa. Detail maksudnya adalah berhasil mengumpulkan informasi yang rinci sampai hal-hal yang kecil. Benar artinya data dari analisa kebutuhan ini haruslah benar, sesuai apa yang dimaksud oleh klien, bukan benar menurut apa yang difikirkan oleh pihak yang melakukan analisa.
Kebutuhan perangkat lunak Analisis kebutuhan perangkat lunak mencakup analisis terhadap : 1. Kebutuhan Fungsional (kebutuhan akan fungsifungsi) 2. Kebutuhan Non-Fungsional (kebutuhankebutuhan selain fungsi)
1. Kebutuhan Fungsional (Kebutuhan Akan Fungsi-Fungsi Pendefinisian layanan yang harus disediakan, bagaimana reaksi sistem terhadap input dan apa yang harus dilakukan sistem pada situasi khusus (Kebutuhan sistem dilihat dari kacamata pengguna)
2. Kebutuhan Non Fungsional (Kebutuhan Selain Fungsi-Fungsi Kendala pada pelayanan atau fungsi sistem seperti kendala waktu, kendala proses pengembangan, standard, dan lain lain Contoh: kehandalan, waktu respon dan kebutuhan storage. Contoh kendala seperti: Keterbatasan kemampuan peralatan I/O, representasi sistem dll.
3 tahap teknik kebutuhan perangkat lunak Teknik kebutuhan perangkat lunak meliputi 3 buah tahap, yakni, 1. elicitation (pengumpulan informasi), 2. specification (spesifikasi), 3. validation (validasi). [
1. Elicitation (pengumpulan informasi) Bertujuan untuk mengumpulkan sebanyak mungkin informasi mengenai problem domain, kesulitankesulitan klien dan user, serta apa yang sistem ingin lakukan untuk mereka. Metode : Wawancara Kuesioner Skenario Prototyping
2. Specification (spesifikasi) Informasi dari proses elicitation dianalisa dan direkam menggunakan teknik modeling dramatis dan tekstual untuk menunjukkan masalah dan solusi yang diajukan. Metode : Spesifikasi formal Protoyping
2. Specification (spesifikasi) Spesifikasi kebutuhan menjelaskan apa yang dapat dilakukan oleh suatu web site dan cakupan dari proyek Tujuan dari tahap spesifikasi kebutuhan adalah menentukan batasan kemampuan sistem. Analisis perangkat lunak dan perangkat keras Teknologi yang akan digunakan Pemilihan SO, Database yg digunakan Spesifikasi semua halaman Penentuan isi (content)
3. Validation (validasi) Mengecek kebutuhan yang telah direkam apakah telah berkaitan dengan tujuan stakeholder terhadap sistem. Metode : Wawancara Teknik kombinasi dari elicitation Inspeksi Fagan Prototyping