Pertemuan 4

REKAYASA PERANGKAT LUNAK 1

Pemahaman
Pemahaman lengkap mengenai persyaratan perangkat
lunak sangat penting bagi keberhasilan usaha
pengembangan perangkat lunak. Tidak peduli
bagaimana perangkat lunak dirancang atau
dikodekan, program yang dianalisis dan ditentukan
secara tidak baik akan mengecewakan pemakainya
dan akan membawa kegagalan bagi pengembangnya.

Tim RPL 1 2
Pemahaman (cont.)
Analisis merupakan sebuah :
— Penemuan
— Perbaikan
— Pemodelan
— Spesifikasi (baru)

Tim RPL 1 3
Pihak yang terlibat
— Pengembang maupun klien harus berperan aktif
— Klien berusaha memformulasikan kembali konsep
yang tidak jelas dari fungsi perangkat lunak dan
kinerja kedalam detail yang konkret.
— Pengembang bertindak sebagai integrator, konsultan
dan pemecah masalah
— Akuntan
— Auditor eksternal

Tim RPL 1 4
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

Tim RPL 1 5
Requirement Software (1)
Permulaanàtanya beberapa pertanyaan yang
menjelaskan:
— Pemahaman dasar dari masalah
— Orangyang membutuhkansolusi
— Keadaan dari solusi yang diinginkan
— Efektivitas komunikasi dan kolaborasi awal antara
konsumen dengan developer
— Perolehanàmemperoleh kebutuhan dari semua
stakeholder

INTI PERMASALAHANNYA ????

Tim RPL 1 6
Requirement Software (1)
— Pelanggan hanya memiliki ide yang samar-samar
apa yang dibutuhkanàpengembang akan
menghasilakn sesuatu yang mengacu terhadap ide
yang samar-samar tersebut.
— Pelanggan akan terus mengikuti perubahan,
sehingga merugikan untuk si pengembang

Tim RPL 1 7
Requirement Software (2)
— Spesifikasi—salah satu dari berikut ini:
— Dokument ertulis
— Sekelompok model
— Matematikaf ormal
— Sekumpulan skenariouser (use-cases)
— Prototipe
— Validasi—memeriksa mekanisme yang memuat
— Kesalahan isi atau interpretasi
— Area dimana klarifikasid ibutuhkan

Tim RPL 1 8
Requirement Software (2)
— Informasi yang hilang
— inkonsistensi(masalah utama ketika produk atau sistem
besar direkayasa)
— Kebutuhan yang konflik atau tidak realistis.
— Manajemen Kebutuhan

Tim RPL 1 9
Teknik Komunikasi
— Kenali stakeholder
“who else do you think I should talk to?”
— Kenali beberapa sudut pandang
— Berusahalah menuju kolaborasi
— Pertanyaan pertama
— Siapa 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?

Tim RPL 1 10
Mendapatkan Requirement
— 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

Tim RPL 1 11
Mendapatkan Requirement
(cont.)
— Tujuannya adalah
— Menemukanp ermasalahan
— Mengajukan elemen-elemens olusi
— Negosiasip endekatan yang berbeda
— Menentukan sekelompok kebutuhan solusi awal

Tim RPL 1 12
FAST (Facilitated Application
Specification Techniques)
Memacu kreasi kerjasama dari tim (pelanggan dan
pengembang) yang bekerja sama untuk :
— Mengidentifikasi masalah
— Menyiapkan elemen-elemen solusi
— Menegosiasikan pendekatan yang berbeda
— Menetapkan sebelumnya kebutuhan solusi yang
diperlukan

Tim RPL 1 13
Panduan FAST
J. Wood dan D. Silver menyarankan beberapa panduan umum
FAST yang dapat digunakan yaitu :
— Peserta harus menghadiri semua rapat
— Semua peserta adalah sama
— Persiapan harus sama pentingnya dengan rapat yang
sebenarnya
— Semua dokumen sebelum rapat harus dikaji ulang
— Lokasi rapat diluar ruangan terkadang diperlukan
— Tentukan agenda dan jangan sampai mengalami
perubahan
— Jangan sampai terbawa dalam hal-hal teknis yang terlalu
rinci
Tim RPL 1 14
Penyebaran Fungsi Kualitas (Quality
Function Deployment = QFD)
— Teknik manajemen kualitas yang menterjemahkan
kebutuhan pelanggan ke dalam kebutuhan teknis
untuk perangkat lunak
— Pertama kali diperkenalkan di Jepang untuk
memaksimalkan kepuasan pelanggan
— Menekankan pemahaman tentang apa yang berguna
kepada pelanggan dan kemudian menyebarkan nilai-
nilai tersebut melalui proses rekayasa

Tim RPL 1 15
Gambaran Konsep QFD :
— 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

Tim RPL 1 16
Prinsip Analisa 1
— Data Domain Model :
— Menetapkan objek data
— Menggambarkan atribut data
— Menetapkan hubungan data

Prinsip Analisa 2
— Fungsi Model :
— Mengidentifikasi fungsi yang (dapat) merubah objek
data
— Mengindikasikan berapa data yang melalui system
— Mewakili data produsen dan konsumen
Tim RPL 1 17
Prinsip Analisa 3
— Model Kebiasaan :
— Mengindikasikan states yang berbeda dari system
— Menetapkan kejadian yang mungkin menyebabkan
perubahan pada state

Prinsip Analisa 4
— Partisi Model :
— Menyaring setiap model untuk mewakili level yang
lebih rendah dari abstraksi

Tim RPL 1 18
Prinsip Analisa 4 (cont.)
— Menyaring objek data
— Membuat hirarki fungsi
— Mewakili kebiasaan pada tingkatan yang berbeda tiap detil
— Membuat partisi horizontal dan vertikal

Prinsip Analisa 5
— Intisari :
— Memulai focus intisari masalah tanpa memperhatikan
rincian implementasi

Tim RPL 1 19
Beberapa Prinsip
— Mengerti masalah sebelum kita memulai menciptakan
model analisa
— Membangun protipe yang memungkinkan pelanggan
untuk mengerti bagaimana pelanggan mengerti
interaksi manusia dan mesin dapat terjadi
— Mencatat hal-hal yang baru dan alasan untuk setiap
kebutuhan
— Menggunakan gambaran bertingkat setiap kebutuhan
— Memprioritaskan kebutuhan
— Bekerja untuk menghilangkan keragu-raguan
Tim RPL 1 20
Negosiasi Kebutuhan
— Mengenali stakeholder kunci
— Orang-orang ini yang akan dilibatkan negosiasi
— Menentukan “kondisi menang” setiap stakeholder
— Kondisike menangan tidak selalu jelas
— Negosiasi
— Bekerja menuju sekumpulan kebutuhan yang
merupakan win-win solution

Tim RPL 1 21
Validasi Requirement 1
— 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 ?

Tim RPL 1 22
Validasi Requirement 1 (cont.)
— 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 ?

Tim RPL 1 23
Validasi Requirement 2 (cont.)
— 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 ?
Tim RPL 1 24
Validasi Requirement 2 (cont.)
— Apakah pola kebutuhan telah digunakan untuk
mempermudan model kebutuhan ? Apakah semua
pola telah divalidasi? Apakah pola konsisten dengan
kebutuhan konsumen ?

Tim RPL 1 25
Summary
— Analisis persyaratan adalah langkah teknis pertama
pada proses rekayasa perangkat lunak
— Analisis harus berfokus pada domain informasi,
fungsional dan tingkah laku dari masalah.
— Dalam beberapa kasus tidaklah mungkin untuk secara
lengkap memspesifikasi suatu masalah pada tahap
awal
— Spesifikasi persyaratan perangkat lunak
dikembangkan sebagai akibat dari analisis

Tim RPL 1 26
 Selesai

Tim RPL 1 27