0% menganggap dokumen ini bermanfaat (0 suara)
27 tayangan10 halaman

Model Waterfall dalam Rekayasa Perangkat Lunak

Diunggah oleh

Rahmawati Oktavia
Hak Cipta
© All Rights Reserved
Kami menangani hak cipta konten dengan serius. Jika Anda merasa konten ini milik Anda, ajukan klaim di sini.
Format Tersedia
Unduh sebagai DOCX, PDF, TXT atau baca online di Scribd
0% menganggap dokumen ini bermanfaat (0 suara)
27 tayangan10 halaman

Model Waterfall dalam Rekayasa Perangkat Lunak

Diunggah oleh

Rahmawati Oktavia
Hak Cipta
© All Rights Reserved
Kami menangani hak cipta konten dengan serius. Jika Anda merasa konten ini milik Anda, ajukan klaim di sini.
Format Tersedia
Unduh sebagai DOCX, PDF, TXT atau baca online di Scribd

MAKALAH MATA KULIAH

REKAYASA PERANGKAT LUNAK

Kelas : 06PS5

Disusun oleh :
Nama Kelompok
1. Rahmawati Oktavia (8040210008)
2. Dwi Ramadianty Melvi (8040210010)
3. Cindy Pratidina Puteri (8040210012)
4. Fadilla Anggraini (8040210114)

UNIVERSITAS DINAMIKA BANGSA JAMBI


FAKULTAS ILMU KOMPUTER
JURUSAN SISTEM INFORMASI
2023
A. WATERFALL

Model waterfall adalah suatu pendekatan pengembangan perangkat lunak yang


bersifat sekuensial dan linear. Model ini mengorganisir proses pengembangan perangkat
lunak menjadi serangkaian fase yang harus diselesaikan secara berurutan sebelum
melanjutkan ke fase berikutnya. Setiap fase dalam model waterfall memiliki tujuan dan
deliverable (produk yang dihasilkan) yang jelas. Model ini pertama kali diperkenalkan
oleh Dr. Winston W. Royce pada tahun 1970.

1. Gambaran Dan Proses Model Waterfall


Berikut adalah gambaran dan proses secara umum dari model pengembangan
perangkat lunak Waterfall:
1. Pengumpulan Kebutuhan (Requirement Gathering):
- Gambaran: Tim proyek berkomunikasi dengan pemangku kepentingan untuk
memahami kebutuhan bisnis dan sistem.
- Proses:
 Identifikasi kebutuhan bisnis.
 Wawancara dengan pengguna dan pemangku kepentingan.
 Dokumentasikan kebutuhan dalam dokumen kebutuhan.
2. Perancangan Sistem (System Design)
- Gambaran: Merancang struktur sistem dan mengidentifikasi komponen-
komponen utama.
- Proses:
 Membuat desain sistem berdasarkan kebutuhan.
 Menentukan arsitektur perangkat lunak.
 Menghasilkan dokumentasi perancangan sistem.
3. Implementasi (Implementation):
- Gambaran: Tahap ini melibatkan pengkodean atau pembangunan sistem
berdasarkan desain yang telah dibuat.
- Proses:
 Menerjemahkan desain menjadi kode.
 Mengimplementasikan komponen-komponen perangkat lunak.
 Melakukan uji unit pada setiap komponen.
4. Pengujian (Testing):
- Gambaran: Melibatkan pengujian sistem secara menyeluruh untuk
memastikan kualitas dan keandalan.
- Proses:
 Melakukan uji integrasi untuk memastikan komponen bekerja bersama.
 Melakukan uji sistem untuk memverifikasi apakah sistem sesuai dengan
spesifikasi.
 Mengidentifikasi dan memperbaiki bug atau masalah.
5. Implementasi (Deployment):
- Gambaran: Tahap implementasi adalah saat sistem diterapkan di lingkungan
produksi.
- Proses:
 Menyiapkan lingkungan produksi.
 Menginstal perangkat lunak dan konfigurasi yang diperlukan.
 Melakukan peluncuran resmi.
6. Pemeliharaan (Maintenance):
- Gambaran: Tahap ini terlibat dalam pemeliharaan sistem setelah implementasi.
- Proses:
 Merespons masalah yang muncul pasca-implementasi.
 Mengidentifikasi dan memperbaiki bug.
 Melakukan pembaruan perangkat lunak jika diperlukan.

Catatan Penting:
- Setiap fase harus diselesaikan sepenuhnya sebelum melanjutkan ke fase berikutnya.
- Waterfall kurang fleksibel terhadap perubahan kebutuhan, sehingga pengelolaan risiko
sangat penting.
- Kebutuhan yang baik diidentifikasi di awal sangat krusial dalam model ini.

2. Kelebihan Dan Kekurangan Waterfall


a. Kelebihan Waterfall

Berikut adalah beberapa kelebihan dari model waterfall:


1. Struktur yang Terorganisir: Model waterfall menawarkan struktur yang
terorganisir dan tahapan yang jelas. Setiap fase harus selesai sebelum
melanjutkan ke fase berikutnya. Ini memberikan keteraturan dan pemahaman
yang baik tentang kemajuan proyek.
2. Dokumentasi yang Kuat: Setiap fase dalam model waterfall diikuti dengan
dokumentasi yang terperinci. Dokumen kebutuhan, dokumen desain, dan
dokumen pengujian membantu dalam pemahaman yang lebih baik terhadap
proyek dan dapat berfungsi sebagai referensi yang baik di masa depan.
3. Manajemen Proyek yang Jelas: Karena sifatnya yang sekuensial, model
waterfall dapat memudahkan manajemen proyek dan pengendalian perubahan.
Ini membuatnya cocok untuk proyek-proyek dengan persyaratan yang relatif
stabil dan terdefinisi dengan baik.
4. Cocok untuk Proyek Kecil dan Sederhana: Pada proyek-proyek kecil dan
sederhana, di mana persyaratan cenderung tetap dan perubahan jarang terjadi,
model waterfall dapat bekerja dengan baik dan efisien.
5. Perencanaan dan Estimasi yang Lebih Mudah: Karena tahap-tahapnya
yang terdefinisi dengan baik, perencanaan dan estimasi proyek menjadi lebih
mudah dibandingkan dengan model yang lebih adaptif.
6. Memungkinkan Pengembang dan Pengelolaan yang Jelas: Model ini
menyediakan perbatasan yang jelas antara tim pengembangan dan manajemen,
memungkinkan pengelolaan proyek yang lebih terfokus pada pengawasan dan
koordinasi.

Meskipun memiliki kelebihan ini, perlu diingat bahwa kelebihan ini hanya relevan dalam
konteks proyek-proyek tertentu. Pada proyek dengan tingkat ketidakpastian yang tinggi atau
persyaratan yang mungkin berubah bisa menggunakan pendekatan yang lain. Keputusan
untuk menggunakan model waterfall atau metode pengembangan lainnya harus selalu
didasarkan pada karakteristik khusus dari proyek yang sedang dihadapi.
b. Kekurangan Waterfall
Meskipun model waterfall memiliki kelebihan tertentu, ada sejumlah kekurangan
yang perlu dipertimbangkan:
1. Ketidakmampuan Menanggapi Perubahan Kebutuhan: Model ini kurang
fleksibel terhadap perubahan kebutuhan yang mungkin muncul selama
pengembangan perangkat lunak. Jika ada perubahan kebutuhan, seringkali
sulit atau mahal untuk mengintegrasikannya setelah fase desain dimulai.
2. Pendekatan Sekuensial yang Ketat: Fase-fase dalam model waterfall harus
diselesaikan secara sekuensial, yang dapat memperpanjang waktu
pengembangan. Ini dapat menjadi masalah jika ada kebutuhan untuk merilis
produk atau fitur lebih cepat.
3. Keterbatasan Kolaborasi dan Komunikasi: Karena setiap fase memiliki
batas yang jelas, kolaborasi dan komunikasi antara tim mungkin terbatas. Hal
ini dapat menghambat pertukaran informasi dan ide antara anggota tim.
4. Keterlambatan Identifikasi Masalah: Karena tahap pengujian sering terjadi
setelah implementasi selesai, masalah atau kegagalan mungkin tidak
teridentifikasi sampai tahap tersebut. Ini dapat menyebabkan perubahan yang
mahal dan kompleks.
5. Kemungkinan Overhead Dokumentasi yang Berlebihan: Fokus pada
dokumentasi yang kuat dapat mengarah pada overhead dokumen yang
berlebihan, terutama pada proyek-proyek kecil atau sederhana, yang dapat
menyebabkan pemborosan waktu dan sumber daya.
6. Pemeliharaan yang Sulit: Jika perubahan diperlukan setelah implementasi,
proses pemeliharaan dapat menjadi sulit karena model ini tidak dirancang
untuk menanggapi perubahan dengan fleksibilitas.
7. Kemungkinan Penundaan Identifikasi Kesalahan Desain: Karena desain
keseluruhan sistem terjadi di awal proyek, kesalahan desain mungkin tidak
terdeteksi sampai tahap pengujian atau bahkan setelah implementasi.
8. Tidak Sesuai untuk Proyek Berbasis Risiko Tinggi: Model waterfall kurang
cocok untuk proyek-proyek dengan tingkat risiko tinggi, karena keseluruhan
rancangan dan implementasi harus diselesaikan sebelum risiko dapat
diidentifikasi dengan jelas.
Oleh karena itu, sementara model waterfall memiliki tempatnya dalam proyek-proyek
tertentu, kekurangan-kekurangan ini perlu dipertimbangkan dengan hati-hati, terutama dalam
lingkungan yang dinamis dan berubah cepat.

B. ICONIX
Iconix adalah suatu metode pengembangan perangkat lunak yang berfokus pada
analisis dan desain berorientasi objek diciptakan oleh Doug Rosenberg pada tahun 1992.
Metode ini terkenal karena memberikan pendekatan yang terstruktur untuk
mengembangkan perangkat lunak, dan sering digunakan dalam pengembangan sistem
berbasis objek. Iconix menyediakan kerangka kerja dan teknik untuk membantu tim
pengembangan memahami, merancang, dan menguji sistem perangkat lunak berbasis
objek secara lebih efektif.

1. Spesifikasi Metode Iconix


Berikut adalah spesifikasi umum dari metode Iconix:
1. Use Case Driven: Menganjurkan pendekatan pengembangan berbasis kasus
pengguna (use case-driven). Use case digunakan untuk menggambarkan
fungsionalitas sistem dari perspektif pengguna.
2. Modeling: Menggunakan berbagai model untuk menggambarkan sistem,
termasuk diagram use case, diagram aktivitas, diagram kelas, dan diagram
urutan.
3. Iterative dan Incremental: Pendekatan iteratif dan incremental diadopsi,
memungkinkan pengembang untuk membangun sistem secara bertahap dan
melibatkan pemangku kepentingan secara berulang.
4. Analisis dan Desain Berbasis Objek: Memanfaatkan prinsip-prinsip analisis
dan desain berbasis objek, termasuk penggunaan kelas, objek, pewarisan,
enkapsulasi, dan polimorfisme.
5. Pemodelan Dinamis dan Statis: Menggambarkan aspek dinamis dan statis dari
sistem dengan menggunakan diagram aktivitas untuk model dinamis dan diagram
kelas untuk model statis.
6. Use Case Realization: Mentransformasikan use case menjadi desain yang lebih
rinci dengan menggunakan skenario, diagram urutan, dan diagram aktivitas.
7. Pengujian Terintegrasi: Mengintegrasikan aktivitas pengujian ke dalam setiap
fase pengembangan, termasuk pengujian unit, integrasi, dan sistem.
8. Dokumentasi yang Dikelola: Memiliki dokumen yang dikelola dengan baik,
termasuk dokumen use case, spesifikasi desain, dan dokumen pengujian.

9. Pemetaan Terhadap Proses Pengembangan Perangkat Lunak: Memiliki


tahapan pengembangan yang dapat dimapping ke dalam fase-fase tertentu, seperti
analisis, desain, implementasi, dan pengujian.
10. Penggunaan Alat: Pemilihan dan penggunaan alat yang mendukung
pengembangan berbasis objek dan memfasilitasi pemodelan sistem.
11. Pelibatan Pemangku Kepentingan: Memastikan partisipasi dan umpan balik
secara teratur dari pemangku kepentingan selama seluruh siklus pengembangan.
12. Dokumentasi yang Dapat Dipahami oleh Pemangku Kepentingan: Membuat
dokumen yang dapat dipahami oleh pemangku kepentingan non-teknis, termasuk
dokumentasi use case yang komprehensif.

Iconix menyediakan pendekatan yang terstruktur dan terdokumentasi untuk


pengembangan perangkat lunak berbasis objek, dengan fokus pada analisis yang cermat
dan pemahaman yang baik terhadap kebutuhan pengguna. Metode ini mendukung
pemodelan yang kuat dan memastikan bahwa dokumentasi proyek dapat dihasilkan dan
dipelihara dengan baik.

2. Proses Iconix:
1. Pengumpulan Kebutuhan (Requirements Gathering):
 Identifikasi dan dokumentasikan kebutuhan sistem.
 Menggunakan use case untuk merinci fungsionalitas dari perspektif
pengguna.
2. Analisis Use Case (Use Case Analysis):
 Mengidentifikasi skenario use case dan menyusun model use case.
 Menyusun skenario atau urutan langkah-langkah yang menjelaskan
interaksi antara aktor dan sistem.
3. Perancangan Sistem (System Design):
 Menggunakan model use case sebagai dasar untuk merancang struktur
sistem.
 Melibatkan pembuatan diagram aktivitas, diagram urutan, dan diagram
kelas.
4. Pengujian:
 Melibatkan pengujian setiap komponen dan fungsi sistem.
 Use case dan skenario digunakan sebagai dasar untuk mengembangkan
skenario pengujian.
5. Implementasi:
 Melibatkan pengkodean dan implementasi sistem berdasarkan desain yang
telah dibuat.
 Proses ini mencakup transformasi desain menjadi kode yang dapat
dieksekusi.
6. Pengujian Integrasi dan Sistem (Integration and System Testing):
 Mengintegrasikan berbagai komponen sistem dan menguji keseluruhan
sistem.
 Memastikan bahwa sistem berfungsi dengan baik sebagai satu kesatuan.
7. Implementasi dan Pemeliharaan (Deployment and Maintenance):
 Menerapkan sistem ke lingkungan produksi.
 Melibatkan pemeliharaan sistem dan penanganan perubahan setelah
implementasi.

3. Elemen-elemen Utama dalam Iconix:


1. Use Case Diagrams:
 Menunjukkan aktor dan use case yang mewakili fungsionalitas sistem dari
perspektif pengguna.
2. Diagram Aktivitas (Activity Diagrams):
 Menggambarkan aliran kerja atau aktivitas dalam sistem, membantu
pemahaman proses bisnis.
3. Diagram Urutan (Sequence Diagrams):
 Menunjukkan urutan interaksi antara objek dalam sistem.
4. Diagram Kelas (Class Diagrams):
 Merinci struktur kelas dan hubungan antara kelas-kelas dalam sistem.
5. Skenario Use Case dan Skenario Pengujian:
 Merinci langkah-langkah spesifik untuk setiap use case, baik dari
perspektif fungsional maupun pengujian.
Proses Iconix dapat disesuaikan dan diadaptasi sesuai dengan kebutuhan proyek
tertentu. Ini memberikan pendekatan yang sistematis untuk pengembangan perangkat
lunak berbasis objek dengan fokus pada penggunaan kasus dan desain yang terstruktur.
4. Kelebihan Dan Kekurangan Metode Iconix
a. Kelebihan Metode Iconix

Metode Iconix memiliki beberapa kelebihan yang membuatnya digunakan dan


diapresiasi dalam pengembangan perangkat lunak, terutama untuk proyek-proyek
berbasis objek. Berikut adalah beberapa kelebihan dari metode Iconix:
1. Focus pada Use Case:
 Metode Iconix berfokus kuat pada penggunaan kasus (use case),
yang membantu dalam pemahaman yang jelas terhadap
fungsionalitas sistem dari perspektif pengguna. Ini membantu tim
pengembangan untuk lebih terhubung dengan kebutuhan pengguna.
2. Modeling yang Efektif:
 Iconix menyediakan teknik pemodelan yang efektif, termasuk
penggunaan diagram aktivitas, diagram urutan, dan diagram kelas.
Ini membantu dalam merinci dan memahami secara mendalam
struktur dan perilaku sistem.
3. Proses Iteratif dan Incremental:
 Metode ini mendukung pendekatan pengembangan yang iteratif
dan incremental. Ini memungkinkan pengembangan sistem secara
bertahap, memungkinkan pemangku kepentingan untuk
memberikan umpan balik yang berkelanjutan.
4. Keterlibatan Pemangku Kepentingan:
 Melalui penggunaan use case dan skenario, Iconix mendorong
keterlibatan aktif dari pemangku kepentingan. Ini membantu dalam
memastikan bahwa kebutuhan dan harapan pengguna tercermin
dengan baik dalam pengembangan.
5. Pengujian Terintegrasi:
 Proses pengembangan Iconix mencakup pengujian yang
terintegrasi, yang berarti pengujian dilibatkan sepanjang siklus
pengembangan. Hal ini dapat membantu mengidentifikasi masalah
lebih awal dalam proses pengembangan.
6. Dokumentasi yang Komprehensif:
 Iconix mendorong penciptaan dokumentasi yang komprehensif,
seperti diagram use case, diagram aktivitas, dan diagram kelas.
Dokumentasi ini memberikan sumber daya yang baik untuk
pemahaman proyek dan pemeliharaan di masa depan.
7. Memfasilitasi Pemahaman dan Desain yang Baik:
 Model yang dihasilkan oleh Iconix membantu dalam pemahaman
yang baik terhadap sistem dan memfasilitasi desain yang
terstruktur. Ini meminimalkan ambiguitas dan meningkatkan
kualitas pengembangan.
8. Fleksibilitas:
 Meskipun memiliki kerangka kerja dan panduan yang terstruktur,
Iconix juga dapat disesuaikan dan diadaptasi sesuai kebutuhan
proyek tertentu. Ini memberikan fleksibilitas dalam
implementasinya.
Penting untuk dicatat bahwa kelebihan metode Iconix akan bervariasi
tergantung pada karakteristik proyek, tim pengembangan, dan kebutuhan pengguna.
Metode ini khususnya bermanfaat pada proyek berbasis objek dengan kebutuhan yang
jelas dan pemangku kepentingan yang terlibat.
b. Kekurangan Metode Iconix
Meskipun metode Iconix memiliki sejumlah kelebihan, seperti yang dijelaskan
sebelumnya, ada juga beberapa kekurangan yang perlu dipertimbangkan:
1. Mungkin Terlalu Terstruktur:
 Iconix dapat terasa terlalu terstruktur untuk beberapa proyek,
terutama proyek-proyek yang lebih kecil atau kurang kompleks.
Pendekatan yang terlalu formal dapat memperlambat
pengembangan pada proyek-proyek tertentu.
2. Mungkin Sulit untuk Proyek dengan Perubahan Kebutuhan yang
Sering:
 Karena fokus pada penggunaan kasus dan desain yang terstruktur,
Iconix mungkin menjadi kurang responsif terhadap perubahan
kebutuhan yang sering terjadi. Proses yang sangat terstruktur dapat
membuat perubahan sulit diimplementasikan.
3. Memerlukan Keterampilan Analisis dan Pemodelan yang Kuat:
 Pemodelan yang mendalam dan analisis yang kuat diperlukan
untuk menggunakan Iconix secara efektif. Tim pengembangan
harus memiliki pemahaman yang baik tentang konsep-konsep
berbasis objek dan metodologi pengembangan perangkat lunak.
4. Pemeliharaan Dokumentasi yang Berlebihan:
 Meskipun dokumentasi yang komprehensif dapat menjadi
kelebihan, bagi beberapa tim atau proyek, dapat dianggap sebagai
beban berlebihan. Pemeliharaan dokumen yang ekstensif dapat
memakan waktu dan sumber daya.
5. Mungkin Kurang Cocok untuk Proyek Berbasis Teknologi Terbaru:
 Iconix, seperti banyak metodologi berbasis objek tradisional,
mungkin kurang cocok untuk proyek-proyek yang memanfaatkan
teknologi terbaru seperti pengembangan berbasis cloud atau
pendekatan pengembangan mikroservis.
6. Kurangnya Fokus pada Pengujian Unit yang Mendalam:
 Meskipun pengujian terintegrasi diterapkan dalam metodologi ini,
fokus pada pengujian unit mungkin kurang mendalam. Hal ini bisa
menjadi kelemahan pada proyek-proyek yang memiliki persyaratan
pengujian unit yang tinggi.
7. Memerlukan Pemahaman Mendalam tentang Use Case Modeling:
 Metode Iconix sangat bergantung pada penggunaan kasus, dan tim
pengembangan harus memiliki pemahaman yang mendalam
tentang teknik use case modeling agar dapat menerapkan
metodologi ini secara efektif.
Seperti halnya dengan setiap metodologi pengembangan perangkat lunak,
kekurangan-kekurangan ini harus dievaluasi dengan mempertimbangkan karakteristik
proyek dan kebutuhan bisnis tertentu. Metode yang satu mungkin lebih sesuai
daripada yang lain tergantung pada konteks dan sifat proyek yang sedang dihadapi.

Anda mungkin juga menyukai