Pemodelan Analisis (Part 1) Pertemuan 5 Rekayasa Perangkat Lunak

Presentasi berjudul: "Pemodelan Analisis (Part 1) Pertemuan 5 Rekayasa Perangkat Lunak"— Transcript presentasi:

1 Pemodelan Analisis (Part 1) Pertemuan 5 Rekayasa Perangkat Lunak
Hernando Ivan TEDDy, s. kom

2 ANALISIS : Starting Point
Rekayasa perangkat lunak dimulai dengan serangkaian tugas pemodelan yang membawa kepada suatu spesifikasi lengkap dari persyaratan representasi dan representasi desain yang komprehensif bagi perangkat lunak yang dibangun.

3 Definisi Pemodelan Analisis
Proses menemukan permasalahan dan menghasilkan alternatif pemecahan yang relevan. Tujuan tahap analisis adalah untuk mengetahui kebutuhan customer berkaitan dengan sistem perangkat lunak yang diinginkan.

4 ILUSTRASI : Bangun Rumah
Analisis

5 SASARAN UTAMA ANALISIS
Menggambarkan apa yang dibutuhkan untuk pelanggan Membangun dasar bagi perancangan perangkat lunak Membatasi serangkaian persyaratan yang dapat divalidasi begitu perangkat lunak dibangun

6 KETERLIBATAN Pada tahap ini yang terlibat adalah tim spesifikasi/analisis dan customer (meliputi end-user, manager dan staf lain yang terlibat)

7 RUANG LINGKUP ANALISIS
Mengindentifikasi customer Mendefinisikan dan menspesifikasikan kebutuhan Membangun model analisis Mendefinisikan spesifikasi secara rinci untuk dijadikan panduan dalam melakukan perancangan

8 RUANG LINGKUP ANALISIS
Mendokumentasikan hasil analisis kedalam dokumen SRS (Software Requirement Specification) Melakukan pengkajian ulang secara formal

9 S R S Secara sederhana, Software Requirement Specifications (SRS) adalah dokumen yang menjelaskan tentang berbagai kebutuhan yang harus dipenuhi oleh suatu software. Dokumen ini dibuat oleh developer (pembuat software) setelah menggali informasi dari calon pemakai software.

10 Manfaat S R S Sebagai bentuk perjanjian antara customer dan supplier tentang software apa yang akan dibuat Mengurangi beban dalam proses pengembangan software Sebagai bahan perkiraan biaya dan rencana penjadwalan

11 Manfaat S R S Sebagai dasar validasi dan verifikasi software di ujung penyelesaian proyek nantinya Mendasari perbaikan produk software di kemudian hari. Jadi, kadang SRS boleh diperbaiki dengan alasan dan mekanisme tertentu serta atas kesepakatan antara customer dan developer.

12 Manfaat S R S Memfasilitasi transfer, semisal software tersebut ingin ditransfer ke pengguna atau mesin-mesin yang lain. Customer pun merasa mudah jika ingin mentransfer software ke bagian-bagian lain dalam organisasinya. Bahkan, jika terjadi pergantian personil developer, proyek dapat mudah ditransfer ke personil baru dengan memahami SRS ini.

13 S R S yang Baik Correct (benar) Unambiguous (tidak ambigu, tapi jelas)
Complete (lengkap) Consistent (konsisten) Verifiable (dapat diverifikasi) Modifiable (bisa dimodifikasi) Traceable (bisa dilacak)

14 S R S TEMPLATE Template dokumen SRS bisa di download di :
gj/SRS.pdf

15 S R S TEMPLATE Mari kita bahas tentang Dokumen SRS, dan disesuaikan dengan studi kasus yang sudah dibagi