presentasi rpl

04/22/23 1

04/22/23 2

Elisitasi Persyaratan Validasi persyaratan

04/22/23

SUMBER : SOFTWARE ENGINEERING EDISI 6 JILID 1 (IAN SOMMERVILLE)

3

Kesalahan antara pengembang perangkat lunak dan user dapat di identifikasi ketika sistem di demonstrasikan

Staf pengembangan perangkat lunak mungkin menemukan persyaratan yang tidak lengkap dan/atau tidak konsisten pada saat prototipe di kembangkan

Sistem yang dapat bekerja Prototipe dapat digunakan sebagai dasar penulisan spesifikasi

untuk sistem kualitas produksi

04/22/23


4

Pelatihan user Pengujian Sistem

04/22/23


5

Kegunaan sistem yang lebih baik Kesesuaian sistem yang lebih dekat dengan

kebutuhan user Kualitas desain yang lebih baik Keterpeliharaan yang lebih baik Usaha pengembangan yang lebih ringan

04/22/23


6

04/22/23


7

04/22/23


8

Tujuan pembuatan prototipe evolusioner adalah menyerahkan sistem yang dapat di pakai kepada end-user.

Tujuan pembuatan prototipe throw-away adalah memvalidasi atau menurunkan persyaratan sistem

04/22/23


9

Pembuatan prototipe evolusioner merupakan bagian dari (atau memiliki banyak kesamaan dengan) teknik pengembangan aplikasi cepat Rapid Application Development (RAD) dan Joint Application Development (JAD) (Millington dan Stapleton, 1995; Wood dan Silver, 1995; Stapleton, 1997)

04/22/23


10

04/22/23


11

Penyerahan sistem yang di percepat Keterlibatan user dengan sistem

04/22/23


12

Proses spesifikasi,perancangan dan implementasi saling bertumpang tindih

Sistem di kembangkan dalam serangkaian bagian (inkremen)

Di pakai teknik-teknik untuk pengembangan sistem yang cepat

Interface sistem user biasanya di kembangkan dengan menggunakan sistem pengembangan interaktif yang memungkinkan desain interface dibuat dengan cepat,dengan menggambar dan menempatkan icon pada interface.

04/22/23


13

Masalah Manajemen Masalah Pemeliharaan Masalah Kontraktual

04/22/23


14

04/22/23


15

Fitur-fitur penting bisa dihilangkan dari prototipe untuk menyederhanakan implementasi yang cepat

Implementasi tidak mempunyai kedudukan legal sebagai kontrak

Persyaratan non-fungsional seperti keandalan, ketahanan dan keselamatan tidak dapat diuji dengan memadai.

04/22/23


16

Prototipe tidak harus perangkat lunak yang dapat berguna pada proses rekayasa persyaratan

Tiruan interface user dari sistem menggunakan kertas terbukti membantu user menyempurnakan desain interface dan skenario pemakaian (Rettig, 1994).

Perluasan dari teknik ini adalah prototipe “Wizard of Oz” (Sommervile & Sawyer 1997).

04/22/23


17

Penyerahan prototipe throw-away yang cepat biasanya tidak bijaksana karena :◦ Bisa saja tidak mungkin menyesuaikan prototipe untuk

memenuhi persyaratan non-fungsional seperti persyaratan kinerja,keamanan,bobot dan keandalan yang di abaikan pada pengembangan prototipe

◦ Perubahan yang cepat pada saat pengembangan pada akhirnya berarti bahwa prototipe tidak di dokumentasikan. Satu-satunya spesifikasi desain adalah kode prototipe. Ini tidak cukup baik untuk pemeliharaan jangka panjang

◦ perubahan yang di lakukan pada saat pengembangan prototipe mungkin akan merusak struktur sistem

◦ Standar kualitas organisasi biasanya di longgarkan untuk pengembangan prototipe

04/22/23

SUMBER : SOFTWARE ENGINEERING 1 EDISI 6 JILID (IAN SOMMERVILLE)

18

Pengembangan bahasa tingkat tinggi dinamik

Pemrograman database Perakitan komponen dan aplikasi

04/22/23


19

Apa domain aplikasi yang akan dibangun? (Object Oriented, Logic. List Based, Database…)

Interaksi User apa yang dibutuhkan? (teks based, graphics based, aplikasi windows, aplikasi web …)

Lingkungan pendukung apa yang disediakan dengan bahasa tersebut? (komponen, object/class, library …)

04/22/23


20

04/22/23 21

04/22/23


22

04/22/23 23

04/22/23

SUMBER : SOFTWARE ENGINEERING JILID 1 EDISI 6 (IAN SOMMERVILLE)

24

Tingkat aplikasi Tingkat komponen

04/22/23


25

04/22/23 26

Software Engineering edisi 6 Jilid 1 (Ian Sommerville,2003)

04/22/23 27

04/22/23 28

04/22/23 29

presentasi rpl

Documents