Anda di halaman 1dari 10

Nama : Merpati Vortuna Amerta Nalle

Nim : 1718023

1. Kelebihan dan kekurangan dari model SDLC


a. Waterfall :
Kelebihan :
 Proses tahapan pengembangannya pasti, dan prosesnya teratur.
 Cocok digunakan untuk produk software/program yang sudah jelas kebutuhan di
awal, sehingga minim kesalahan.
 Software yang dihasilkan biasanya memiliki kualitas yang baik.
 Dokumen pengembangan system sangat terorganisir, karena setiap fase harus
terselesaikan dengan lengkap sebelum melangkah ke fase berikutnya.

Kekurangan:

 Membutuhkan tim yang solid. apabila salah satu tim tidak dapat menjalankan tugas
dengan semestinya, maka akan sangat berpengaruh terhadap alur kerja tim yang lain. 
 Membutuhkan waktu yang lebih lama . pelanggan harus sabar untuk menanti produk
selesai, karena dikerjakan tahap per tahap, dan proses pengerjaannya akan berlanjut
ke setiap tahapan bila tahap sebelumnya sudah benar-benar selesai.
 Semua tim dituntut untuk bekerja sesuai dengan arahan dan petunjuk yang telah
ditetapkan di awal. Sehingga, klien tidak dapat mengeluarkan pendapat
dan feedback kepada tim pengembang.
 Sulit untuk mengalami perubahan kebutuhan yang diinginkan oleh customer/
pelanggan.

b. V-model :
Kelebihan :
 Proaktif dalam pelacakan error dimana error ditemukan pada tahap awal bahkan
mungkin dalam tahap pengembangan sebelum aplikasi diuji.
 Menurangi biaya untuk memperbaiki error karena error ditemukan pada tahap
awal.
 Mudah untuk me-manage karena sifat kekakuan dari model dan setiap fase dalam
siklus memiliki tujuan yang spesifik.
 Model yang menerapkan disiplin tingkat tinggi dan fase – fase dalam model
diselesaikan satu persatu
 Dapat bekerja dengan sangat baik untuk proyek kecil dimana requirement sangat
mudah dipahami

Kekurangan :

 Kerugian terbesar dari model-V adalah sangat kaku dan paling tidak fleksibel.
Yaitu jika ada perubahan yang terjadi di tengah jalan, tidak hanya dokumen
persyaratan tetapi juga dokumentasi pengujian perlu diperbarui.
 membutuhkan banyak sumber daya dan uang, sehingga hanya dapat diterapkan
oleh beberapa perusahaan besar.
 Hal ini tidak diusulkan untuk proyek jangka pendek karena memerlukan tinjauan
pada setiap tahap.

 Tidak ada sistem yang dapat digunakan sampai satu siklus selesai

c. Prototype model :
Kelebihan :
 Pelanggan berpartisipasi aktif dalam pengembangan sistem, sehingga hasil produk
pengembangan akan semakin mudah disesuaikan dengan keinginan dan
kebutuhan pelanggan.
 Mempersingkat waktu pengembangan produk perangkat lunak.
 Penentuan kebutuhan lebih mudah diwujudkan.
 Prototype model melibatkan pelanggan dalam analisa dan desain.

Kekurangan :
 Walaupun pemakai melihat berbagai perbaikan dari setiap versi prototype, tetapi
pemakai mungkin tidak menyadari bahwa versi tersebut dibuat tanpa
memperhatikan kualitas dan pemeliharaan jangka panjang.
 Pengembang kadang-kadang membuat kompromi implementasi dengan
menggunakan sistem operasi yang tidak relevan dan algoritma yang tidak efisien.
 Prototype  yang dihasilkan biasanya sulit dirubah.

d. Spiral Model
Kelebihan :
 Perubahan tambahan atau fungsi-fungsi baru dapat dilakukan di tahap selanjutnya
jika ada perubahan secara tiba-tiba.
 Perkiraan biaya menjadi mudah karena pembuatan prototipe dilakukan dalam
fragmen-fragmen kecil.
 Pengembangan berkelanjutan atau berulang membantu dalam manajemen risiko.
 Selalu ada ruang untuk umpan balik pelanggan.

Kekurangan :

 Untuk kelancaran protocol model spiral perlu diikuti dengan ketat


 Pengembangan perangkat lunak spiral tidak disankan untuk proyek yang lebih
kecil, karena mungkin menghabiskan banyak biaya

e. RAD (Rapid Aplication Development)


Kelebihan :
 Lebih efektif dari pengembangan model waterfall dalam menghasilkan system
yang memenuhi kebutuhan langsung dari pelanggan.
 model RAD mengikuti tahap pengembangan system seperti pada umumnya, tetapi
mempunyai kemampuan untuk menggunakan kembali komponen yang ada
sehingga pengembang tidak perlu membuatnya dari awal lagi sehingga waktu
pengembangan menjadi lebih singkat dan efisien.
 cocok untuk proyek yang memerlukan waktu yang singkat.
Kekurangan :

 Tidak semua aplikasi sesuai untuk RAD, bila system tidak dapat dimodulkan
dengan teratur, pembangunan komponen penting pada RAD akan menjadi sangat
bermasalah.
 Membutuhkan tenaga kerja yang banyak untuk menyelesaikan sebuah proyek
dalam skala besar.
 jika ada perubahan di tengah-tengah pengerjaan maka harus membuat kontrak
baru antra pengembang dan pelanggan.

2. Agile unified process (AUP)


Agile Unified Process (AUP) diketahui sebagai metode pengembangan software
yang sesuai untuk pembangunan perancangan perangkat lunak dengan skala small-
medium. AUP adalah salah satu bentuk metode dari metode Agile. Terbentuknya Metode
AUP ini adalah gabungan antara metode Rational Unified Process (RUP) dan Agile
Method (AM).

AUP mempunyai 4 tahap pengembangan perangkat lunak dan 7 disiplin yang


dilakukan dalam setiap tahap secara iterative. 4 tahapan pengembangan yang ada dalam
AUP adalah adopsi dari metode UP (Unified Process) yaitu :
a. Inception
Identifikasi secara objektif jangkauan awal dari sistem yang akan dikembangkan.
Aktifitas yang dilakukan pada tahap ini diantaranya analisis sistem, perumusan target
dari sistem yang dikembangkan, identifikasi kebutuhan sistem, perancangan
pengujian sistem, membuat model alur rencana sistem dengan menggunakan diagram
dan dilakukannya pembuatan dokumentasi.
b. Elaboration
Menetapkan dan melakukan rancangan dari sistem sesuai dengan hasil yang didapat
dalam tahap inception. aktifitas utama yang dilakukan pada tahap ini mencakup
pembuatan desain arsitektur sistem, desain komponen sistem, desain format data
dalam database, desain interface / tampilan sistem, membuat model pada diagram
UML dan pembuatan dokumentasi.
c. Construction
Tahap untuk melakukan implementasi sesuai dengan hasil yang didapat dari tahap
inception dan elaboration yang sesuai dengan kebutuhan user. Pada tahap ini
dilakukan terlebih dahulu pemeriksaan ulang semua desain sistem meliputi
komponen kebutuhan sistem dan diagram rancangan sistem. Setelah dirasa hasil
analisa rancangan sistem cukup dan sesuai maka dapat dilakukan implementasi
sistem dengan bahasa pemrograman tertentu. Aktivitas lain yang dilakukan pada
tahap ini mencakup pengujian hasil analisa dan desain, pendataan kebutuhan
implementasi, pembuatan program, pengujian secara sederhana, pendataan berbagai
kemungkinan pengembangan / perbaikan lebih lanjut dan pembuatan dokumentasi.
d. Transition
Melakukan validasi dan integrasi sistem dengan yang berhubungan dengan sistem.[5]
Tahapan yang dilakukan adalah menyerahkan sistem aplikasi ke user disertai pula
pelaksanaan pelatihan sistem kepada user dan testing aplikasi terhadap keinginan
user. Dilakukan pula dokumentasi untuk tahap transition diantaranya pengujian dan
pendataan jika terjadi eror.
AUP menggunakan alur kerja yang linear, namun di tiap aktivitas dilakukan iterasi
sehingga secepat mungkin dapat menghasilkan produk perangkat lunak yang lebih baik.
Iterasi AUP adalah :
a. Modelling
Memahami proses bisnis dari studi kasus, bidang masalah yang ada dalam studi
kasus, dan menemukan solusi yang tepat dalam menangani permasalahan dalam
studi kasus. Solusi yang digunakan berupa perancangan diagram sistem seperti
bisnis usecase, usecase diagram, class diagram, desain interface dan desain database.
Iterasi modelling lebih banyak dilakukan dalam tahapan inception dan elaboration.
b. Implementation
Model diterjemahkan kedalam bentuk source code. Diuji secara dasar dan diuji
dalam letak tertentu. Implementation digunakan pada tahapan elaboration dalam
melakukan implementasi perancangan diagram kebutuhan sistem dan pada tahap
construction sebagai implementasi desain sistem kedalam bahasa pemrograman.
c. Testing
Mendesain dan melakukan pengujian untuk memastikan apakah hasil rancangan
maupun implementasi yang telah dibuat sesuai dengan kebutuhan. Testing dilakukan
mulai dari tahap elaboration sebagai pengujian hasil rancangan sistem dan pada
tahap construction sebagai pengujian modul-modul yang ada dalam sistem
sedangkan dalam tahap transition sebagai pengujian terhadap kepuasan user.
d. Deployment
Fokus pada penerimaan software oleh user dan evaluasi dari user. Iterasi ini hanya
dilakukan dalam tahapan construction akhir menuju tahap transition sebagai salah
satu aktifitas integrasi sistem dari pengembang kepada user.
e. Configuration
Management Mengatur akses terhadap kerangka sistem. Mencakup selalu
mengetahui versi sistem, mengontrol dan mengatur perubahan yang terjadi.
Configuration Management lebih fokus terhadap hal internal sistem.
f. Project Management
Menunjukkan aktivitas yang harus dikerjakan dalam project, mencakup menangani
kemungkinan kerugian, berhubungan dengan manusia (memberikan tugas,
mengetahui progress dll), berkoordinasi dengan tim dan sistem diluar jangkauan dari
proyek untuk memastikan tepat waktu dan tepat biaya. Selain itu melakukan
dokumentasi pada perubahan sistem secara terus menerus. Project Management
lebih difokuskan terhadap komunikasi antara tim pengembang sistem terhadap user
yang akan menerima dan menggunakan sistem.
g. Environment Management
Mendukung dalam pengembangan proyek dengan tujuan proses dapat berjalan
sesuai dengan agenda dan prosedur, dan memastikan tools yang tersedia sudah
sesuai dengan kebutuhan. Aktifitas yang dilakukan adalah menjamin sarana dan
prasarana yang dibutuhkan dalam segala kegiatan pembangunan sistem.

Kelebihan dan kekurangan :

Kelebihan :

 Meningkatkan kepuasan kepada klien.


 Dapat melakukan
 review pelanggan mengenai software yang dibuat lebih awal.
 Pembangunan system dibuat lebih cepat.
 Mengurangi resiko kegagalan implementasi software dari segi non-teknis.
 Jika pada saat pembangunan system terjadi kegagalan kerugian dari segi materi
relatif kecil.

Kekurangan :

 Developer harus selalu siap dengan perubahan karena perubahan akan selalu
diterima.
 Agile tidak akan berjalan dengan baik jika komitmen tim kurang.
 Tidak cocok dalam skala tim yang besar (>20 orang).
 Perkiraan waktu release dan harga perangkat lunak sulit ditentukan.
3. Pengukuran perangkat lunak
Perangkat lunak dapat diukur dengan melihat dari sudut pandang proses
pengembangan perangkat lunak (proses) dan hasil produk yang dihasilkan (product). Dari
sudut pandang process standart ISO 1900 dapat digunakan untuk mengukur kualitas
perangkat lunak Dan diskusi tentang ini berkembang dengan munculnya tema kajian
tentang CMM (The Capability Maturity Model) yang dikembangkan di Software
Engineering Institute, Carnegie Mellon University serta beberapa kajian lain seperti
SPICE (Software Process Improvement and Capability dEtermination) dan
BOOTSTRAP. CMM, SPICE dan BOOTSTRAP mengukur kualitas perangkat lunak dari
seberapa matang proses pengembangannya.
Sedangkan dari sudut pandang product pengukuran perangkat lunak dapat
menggunakan standart dari ISO 9126 atau best practice yang dikembangkan para praktis
dan pengembang perangkat lunak.
PARAMETER DAN METODE PENGUKURAN
Pendekatan engineering menginginkan bahwa kualitas perangkat lunak ini dapat diukur
secara kuantitatif, dalam bentuk angka-angka yang mudah dipahami oleh manusia. Untuk
itu perlu ditentukan parameter atau atribut pengukuran

Kualitas software diukur dengan metode penjumlahan dari keseluruhan kriteria


dalam suatu faktor sesuai dengan bobot (weight) yang telah ditetapkan [2]. Rumus
pengukuran yang digunakan adalah:
Fa = w1c1 + w2c2 + … + wncn
Dimana:
Fa adalah nilai total dari faktor
wi adalah bobot untuk kriteria
ci adalah nilai untuk kriteria
Kemudian tahapan yang harus kita tempuh dalam pengukuran adalah sebagai berikut:
Tahap 1: Tentukan kriteria yang digunakan untuk mengukur suatu faktor
Tahap 2: Tentukan bobot (w) dari setiap kriteria (biasanya 0 <= w <= 1)
Tahap 3: Tentukan skala dari nilai kriteria (misalnya, 0 <= nilai kriteria <= 10)
Tahap 4: Berikan nilai pada tiap kriteria
Tahap 5: Hitung nilai total dengan rumus Fa = w1c1 + w2c2 + … + wncn

5. Tantangan penerapan RPL dalam pengembangan PL

a. Metode yang digunakan untuk mengembangkan sistem pada proyek skala kecil atau
menengah tidak sesuai bila diterapkan pada pengembangan sistem berskala besar atau
kompleks.
b. Perubahan dalam pengembangan perangkat lunak tidak dapat dihindari. Era sekarang
ini, perubahan terjadi dengan cepat dan harus dapat mengakomodasi perubahan ini
untuk mengembangkan perangkat lunak yang lengkap merupakan salah satu tantangan
utama yang dihadapi oleh para insinyur perangkat lunak (software engineer).
c. Kemajuan teknologi komputer dan perangkat lunak mengharuskan perubahan sifat
sistem perangkat lunak. Sistem perangkat lunak yang tidak dapat mengakomodasi
perubahan maka tidak akan banyak berguna. Dengan demikian, salah satu tantangan
rekayasa perangkat lunak adalah menghasilkan perangkat lunak berkualitas tinggi
yang mampu beradaptasi dengan kebutuhan yang berubah sesuai waktu yang dapat
diterima. Untuk memenuhi tantangan ini, pendekatan berorientasi objek lebih
diutamakan, namun mengakomodasi perubahan pada perangkat lunak dan
perawatannya dengan biaya yang dapat diterima masih merupakan tantangan
tersendiri.
d. Komunikasi informal mengambil sebagian besar waktu yang dihabiskan untuk proyek
perangkat lunak. Pemborosan waktu seperti itu dapat menunda penyelesaian proyek
dalam waktu yang telah ditentukan.
e. Pengguna umumnya memiliki gagasan samar tentang ruang lingkup dan persyaratan
sistem perangkat lunak. Hal ini biasanya menghasilkan pengembangan perangkat
lunak, yang tidak sesuai dengan ekspektasi pengguna.
f. Perubahan biasanya digabungkan dalam dokumen tanpa mengikuti prosedur standar
apapun. Dengan demikian, kegiatan verifikasi semua perubahan tersebut seringkali
menjadi sulit.
g. Pengembangan perangkat lunak yang berkualitas dan handal memerlukan perangkat
lunak untuk diuji secara menyeluruh. Meskipun pengujian menyeluruh terhadap
perangkat lunak menghabiskan sebagian besar sumber daya, tetapi apabila
meremehkannya dapat menyebabkan memburuknya kualitas perangkat lunak.

Anda mungkin juga menyukai