Materi ini merupakan materi pengenalan model pengembangan sistem informasi

1. Rekayasa Perangkat Lunak
(RPL – 2 SKS)
S1 Informatika
Heni Su
Fakultas Teknik dan Ilmu Kom
Universitas Teknokrat Ind

2. Learning Objective
 Apa yang dimaksud dengan proses-proses
perangkat lunak?
 Aktivitas-aktivitas mendasar, yang selalu ada
dalam setiap proses rekayasa perangkat lunak?
 Bagaimana proses-proses rekayasa perangkat
lunak dimodelkan dan bagaimana pola
prosesnya?
 Apa itu model proses dan apa kekuatan serta
kelemahannya?

3. Proses & Model PL
 Kerangka kerja untuk tugas-tugas yang
dibutuhkan untuk membangun perangkat lunak
dengan kualitas tinggi
 Strategi pengembangan PL yang melingkupi
lapisan proses, metode dan alat bantu yang
digunakan

4. Model Proses Perangkat Lunak
 RPL didefinisikan sebagai sejumlah aktivitas-
aktivitas kerja, tindakan-tindakan, serta
pekerjaan-pekerjaan, yang harus dilaksanakan
saat produk dibuat.
 Masing-masing aktivitas kerja, tindakan-tidakan,
serta pekerjaan-pekerjaan tersebut berada dalam
kerangka kerja atau model yang mendefinisikan
hubungan antar satu proses dengan proses yang
lainnya.

5. Kerang Kerja Proses Perangkat Lunak
Proses Kerangka Kerja
Aktivitas-aktivitas penyangga
Aktivitas Kerangka Kerja # 1
Tindakan-tindakan rekayasa perangkat lunak # 1.1
Satuan Pekerjaan-
pekerjaan
Pekerjaan produk-produk
kerja titik jaminan kualitas
project milestones
Pekerjaan produk-produk
kerja titik jaminan kualitas
project milestones
Satuan Pekerjaan-
pekerjaan
Pekerjaan produk-produk
kerja titik jaminan kualitas
project milestones
Pekerjaan produk-produk
kerja titik jaminan kualitas
project milestones
Tindakan-tindakan rekayasa perangkat lunak # 1.k
Proses Perangkat Lunak
Aktivitas Kerangka Kerja # n
Tindakan-tindakan rekayasa perangkat lunak # 1.1
Satuan Pekerjaan-
pekerjaan
Pekerjaan produk-produk
kerja titik jaminan kualitas
project milestones
Pekerjaan produk-produk
kerja titik jaminan kualitas
project milestones
Satuan Pekerjaan-
pekerjaan
Pekerjaan produk-produk
kerja titik jaminan kualitas
project milestones
Pekerjaan produk-produk
kerja titik jaminan kualitas
project milestones
Tindakan-tindakan rekayasa perangkat lunak # 1.k

6. Mendefinisikan Aktivitas Kerangka Kerja
 Untuk proyek perangkat lunak bersekala kecil,
spesifikasi kebutuhan pada umumnya bersifat
langsung dan aktifitas komunikasi mungkin bisa
dilakukan hanya dengan/melalui pembicaraan
telepon.
 Aliran Proses
KomunikasiKomunikasi PerencanaanPerencanaan PemodelanPemodelan KontruksiKontruksi
Penyerahan
ke
Pelanggan /
Pengguna
Penyerahan
ke
Pelanggan /
Pengguna
[a] aliran proses linier

7. Mendefinisikan Aktivitas Kerangka Kerja
KomunikasiKomunikasi PerencanaanPerencanaan PemodelanPemodelan KontruksiKontruksi
Penyerahan
ke
Pelanggan /
Pengguna
Penyerahan
ke
Pelanggan /
Pengguna
[b] aliran proses iteratif
KomunikasiKomunikasi
PerencanaanPerencanaan PemodelanPemodelan
KontruksiKontruksi
Penyerahan
ke
Pelanggan /
Pengguna
Penyerahan
ke
Pelanggan /
Pengguna
[c] aliran proses evolusioner
Peluncuran suatu
versi perangkat lunak

8. Mendefinisikan Aktivitas Kerangka Kerja
KomunikasiKomunikasi PerencanaanPerencanaan
PemodelanPemodelan
KontruksiKontruksi
Penyerahan
ke
Pelanggan /
Pengguna
Penyerahan
ke
Pelanggan /
Pengguna
waktu

9. Mendefinisikan Aktivitas Kerangka Kerja
 Membuat kontak dengan pemesan melalui
telepon
 Membahas spesifikasi kebutuhan dan
mencatatnya
 Menorganisasi catatan-catatan menjadi
pernyataan-pernyataan ringkas tertulis tentang
spesifikasi kebutuhan
 Mengirimkannya kepemesan melalu email untuk
meminta persetujuan

10. Mendefinisikan Aktivitas Kerangka Kerja
Saat proyek semakin komplek dan melibatkan
banyak stakeholder, aktivitas komunikasi sebaiknya
memiliki 6 tindakan nyata:
Pertemuan awal [inception]
Proses bertanya-tanya dan melakukan penelitian
[elicitation]
Mendapatkan rincian [elaboration]
Pembicaraan yang lebih serius [negotiation]
Penulisan spesifikasi [specification]
Pemeriksaan apakah segala sesuatunya berjalan
dengan baik [validation]

11. Mendefinisikan Himpunan Pekerjaan
 Mendefinisikan pekerjaan-pekerjaan nyata yang
harus diselesaikan untuk memenuhi sasaran
tertentu dari suatu aksi rekayasa perangkat
lunak.
 Untuk proyek yang kecil:
 Membuat daftar para stakeholder untuk proyek Perangkat lunak
yang akan dilaksanakan.
 Mengundang semua stakeholder untuk menghadiri pertemuan
informal.
 Bertanya pada masing-masing stakeholder untuk membuat daftar
fitur-fitur serta fungsi-fungsi.
 Mendiskusikan spesifikasi kebutuhan dan menggambarkan daftar
spesifikasi kebutuhan yang bersifat final.
 Melakukan prioritas untuk masing-masing spesifikasi kebutuhan.

12. Mendefinisikan Himpunan Pekerjaan
 Untuk proyek yang lebih besar/komplek:
 Membuat daftar para pemegang saham untuk RPL.
 Melakukan pembicaraan dengan stakeholder
secara terpisah untuk mendapatkan kebutuhan dan
keinginan secara keseluruhan.
 Mengembangkan daftar fungsi dan fitur yang
bersifat awal berdasarkan masukan-masukan dari
para stakeholder.
 Mencatat batasan-batasan yang akan diterapkan
pada sistem/perangkat lunak

13. Pola-pola proses
 Mendeskripsikan permasalahan-permasalahan
yang berkaitan dengan proses, yang dijumpai
selama pekerjaan RPL berlangsung
 Mendeskripsikan suatu permasalahan [dan
solusinya] dan
 Menghubungkan dengan aktivitas kerangka kerja
[misal perencanaan dan menghubungkannya
dengan aktifitas kerja peramalan/estimasi biaya
proyek]

14. Waterfall Model

15. Aktifitas Waterfall Model
 Requirements analysis and definition:
Mengumpulkan kebutuhan secara lengkap kemudian
dianalisis dan didefinisikan kebutuhan yang harus
dipenuhi oleh program yang akan dibangun.
 System and software design: Desain dikerjakan
setelah kebutuhan selesai dikumpulkan secara
lengkap.
 Implementation and unit testing: desain program
diterjemahkan ke dalam kode-kode dengan
menggunakan bahasa pemrograman yang sudah
ditentukan. Program yang dibangun langsung diuji.
 Integration and system testing: Penyatuan unit--unit
program kemudian diuji secara keseluruhan (system
testing).

16. Aktifitas Waterfall Model
 Operation and maintenance: mengoperasikan
program dilingkungannya dan melakukan
pemeliharaan, seperti penyesuaian atau perubahan
karena adaptasi dengan situasi sebenarnya.
 Kekurangan yang utama dari model ini adalah
kesulitan dalam mengakomodasi perubahan
setelah proses dijalani. Fase sebelumnya harus
lengkap dan selesai sebelum mengerjakan fase
berikutnya.

17. Prototyping Model
 Sebagian besar customer hanya memberikan
beberapa kebutuhan umum software tanpa detil
input, proses atau detil output.

18. Aktifitas Prototyping Model
 Requirements: developer dan klien bertemu dan
menentukan tujuan umum, kebutuhan yang
diketahui dan gambaran bagian-bagian yang akan
dibutuhkan berikutnya.
 Design: perancangan dilakukan cepat dan
rancangan mewakili semua aspek software yang
diketahui, dan rancangan ini menjadi dasar
pembuatan prototype.
 Evaluasi prototype: klien mengevaluasi prototype
yang dibuat dan digunakan untuk memperjelas
kebutuhan software.

19. Evolutionary Model
 Iteratif, hasil proses berupa produk yang makin
lama makin lengkap sampai versi
terlengkap dihasilkan sebagai produk akhir dari
proses.

20. Karakteristik Iteratif
 Model ini cocok jika jumlah anggota tim
pengembang/pembangun PL tidak cukup.
 Mampu mengakomodasi perubahan secara
fleksibel.
 Produk yang dihasilkan pada increment pertama
bukanlah prototype, tapi
 Produk yang sudah bisa berfungsi dengan
spesifikasi dasar.

21. Spiral Model (Original: Boehm)

22. Spiral Model (Original: Boehm)
 Customer communication: membangun
komunikasi yang baik dengan pengguna/customer.
 Planning: mendefinisikan resources, batas waktu,
informasi­informasi lain seputar proyek
 Risk analysis: identifikasi resiko managemen dan
teknis
 Engineering: pembangunan contoh­contoh aplikasi,
misalnya prototype
 Construction and release: pembangunan, test,
install dan support.
 Customer evaluation: mendapatkan feedback dari
pengguna beradasarkan evaluasi PL pada fase
engineering dan fase instalasi.

23. Spiral Model (Original: Boehm)
 Pada model spiral, resiko sangat
dipertimbangkan.
 Resiko adalah sesuatu yang mungkin
mengakibatkan kesalahan.
 Model spiral merupakan pendekatan
yang realistik untuk PL berskala besar.
 Pengguna dan pembangun bisa memahami
dengan baik software yang dibangun
karena setiap kemajuan yang dicapai selama
proses dapat diamati dengan baik.

24. RAD (Rapid Application Development)
 RAD adalah model proses pembangunan PL
yang incremental. RAD menekankan pada siklus
pembangunan yang pendek/singkat. RAD
mengadopsi model waterfall dan pembangunan
dalam waktu singkat dicapai dengan menerapkan
component based construction.
 Waktu yang singkat adalah batasan yang penting
untuk model ini. Jika kebutuhan lengkap dan
jelas maka waktu yang dibutuhkan untuk
menyelesaikan secara komplit software yang
dibuat adalah misalnya 60 sampai 90 hari.

25. Kelemahan dalam RAD model
 Tidak cocok untuk proyek skala besar
 Proyek bisa gagal karena waktu yang disepakati
tidak dipenuhi
 Sistem yang tidak bisa dimodularisasi tidak cocok
untuk model ini
 Resiko teknis yang tinggi juga kurang cocok
untuk model ini

26. RAD model

27. Fase­fase dalam RAD model
 Business modelling : menjawab pertanyaan :
informasi apa yang mengendalikan proses bisnis ?
Informasi apa yang dihasilkan ? Siapa
yang menghasilkan informasi ? Kemana informasi
itu diberikan ? Siapa yang mengolah informasi ? →
kebutuhan dari sistem
 Data modelling : aliran informasi yang sudah
didefinisikan, disusun menjadi sekumpulan objek
data. Ditentukan karakteristik/atribut dan hubungan
antar objek­objek tersebut → analisis kebutuhan
dan data
 Process Modelling : objek data yang sudah
didefinisikan diubah menjadi aliran informasi
yang diperlukan untukmenjalankan fungsi­fungsi

28. Fase­fase dalam RAD model
 Application Generation: RAD menggunakan
component program yang sudah ada atau
membuat component yang bisa digunakan lagi,
selama diperlukan.
 Testing and Turnover: karena menggunakan
component yang sudah ada, maka kebanyakan
component sudah melalui uji atau testing. Namun
component baru dan interface harus tetap diuji.

29. V model
 V model adalah metode pengembangan
perangkat lunak yang mengijinkan pada setiap
prosesnya untuk dilakukan testing dan validasi.
Jadi proses baru menggunakan hasil dari proses
lama sebagai acuannya. Ini memungkinkan
meminimalisasikan kesalahan pada prosesnya.

30. V model

31. Keuntungan V model
 Bahasa yang digunakan untuk
merepresentasikan konsep V model
menggunakan bahasa formal. Contoh : dengan
menggunakan objek model ataupun frame-frame
 Meminimalisasikan kesalahan pada hasil akhir
karena ada test pada setiap prosesnya
 Penyesuaian yang cepat pada projek yang baru
 Memudahkan dalam pembuatan dokumen projek
 Biaya yang murah dalam perawatan dan
modifikasinya

32. Kerugian V model
 Bahasa yang digunakan untuk merepresentasikan
konsep V model menggunakan bahasa formal. Contoh :
dengan menggunakan objek model ataupun frame-frame
 Meminimalisasikan kesalahan pada hasil akhir karena
ada test pada setiap prosesnya
 Penyesuaian yang cepat pada projek yang baru
 Memudahkan dalam pembuatan dokumen projek
 Biaya yang murah dalam perawatan dan
modifikasinyaAktifitas V-Model hanya difokuskan pada
projectnya saja, bukan pada keseluruhan organisasi. V-
Model adalah proses model yang hanya dikerjakan sekali
selama project saja, bukan keseluruhan organisasi.
 Prosesnya hanya secara sementara. Ketika project
selesai, jalannya proses model dihentikan. Tidak
berlangsung untuk keseluruhan organisasi.

33. Kerugian V model
 Metode yang ditawarkan terbatas. Sehingga kita tidak
memiliki cara pandang dari metode yang lain. Kita tidak
memiliki kesempatan untuk mempertimbangkan jika ada
tools lain yang lebih baik.
 Toolnya tidak selengkap yang dibicarakan. SDE (Software
Development Environment).Tidak ada tools untuk
hardware di V-Model. Tool yang dimaksud adalah
“software yang mendukung pengembangan atau
pemeliharaan / modifikasi dari system IT.

34. Penerapan V Model
 V model biasa digunakan pada proyek-proyek
dengan skala yang besar. Sebagai contohnya
yaitu digunakan di Jerman untuk mengatur
sistem administrasi pemerintahannya dalam hal
ini pada bagian BWB (Bundesamt für
Wehrtechnik und Beschaffung = German Federal
Office for Procurement).

35. Component­based Development Model
 Component-based development sangat berkaitan
dengan teknologi berorientasi objek. Pada
pemrograman berorientasi objek, banyak class
yang dibangun dan menjadi komponen dalam
suatu software. Class-class tersebut bersifat
reusable artinya bisa digunakan kembali. Model
ini bersifat iteratif atau berulang-ulang prosesnya.

36. Proses Component­based Development
Model
 Component-Based Software Engineering (CBSE)
adalah proses yang menekankan perancangan
dan pembangunan software dengan
menggunakan komponen software yang sudah
ada.
 CBSE terdiri dari dua bagian yang terjadi secara
paralel yaitu software engineering (component-
based development) dan domain engineerin.

37. Proses Component­based Development
Model
 Domain engineering menciptakan model domain bagi
aplikasi yang akan digunakan untuk menganalisis
kebutuhan pengguna. Identifikasi, pembangunan,
pengelompokan dan pengalokasikan komponen-
komponen software supaya bisa digunakan pada sistem
yang ada dan yang akan datang.
 Software engineering (component-based development)
melakukan analisis terhadap domain model yang sudah
ditetapkan kemudian menentukan spesifikasi dan
merancang berdasarkan model struktur dan spesifikasi
sistem, kemudian melakukan pembangunan software
dengan menggunakan komponen-komponen yang sudah
ditetapkan berdasarkan analisis dan rancangan yang
dihasilkan sebelumnya hingga akhirnya menghasilkan
software.

38. Proses Component­based Development
Model

39. Terimakasih