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 :
1. Menurut referensi Pressman
2. 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-perangkatlunak.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-sequentialwaterfallmodel.html
http://malikah-tutik.blogspot.com/2013/03/model-proses-rekayasa-perangkat-lunak.html
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 :
1. Menurut referensi Pressman
2. 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-perangkatlunak.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-sequentialwaterfallmodel.html
http://malikah-tutik.blogspot.com/2013/03/model-proses-rekayasa-perangkat-lunak.html