Model Proses Rekayasa Perangkat Lunak

TUGAS RUMAH
diajukan untuk memenuhi salah satu tugas mata kuliah Rekayasa Perangkat
Lunak
yang diampu oleh Rasim, S.T., M.T.


Disusun oleh:

1206350
Isnaeni Rahmawati





PROGRAM STUDI PENDIDIKAN ILMU KOMPUTER
FAKULTAS PENDIDIKAN MATEMATIKA DAN IPA
UNIVERSITAS PENDIDIKAN INDONESIA
2014
Model Proses Rekayasa Perangkat Lunak

Model proses perangkat lunak adalah gambaran abstrak dari suatu proses.
Model ini menyajikan deskripsi suatu proses dari beberapa sudut pandang
tertentu.

1. Waterfall Model / Linear Sequential Model
Waterfall model adalah model yang melakukan pendekatan pada
perkembangan perangkat lunak secara seistematik dan sekuensial. Yang
artinya kegiatan pada model ini dilakukan secara terurut berdasarkan
panduan proses mulai dari komunikasi kepada client atau pelanggan sampai
dengan aktifitas sampai pengorderan setelah masalah dipahami secara
lengkap dan berjalan stabil sampai selesai.

Ada 2 fase-fase dalam Waterfall model :
Menurut referensi Pressman

Menurut referensi Sommerville
Kedua fase-fase menggunakan nama yang berbeda pada tiap fasenya,
tetapi pada dasarnya inti dari kedua fase-fase tersebut adalah sama.
Tahapan-tahapan yang yang sering dijumpai adalah menurut refrensi dari
Sommerville karena lebih terperinci perbedaan pada tiap fasenya.


a. Requirements definition
b. System and software design
c. Implementation and unit testing
d. Integration and system testing
e. Operation and maintenance


Kelebihan Model Waterfall:
Bisa digunakan jika suatu persyaratan untuk membuat suatu software
sudah dipahami dengan baik dan sudah lengkap semua persyaratan yang
ada.


Kekurangan Model Waterfall:
Waterfall model bersifat kaku sehingga sulit untuk melakukan
perubahan pada sistem perangkat lunak.
Terjadinya pembagian proyek menjadi tahap-tahap yang tidak
fleksibel, karena komitmen harus dilakukan pada tahap awal proses.
Hal ini mengakibatkan sulitnya untuk merespon perubahan kebutuhan
pengguna (user).
Model air terjun harus digunakan hanya ketika persyaratan dipahami
dengan baik.

2. Incremental Proses Model
a. The Incremental Model
Dalam model Incremental ini proses pengerjaan perangkat lunak akan
dilakukan perbagian sehingga bagian selanjutnya akan dikerjakan
setelah bagian awal telah selesai dan selanjutnya sampai menghasilkan
perangkat lunak yang lengkap dengan semua fungsi yang diperlukan dan
pengerjaan perangkat lunak berakhir. Sebelum pengerjaan perangkat
lunak akan dilakukan perancangan arsitektur software sebagai kerangka
dalam pengerjaan perbagian.


Tahapan dari Incremental Model :
Requirement : penentuan kebutuhan perangkat lunak yang akan dibangun.
Specification : spesifikasi bagian dari perangkat lunak.
Architecture Design : pembuatan perancangan perangkat lunak (dasar
dari kerangka kerja)


Kelebihan Incremental Model :
Resiko yang rendah pada pengembangan sistem.
Mengutamakan fungsi-fungsi pada sistem perangkat lunak sehingga
kemudahan pemakaian sistem yang paling di utamakan.
Tahap awal adalan dasar dari pembuatan tahap berikutnya
(dikerjakan secara terurut)
Model ini cocok jika jumlah anggota tim pengembang/pembangun PL
tidak cukup.
Mampu mengakomodasi perubahan secara fleksibel.


Kekurangan Incremental Model :
Hanya cocok untuk proyek berukuran kecil (tidak lebih dari
200.000 baris coding)
Mungkin terjadi kesulitan untuk memetakan kebutuhan pengguna ke
dalam rencana spesifikasi masing-masing hasil increment


b. The RAD Model (Rapid Aplication Development)
RAD (Rapid Application Development) adalah model proses yang juga
termasuk dalam Incremental Proses Model karena pembangunan dari
sistem perangkat lunak dikerjakan dengan tahapan yang terurut mulai
dari dasar (awal) sampai tahap paling tinggi (proses akhir
pembuatan), tetapi perbedaannya model ini dibagi menjadi beberapa
modul dan dikerjakan secara besama-sama dan sesuai dengan waktu yang
ditentukan.


RAD adalah sebuah model proses perkembangan software sekuensial
linier yang menekankan siklus perkembangan yang sangat pendek. Model
RAD ini merupakan sebuah adaptasi "kecepatan tinggi" dari model
sekuensial linier di mana perkembangan cepat dicapai dengan
menggunakan pendekatan kontruksi berbasis komponen. Jika kebutuhan
dipahami dengan baik, proses RAD memungkinkan tim pengembangan
menciptakan "sistem fungsional yang utuh" dalam periode waktu yang
sangat pendek (kira-kira 60 sampai 90 hari). Karena dipakai terutama
pada aplikasi sistem konstruksi, pendekatan RAD melingkupi fase –
fase sebagai berikut :
1. Bussiness modeling
Aliran informasi di antara fungsi – fungsi bisnis dimodelkan
dengan suatu cara untuk menjawab pertanyaan – pertanyaan berikut :
informasi apa yang mengendalikan proses bisnis? Informasi apa yang di
munculkan? Siapa yang memunculkanya? Ke mana informasi itu pergi?
Siapa yang memprosesnya?


2. Data modeling
Aliran informasi yang didefinisikan sebagai bagian dari fase
bussiness modelling disaring ke dalam serangkaian objek data yang
dibutuhkan untuk menopang bisnis tersebut. Karakteristik (disebut
atribut) masing–masing objek diidentifikasi dan hubungan antara objek
– objek tersebut didefinisikan.


3. Prosess modelling
Aliran informasi yang didefinisikan di dalam fase data modeling
ditransformasikan untuk mencapai aliran informasi yang perlu bagi
implementasi sebuah fungsi bisnis. Gambaran pemrosesan diciptakan
untuk menambah, memodifikasi, menghapus, atau mendapatkan kembali
sebuah objek data.


4. Aplication generation
RAD mengasumsikan pemakaian teknik generasi ke empat. Selain
menciptakan perangkat lunak dengan menggunakan bahasa pemrograman
generasi ketiga yang konvensional, RAD lebih banyak memproses kerja
untuk memkai lagi komponen program yang ada ( pada saat memungkinkan)
atau menciptakan komponen yang bisa dipakai lagi (bila perlu). Pada
semua kasus, alat – alat bantu otomatis dipakai untuk memfasilitasi
konstruksi perangkat lunak.


5. Testing and turnover
Karena proses RAD menekankan pada pemakaian kembali, banyak
komponen program telah diuji. Hal ini mengurangi keseluruhan waktu
pengujian. Tetapi komponen baru harus di uji dan semua interface
harus dilatih secara penuh.

Kelebihan RAD Model :
Pengerjaan sistem yang cepat (60 -90 hari)
RAD dapat menggunakan kembali komponen yang ada (reusable
object) sehingga pengembang pengembang tidak perlu membuat dari
awal lagi.
Proses pengiriman menjadi lebih mudah karena proses pembuatan
berupa potongan- potongan script
Lebih efektif dari pendekatan air terjun dalam menghasilkan
sistem yang memenuhi kebutuhan langsung dari pelanggan.
Cocok untuk proyek yang memerlukan waktu yang singkat.

Kekurangan RAD Model :
Tidak tepat untuk sistem yang berukuran besar (sangat tidak
cocok untuk proyek skala besar)
RAD memerlukan sumber daya manusia yang memadai untuk
menciptakan jumlah tim RAD yang baik.
Pembuatan sistem bisa gagal jika waktu kesepakatan tidak
terpenuhi (terlalu cepat atau permintaan agar diselesaikan lebih
cepat dari perjanjian).
Mempunyai banyak resiko karena dikerjakan dalam modul yang
berbeda dan dalam waktu yang hampir bersamaan dan pada tempat
yang belum tentu sama.
RAD menuntut pengembangan dan pelanggan memiliki komitmen di
dalam aktivitas rapid-fire yang diperlukan untuk melengkapi
sebuah sistem, di dalam kerangka waktu yang sangat diperpendek.
Jika komitmen tersebut tidak ada, proyek RAD akan gagal.


3. Evolutionary Software Process Models
a. Protoyping Model
Protoyping Model adalah model yang dapat diterapkan pada model
apapun. Model ini tidak memerlukan data yang lengkap dari sisi client
dan banyaknya keraguan dari pembuat software karena kondisi yang
belum diketahui (seberapa besar software, bagaimana sistem
penerapannya). Model ini tepat digunakan jika pihak client
menginginkan prototype dari software dalam waktu yang singkat. Dan
prototype inilah yang akan menjadi acuan dari client untuk memberikan
data kebutuhan yang lebih lengkap pada pembuat software (developer).
Metode prototyping adalah sistem informasi yang menggambarkan hal-
hal penting dari sistem informasi yang akan datang. Prototipe sistem
informasi bukanlah merupakan sesuatu yang lengkap, tetapi sesuatu
yang harus dimodifikasi kembali, dikembangkan, ditambahkan atau
digabungkan dengan sistem informasi yang lain bila perlu.

Penjelasan dari gambar di atas sebagai berikut:
User merasa prototipe merupakan PL yang sesungguhnya, padahal
ketika membuat prototipe belum disertakan kualitas PL secara
keseluruhan / kemampuan pemeliharaan untuk jangka panjang
Developer sering membuat kompromi-kompromi implementasi untuk
membuat prototipe bekerja dengan cepat sehingga akan ditemui
ketidakcocokan pada prototipe ketika prototipe dibangun dengan
bahasa yang sederhana
Program dibuat ulang / prototipe selalu baru

Mengacu pada pemilahan fungsi yang harus ditampilkan oleh
prototyping. Pemilahan harus selalu dilakukan berdasarkan pada tugas-
tugas yang relevan yang sesuai dengan contoh kasus yang akan
diperagakan

Jenis-Jenis Prototyping
Feasibility Prototyping – digunakan untuk menguji kelayakan dari
teknologi yang akan digunakan untuk system informasi yang akan
disusun.
Requirement Prototyping – digunakan untuk mengetahui kebutuhan
aktivitas bisnis user.
Desain Prototyping - digunakan untuk mendorong perancangan system
informasi yang akan digunakan.
Implementation Prototyping – merupakan lanjytan dari rancangan
protipe, prototype ini langsung disusun sebagai suatu system
informasi yang akan digunakan.

Kelebihan Prototyping Model :
User dapat berpartisipasi aktif
Penentuan kebutuhan lebih mudah diwujudkan
Mempersingkat waktu pengembangan SI


Kekurangan Prototyping Model :
Proses analisis dan perancangan terlalu singkat
Mengesampingkan alternatif pemecahan masalah
Biasanya kurang fleksible dalam mengahadapi perubahan
Prototype yang dihasilkan tidak selamanya mudah dirubah
.Banyak ketidak sesuaian pada bentuk prototype.
Prototype terlalu cepat selesai
Pada prototype tentu saja banyak kebutuhan yang tidak di
tampilkan seluruhnya karena data yang dikumpulkan hanya
sebagian.
Prototype yang di setujui oleh client harus dikembangkan oleh
developer tanpa ada data tambahan dari client dan software dari
prototype harus memiliki fungsi yang lengkap.

b. Spiral Model
Model ini cukup baru ditemukan,yaitu tahun 1988 oleh Barry Boehm.
Spiral adalah salah satu bentuk evolusi yang menggunakan metode
iterasi natural yang dimiliki oleh model prototyping dan digabungkan
dengan aspek sistematis yang dikembangkan model waterfall.
Spiral model dibagi menjadi beberapa framework aktivitas, yang
disebut dengan task regions. Kebanyakan aktivitas2 tersebut dibagi
antara 3 sampai 6 aktivitas. Berikut adalah aktivitas-aktivitas yang
dilakukan dalam spiral model:

Customer Communication. Aktivitas yang dibutuhkan untuk
membangun komunikasi yang efektif antara developer dengan user /
customer terutama mengenai kebutuhan dari customer.
Planning. Aktivitas perencanaan ini dibutuhkan untuk menentukan
sumberdaya, perkiraan waktu pengerjaan, dan informasi lainnya
yang dibutuhkan untuk pengembangan software.
Analysis risk. Aktivitas analisis resiko ini dijalankan untuk
menganalisis baik resiko secara teknikal maupun secara
manajerial. Tahap inilah yang mungkin tidak ada pada model
proses yang juga menggunakan metode iterasi, tetapi hanya
dilakukan pada spiral model.
Engineering. Aktivitas yang dibutuhkan untuk membangun 1 atau
lebih representasi dari aplikasi secara teknikal.
Construction & Release. Aktivitas yang dibutuhkan untuk develop
software, testing, instalasi dan penyediaan user / costumer
support seperti training penggunaan software serta dokumentasi
seperti buku manual penggunaan software.
Customer evaluation. Aktivitas yang dibutuhkan untuk mendapatkan
feedback dari user / customer berdasarkan evaluasi mereka selama
representasi software pada tahap engineering maupun pada
implementasi selama instalasi software pada tahap construction
and release.


Kelebihan model Spiral :
Dapat disesuaikan agar perangkat lunak bisa dipakai selama hidup
perangkat lunak komputer.
Lebih cocok untuk pengembangan sistem dan perangkat lunak skala
besar
Pengembang dan pemakai dapat lebih mudah memahami dan bereaksi
terhadap resiko setiap tingkat evolusi karena perangkat lunak
terus bekerja selama proses .
Kelemahan model Spiral:
Sulit untuk menyakinkan pelanggan bahwa pendekatan evolusioner
ini bisa dikontrol.
Memerlukan penaksiran resiko yang masuk akal dan akan menjadi
masalah yang serius jika resiko mayor tidak ditemukan dan
diatur.
Butuh waktu lama untuk menerapkan paradigma ini menuju kepastian
yang absolute
4. Extreme Programming (XP) Model
Model proses ini diciptakan dan dikembangkan oleh Kent Beck. Model
ini adalah model proses yang terbaru dalam dunia rekayasa perangkat
lunak dan mencoba menjawab kesulitan dalam pengembangan software yang
rumit dan sulit dalam implementasi.
Menurut Kent Beck XP adalah : "A lightweight, efficient, low-risk,
flexible,predictable, scientific and fun way to develop software". Suatu
model yang menekankan pada:
keterlibatan user secara langsung
pengujian
pay-as-you-go design


Adapun empat nilai penting dari XP
1. Communication/Komunikasi: komunikasi antara developer dan klien
sering menjadi masalah. Karena itu komunikasi dalam XP dibangun
dengan melakukan pemrograman berpasangan (pair programming).
Developer didampingi oleh pihak klien dalam melakukan coding dan
unit testing sehingga klien bisa terlibat langsung dalam
pemrograman sambil berkomunikasi dengan developer. Selain itu
perkiraan beban tugas juga diperhitungkan.
2. Simplicity/ sederhana: Menekankan pada kesederhanaan dalam
pengkodean: "What is the simplest thing that could possibly work?"
Lebih baik melakukan hal yang sederhana dan mengembangkannya besok
jika diperlukan. Komunikasi yang lebih banyak mempermudah, dan
rancangan yang sederhana mengurangi penjelasan.
3. Feedback / Masukan/Tanggapan: Setiap feed back ditanggapi dengan
melakukan tes, unit test atau system integration dan jangan
menunda karena biaya akan membengkak (uang, tenaga, waktu).
4. Courage / Berani: Banyak ide baru dan berani mencobanya, berani
mengerjakan kembali dan setiap kali kesalahan ditemukan, langsung
diperbaiki.






Kelebihan model Extreme Programming :
Komunikasi dalam XP dibangun dengan melakukan pemrograman
berpasangan (pair programming). Developer didampingi oleh pihak
klien dalam melakukan coding dan unit testing sehingga klien
bisa terlibat langsung dalam pemrograman sambil berkomunikasi
dengan developer. Selain itu perkiraan beban tugas juga
diperhitungkan.
Menekankan pada kesederhanaan dalam pengkodean: "What is the
simplest thing that could possibly work?" Lebih baik melakukan
hal yang sederhana dan mengembangkannya besok jika diperlukan.
Komunikasi yang lebih banyak mempermudah, dan rancangan yang
sederhana mengurangi penjelasan.
Setiap feed back ditanggapi dengan melakukan tes, unit test atau
system integration dan jangan menunda karena biaya akan
membengkak (uang, tenaga, waktu).
Banyak ide baru dan berani mencobanya, berani mengerjakan
kembali dan setiap kali kesalahan ditemukan, langsung
diperbaiki.
Kelemahan model Extreme Programming :
Developer harus selalu siap dengan perubahan karena perubahan
akan selalu diterima.
Tidak bisa membuat kode yang detail di awal (prinsip simplicity
dan juga anjuran untuk melakukan apa yang diperlukan hari itu
juga).


REFERENSI
http://www.mdp.ac.id/materi/2012-2013-1/si317/051039/si317-051039-543-
4.pptx
http://aryapramana.blogspot.com/2011/09/model-proses-rekayasa-perangkat-
lunak.html
http://rpl07.wordpress.com/2007/06/21/model-dan-proses-oleh-rona-f-5105-
100-083/
http://if-unsika-2011066.blogspot.com/2013/04/model-linear-
sequentialwaterfall-model.html
http://malikah-tutik.blogspot.com/2013/03/model-proses-rekayasa-
perangkat-lunak.html