REKAYASA PERANGKAT LUNAK

(RPL)

Materi 4
Konsep & Prinsip Analisis
 Tujuan Analisis Sistem
Mendefinisikan masalah secara tepat
Menyusun alternatif penyelesaian
 Memilih dan mempertimbangkan satu dari alternatif
tersebut
 Menyusun spesifikasi logis untuk penyelesaian
Menyusun persyaratan fisik untuk penyelesaian
Menyusun anggaran untuk fase desain sistem
pengkodean dan implementasi sistem
 Pihak-Pihak Yang Terlibat
Ahli sistem lingkungan kerja dan software
Konsultan
Akuntan
Auditor eksternal 
 Rekayasa Kebutuhan (1)
Permulaan—tanya beberapa pertanyaan yang menjelaskan:
 Pemahaman dasar dari masalah
 Orang yang membutuhkan solusi
 Keadaan dari solusi yang diinginkan
 Efektivitas komunikasi dan kolaborasi awal antara konsumen dengan developer
Perolehan—memperoleh kebutuhan dari semua stakeholder
Penguraian—membuat model analisis yang mampu melakukan
identifikasi kebutuhan data, fungsi dan perilaku
Negosiasi—menyepakati sistem penyajian yang realistis bagi
konsumen dan developer
 Rekayasa Kebutuhan (2)
Spesifikasi—salah satu dari berikut ini:
 Dokumen tertulis
 Sekelompok model
 Matematika formal
 Sekumpulan skenario user (use-cases)
 Prototipe
Validasi—memeriksa mekanisme yang memuat
 Kesalahan isi atau interpretasi
 Area dimana klarifikasi dibutuhkan
 Informasi yang hilang
 inkonsistensi (masalah utama ketika produk atau sistem besar direkayasa)
 Kebutuhan yang konflik atau tidak realistis.
Manajemen Kebutuhan
  
Teknik Komunikasi

Kenali stakeholder
 “who else do you think I should talk to?”
Kenali beberapa sudut pandang
Berusahalah menuju kolaborasi
Pertanyaan pertama
 di belakang permintaan atas pekerjaan ini ?
 Siapa yang akan menggunakan solusi ini?
 Apa keuntungan ekonomi dari solusi yang sukses ?
 Apakah ada sumber solusi lain yang anda butuhkan?
 Memperoleh Kebutuhan
Pertemuan diadakan dan dihadiri baik oleh software engineer maupun konsumen
Aturan persiapan dan partisipasi dibuat
Agenda ditawarkan
Seorang fasilitator (bisa konsumen, developer atau orang luar) mengendalikan
pertemuan
Mekanisme definisi digunakan (bisa berupa kertas kerja, grafik, bulletin board
elektronik, forum virtual dsb)
Tujuannya adalah
 Menemukan permasalahan
 Mengajukan elemen-elemen solusi
 Negosiasi pendekatan yang berbeda
 Menentukan sekelompok kebutuhan solusi awal
 Penyebaran Fungsi Kualitas
Penyebaran fungsi menemukan “nilai” (dalam persepsi
konsumen) dalam setiap fungsi yang diperlukan sistem
Penyebaran Informasi menentukan event dan objek data
Penyebaran Tugas memeriksa perilaku sistem
Analisis Nilai menentukan prioritas relatif dari
kebutuhan
  
Mendapatkan Produk-Produk Kerja

Sebuah pernyataan kebutuhan dan kemungkinan dikerjakan.

Pernyataan terbatas tentang lingkup sistem atau produk.
Daftar konsumen, pengguna dan stakeholder lain yang
berpartisipasi dalam pengumpulan kebutuhan
Deskripsi lingkungan teknis sistem
Daftar kebutuhan (disarankan dikelompokkan berdasar fungsi) dan
batasan domain yang diterapkan pada masing- masing kebutuhan
Beberapa prototype yang dikembangkan untuk definisi kebutuhan
yang lebih baik
 Use-Cases
Sekelompok skenario pengguna yang menggambarkan alur
penggunaan sistem
Setiap skenario digambarkan dari sudut pandang “aktor”, seseorang
atau piranti yang berinteraksi dengan PL dalam berbagai cara
Setiap skenario menjawab pertanyaan-pertanyaan berikut :
 Siapa aktor primer dan sekunder ?
 Apa tujuan aktor ?
 Prekondisi apa yang harus ada sebelum cerita dimulai?
 Apa tugas atau fungsi utama yang dilakukan oleh aktor ?
 Ekstensi apa yang harus diperhatikan ketika cerita digambarkan?
Use-Case Diagram
 Membangun Model Analisis
Elemen-elemen model analisis
 Elemen-elemen berbasis skenario
• Fungsional—memproses narasi untuk fungsi PL
• Use-case—gambaran interaksi antara aktor dan sistem
 Elemen-elemen berbasis Class
• Dipengaruhi oleh skenario
 Elemen-elemen Perilaku/Behavioral
• State diagram
 Elemen-elemen berorientasi aliran
• Data flow diagram
State Diagram
 Pola-Pola Analisis (1)
Nama Pola: sebutan yang mengungkap esensi pola
Maksud: Menggambarkan apa yang dilakukan atau direpresentasikan
pola
Motivasi: Sebuah skenario yang menggambarkan bagaimana pola dapat
digunakan untuk menyelesaikan masalah
Pengaruh dan Konteks: deskripsi isu eksternal yang dapat
mempengaruhi bagaimana pola digunakan, dan isu eskternal yang akan
diselesaikan ketika pola diterapkan.
Solusi: Deskripsi tentang bagaimana pola diterapkan untuk
menyelesaikan masalah dengan tekanan pada isu struktural dan perilaku
 Pola-Pola Analisis (2)
Konsekuensi: menunjukkan apa yang terjadi apabila pola diterapkan dan
apa kerugian yang ada selama aplikasi tersebut dijalankan
Desain: Membahas bagaimana pola analisis dapat diterima melalui
penggunakan pola desain (design patterns) yang sudah dikenal
Penggunaan yang sudah dikenal: Contoh penggunaan di dalam sistem
aktual
Penggunaan yang sudah dikenal: Contoh penggunaan di dalam sistem
aktual
Pola terkait: Satu atau lebih pola analisis yang terkait dengan nama pola
yang ada karena (1)secara umum digunakan dengan nama pola;(2)secara
struktur mirip dengan nama pola;(3)variasi dari nama pola.
  
Negosiasi Kebutuhan

Mengenali stakeholder kunci

 Orang-orang ini yang akan dilibatkan negosiasi
Menentukan “kondisi menang” setiap stakeholder
 Kondisi kemenangan tidak selalu jelas
Negosiasi
 Bekerja menuju sekumpulan kebutuhan yang merupakan win-
win solution
  
 
Validasi Kebutuhan-I

Apakah setiap kebutuhan konsisten dengan tujuan keseluruhan

sistem/produk?
Apakah semua kebutuhan telah dispesifikasikan pada tingkat abstraksi yang
tepat ? Apakah beberapa kebutuhan pada tingkatakan detail teknis tidak
tepat pada level ini ?
Apakah kebutuhan benar-benar diperlukan ataukan dia hanya merupakan
fitur tambahan yang tidak esensial bagi tujuan sistem ?
Apakah setiap kebutuhan terbatasi dengan baik dan tidak ambigu ?
Apakah setiap kebutuhan mempunyai atribut ? Apakah sebuah sumber
tercatat untuk setiap kebutuhan ?
Apakah setiap kebutuhan konflik dengan kebutuhan lain ?
 Validasi Kebutuhan--II
 Apakah setiap kebutuhan dapat diterima dalam lingkungan teknik yang
menjadi rumah bagi sistem/produk?
Apakah setiap kebutuhan dapat diuji, setelah diimplementasi ?
Apakah model kebutuhan mencerminkan informasi, fungsi, dan perilaku
sistem yang dibangun dengan baik.
Apakah model kebutuhan telah dipartisi sedemikian sehingga
menampilkan secara progresif informasi yang lebih detail tentang sistem ?
Apakah pola kebutuhan telah digunakan untuk mempermudan model
kebutuhan ? Apakah semua pola telah divalidasi? Apakah pola konsisten
dengan kebutuhan konsumen ?