Pertemuan 4.

Slides:



Advertisements
Presentasi serupa
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Advertisements

MODEL PROTOTYPE.
CHAPTER 7 Pengembangan Sistem
Komponen Dan Model Sistem Informasi
©Ayi Purbasari, S.T., /2008 Materi 3 Kuliah IT-505 PSBO ©Ayi Purbasari, S.T., /2008.
DASAR-DASAR PENGUJIAN PERANGKAT LUNAK
ANALISIS SISTEM.
PEMODELAN ANALISIS Kuliah - 5
Bab 10 Penetapan Harga Produk Memahami dan Menangkap Nilai Pelanggan
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Bab 9 Pengembangan Produk Baru dan Strategi Siklus Hidup Produk
SIKLUS HIDUP PROYEK Manajemen Proyek_Gasal 2012/2013.
REKAYASA SISTEM.
Software Quality Assurance
Peran Advokat dalam Mediasi
LANGKAH-LANGKAH melaksanakan SURVEI CONTOH
REKAYASA PERANGKAT LUNAK REQUIREMENTS ANALYSIS FUNDAMENTALS
Perancangan sistem ( berbasis objek )
Konsep & Prinsip Analisis
ANALISIS DAN DESAIN SISTEM INFORMASI
SISTEM AUDIT SISTEM PENJAMINAN MUTU INTERNAL PERGURUAN TINGGI
Analisis Kebutuhan dan Spesifikasi Perangkat Lunak
Analisis Persyaratan Perangkat Lunak dan Spesifikasi
1 Pendahuluan Ir. Waniwatining Astuti, M.T.I Muhammad Rachmadi, S.T., M.T.I.
ANALISIS SISTEM 1.
PERANCANGAN SISTEM.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Metodologi Pengembangan Sistem Informasi
Pemodelan Analisis (Part 1) Pertemuan 5 Rekayasa Perangkat Lunak
KONSEP DAN PRINSIP ANALISIS
Pertemuan 11 PRINSIP DAN KONSEP ANALISA
PENGEMBANGAN PERANGKAT LUNAK.
Spesifikasi Perangkat Lunak
ANALISIS KEBUTUHAN.
PriNciples That Guide Practice
Rekayasa Perangkat Lunak Model Proses PL
REKAYASA PERANGKAT LUNAK
Apakah “Praktek”? Praktek adalah sejumlah konsep, prinsip, metode dan tools that yang harus dimiliki ketika software direncanakan dan dikembangkan. Dia.
Konsep dan Prinsip Analisis
KONSEP DAN PRINSIP ANALISIS
4 Managing Software Requirement Analisis Kebutuhan
12. KONSEP DAN PRINSIP ANALISIS
REKAYASA PERANGKAT LUNAK
Jaminan Mutu dalam Kebutuhan Rekayasa
Rekayasa Perangkat Lunak Dosen : Citra Noviyasari, S.Si, MT
REKAYASA KEBUTUHAN SOFTWARE
Disusun Oleh: Defri Kurniawan, M.Kom Teknik Informatika UDINUS
R.S. Pressman & Associates, Inc
PENGEMBANGAN SISTEM.
JAMINAN KUALITAS PERANGKAT LUNAK (SOFTWARE QUALITY ASSURANCE)
Materi Habis Uts IMK Prototyping
Rekayasa Perangkat Lunak Dosen : Citra Noviyasari, S.Si, MT
Rekayasa Kebutuhan Software
Analisis Kebutuhan.
PENGEMBANGAN SISTEM Muhammad Hidayat, SE.
PENGEMBANGAN SISTEM.
PERTEMUAN 2 Proses Pengembangan Perangkat Lunak
SOFTWARE ENGINEERING Astrina DF ( ) Bagus Ilyas R ( )
Materi Rekayasa Perangkat Lunak
KEBUTUHAN & SPESIFIKASI SOFTWARE
Rekayasa Kebutuhan.
Analisa [Kebutuhan] Sistem
Pertemuan 8 Rekayasa Kebutuhan
ANALISA KEBUTUHAN PERANGKAT LUNAK
PENGEMBANGAN SISTEM.
Hanya digunakan di lingkungan Universtias
PRAKTEK RPL.
12. KONSEP DAN PRINSIP ANALISIS
KONSEP DAN PRINSIP ANALISIS
Analisis Persyaratan Perangkat Lunak dan Spesifikasi
Transcript presentasi:

Pertemuan 4

Pemahaman Tidak peduli bagaimana perangkat lunak dirancang atau 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 — Auditoreksternal Tim RPL 1 4

Tujuan Analisis Sistem — Mendefinisikan masalah secara tepat — Menyusun alternatif penyelesaian — Memilihdan 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 — Orang yang membutuhkan solusi — Keadaandari 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 menghasilkan sesuatu yang mengacu terhadap ide yang samar-samar tersebut. — Pelangganakan terus mengikuti perubahan, sehingga merugikan untuk si pengembang Tim RPL 1 7

Requirement Software (2) — Spesifikasi salah satu dari berikut ini: — Dokumentertulis — Sekelompok model — Matematika f ormal — Sekumpulan scenario user (use-cases) — Prototipe — Validasi memeriksamekanismeyang memuat — Kesalahan isi atau interpretasi — Areadimana klarifikasi dibutuhkan 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. — ManajemenKebutuhan 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 — Menemukan permasalahan — Mengajukan elemen-elemen solusi — Negosiasi pendekatan 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

PenyebaranFungsi Kualitas (Quality Function Deployment= QFD) — Teknik manajemen kualitas yang menterjemahkan kebutuhan pelanggan kedalam 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 — Mewakilidata 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 fokus 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 — Kondisi kemenangan 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 tingkatabstraksi 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 lakudari 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