Slide INF205 RPL Pertemuan 3

(1)

REKAYASA PERANGKAT

LUNAK

(2)

(3)

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

(4)

Pihak-Pihak Yang Terlibat

Ahli sistem lingkungan kerja dan software Konsultan

Akuntan

(5)

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

(6)

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

(7)

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?}

(8)

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}

(9)

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

(10)

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

(11)

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 ?}

(12)

(13)

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}

(14)

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.

(15)

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

(16)

Negosiasi Kebutuhan

Mengenali stakeholder kunci

 _{Orang-orang ini yang akan dilibatkan negosiasi}

Menentukan “kondisi menang” setiap stakeholder

 _{Kondisi kemenangan tidak selalu jelas}

Negosiasi

(17)

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 ?

(18)

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 ?