Rekayasa Perangkat Lunak (RPL)
1. Model waterfall Rekayasa Perangkat
Lunak
1. Sejarah
model waterfall
Nama model ini sebenarnya adalah “Linear Sequential Model”.
Model ini sering disebut dengan “classic life cycle” atau model
waterfall. Model ini pertama kali yang diperkenalkan oleh Winston Royce sekitar
tahun 1970 sehingga sering dianggap kuno, tetapi merupakan model yang paling
banyak dipakai didalam Software Engineering (SE). Model ini
melakukan pendekatan secara sistematis dan berurutan. Disebut dengan waterfall karena
tahap demi tahap yang dilalui harus menunggu selesainya tahap sebelumnya dan
berjalan berurutan.
2. Pengertian Waterfall
Waterfall atau AIR terjun adalah model yang dikembangkan untuk
pengembangan perangkat lunak, membuat perangkat lunak. model berkembang
secara sistematis dari satu tahap ke tahap lain dalam mode seperti air terjun.
Model ini mengusulkan sebuah pendekatan kepada pengembangan
software yang sistematikdan sekuensial yang mulai dari tingkat kemajuan sistem
pada seluruh analisis, desain, kode, pengujian dan pemeliharaan. Model ini
melingkupi aktivitas-aktivitas sebgai berikut : rekayasa dan pemodelan sistem
informasi, analisis kebutuhan, desain, koding, mengujian dan pemeliharaan.
Model pengembangan ini bersifat linear dari tahap awal
pengembangan system yaitu tahap perencanaan sampai tahap akhir pengembangan
system yaitu tahap pemeliharaan. Tahapan berikutnya tidak akan dilaksanakan
sebelum tahapan sebelumnya selesai dilaksanakan dan tidak bisa kembali atau
mengulang ke tahap sebelumnya.
3. Tahapan
atau fase model waterfall
Ini adalah gambar tahapan atau fase yang paling umum tentang
model waterfall
Akan tetapi Roger S. Pressman memecah model ini menjadi 6
tahapan meskipun secara garis besar sama dengan tahapan-tahapan model waterfall
pada umumnya. Berikut adalah Gambar dan penjelasan dari tahap-tahap yang
dilakukan di dalam model ini menurut Pressman:
1) System / Information Engineering and
Modeling. Permodelan ini diawali dengan mencari kebutuhan dari keseluruhan
sistem yang akan diaplikasikan ke dalam bentuk software. Hal ini sangat
penting, mengingat software harus dapat berinteraksi dengan elemen-elemen yang
lain seperti hardware, database, dsb. Tahap ini sering disebut dengan Project
Definition.
2) Software Requirements Analysis.
Proses pencarian kebutuhan diintensifkan dan difokuskan pada software. Untuk
mengetahui sifat dari program yang akan dibuat, maka para software engineer
harus mengerti tentang domain informasi dari software, misalnya fungsi yang
dibutuhkan, user interface, dsb. Dari 2 aktivitas tersebut (pencarian kebutuhan
sistem dan software) harus didokumentasikan dan ditunjukkan kepada pelanggan.
3) Design. Proses ini digunakan untuk
mengubah kebutuhan-kebutuhan diatas menjadi representasi ke dalam bentuk
“blueprint” software sebelum coding dimulai. Desain harus dapat
mengimplementasikan kebutuhan yang telah disebutkan pada tahap sebelumnya.
Seperti 2 aktivitas sebelumnya, maka proses ini juga harus didokumentasikan
sebagai konfigurasi dari software.
4) Coding. Untuk dapat dimengerti oleh
mesin, dalam hal ini adalah komputer, maka desain tadi harus diubah bentuknya
menjadi bentuk yang dapat dimengerti oleh mesin, yaitu ke dalam bahasa
pemrograman melalui proses coding. Tahap ini merupakan implementasi dari tahap
design yang secara teknis nantinya dikerjakan oleh programmer.
5) Testing / Verification. Sesuatu yang
dibuat haruslah diujicobakan. Demikian juga dengan software. Semua
fungsi-fungsi software harus diujicobakan, agar software bebas dari error, dan
hasilnya harus benar-benar sesuai dengan kebutuhan yang sudah didefinisikan
sebelumnya.
6) Maintenance. Pemeliharaan suatu
software diperlukan, termasuk di dalamnya adalah pengembangan, karena software
yang dibuat tidak selamanya hanya seperti itu. Ketika dijalankan mungkin saja
masih ada errors kecil yang tidak ditemukan sebelumnya, atau ada penambahan
fitur-fitur yang belum ada pada software tersebut. Pengembangan diperlukan
ketika adanya perubahan dari eksternal perusahaan seperti ketika ada pergantian
sistem operasi, atau perangkat lainnya.
4. Karakteristik
Dalam model ini terdapat beberapa sifat-sifat yang menojol dan
cenderung menjadi permasalahan pada model waterfall.
1) Ketika problem muncul, maka
proses berhenti karena tidak dapat menuju ke
tahapan selanjutnya. Apabila terdapat kemungkinan problem tersebut
muncul akibat kesalahan dari tahapan sebelumnya, maka proses harus membenahi
tahapan sebelumnya agarproblem ini tidak muncul.
2) Karena pendekatannya secara sequential,
maka setiap tahap harus menunggu hasil dari tahap sebelumnya. Hal itu tentu
membuang waktu yang cukup lama, artinya bagian lain tidak dapat mengerjakan hal
lain selain hanya menunggu hasil dari tahap sebelumnya.
5. Mengapa
model ini sangat populer?
Selain karena pengaplikasian menggunakan model ini mudah,
kelebihan dari model ini adalah ketika semua kebutuhan sistem dapat
didefinisikan secara utuh, eksplisit, dan benar di awal project, maka SE dapat
berjalan dengan baik dan tanpa masalah. Meskipun seringkali kebutuhan sistem
tidak dapat didefinisikan seeksplisit yang diinginkan, tetapi paling tidak,
problem pada kebutuhan sistem di awal project lebih ekonomis dalam hal uang
(lebih murah), usaha, dan waktu yang terbuang lebih sedikit jika dibandingkan
problem yang muncul pada tahap-tahap selanjutnya.
Meskipun demikian, karena model ini melakukan pendekatan secara
urut / sequential, maka ketika suatu tahap terhambat, tahap selanjutnya tidak
dapat dikerjakan dengan baik dan itu menjadi salah satu kekurangan dari model
ini.
6. Kapan
model waterfall di gunakan?????
Salah satu model tradisional dan mudah yang tahapannya mengalir
satu arah seperti air terjun adalah Waterfall Model atau
Linear Sequential Model. Pertanyaannya, kapan sebaiknya model tersebut
digunakan?
Teori-teori lama menyimpulkan ada beberapa hal, yaitu:
Teori-teori lama menyimpulkan ada beberapa hal, yaitu:
1) Ketika semua persyaratan sudah
dipahami dengan baik di awal pengembangan.
2) Definisi produk stabil dan
tidak ada perubahan saat pengembangan untuk alasan apapun seperti perubahan
eksternal, perubahan tujuan, perubahan anggaran atau perubahan teknologi. Untuk
itu, teknologi yang digunakan pun harus sudah dipahami dengan baik.
3) Menghasilkan produk baru, atau
versi baru dari produk yang sudah ada. Sebenarnya, jika menghasilkan versi baru
maka sudah masuk incremental
development, yang setiap tahapnya sama dengan Waterfall kemudian
diulang-ulang.
4) Porting produk
yang sudah ada ke dalam platform baru.
Dengan demikian, Waterfall dianggap pendekatan yang lebih cocok
digunakan untuk proyek pembuatan sistem baru. Tetapi salah satu kelemahan
paling dasar adalah menyamakan pengembangan perangkat keras dengan perangkat
lunak dengan meniadakan perubahan saat pengembangan. Padahal, galat diketahui
saat perangkat lunak dijalankan, dan perubahan-perubahan akan sering terjadi.
7. Tahap
Pengembangan Waterfal
Tahap – tahap pengembangan waterfall model adalah :
1) Analisis dan definisi
persyaratan Pelayanan, batasan, dan tujuan sistem ditentukan melalui
konsultasi dengan user.
2) Perancangan sistem dan
perangkat lunak Kegiatan ini menentukan arsitektur sistem secara keseluruhan.
3) Implementasi dan pengujian unit
Perancangan perangkat lunak direalisasikan sebagai serangkaian program.
4) Integrasi dan pengujian sistem
Unit program diintegrasikan atau diuji sebagai sistem yang lengkap untuk
menjamin bahwa persyaratan sitem telah terpenuhi
5) Operasi dan pemeliharaan
Merupakan fase siklus yang paling lama. Sistem diinstall dan dipakai. Perbaikan
mencakup koreksi dari berbagai error, perbaikan dan implementasi unit sistem
dan pelayanan sistem.
8. Keuntungan
dari Model Waterfall
1) Merupakan model pengembangan
paling handal dan paling lama digunakan.
2) Cocok untuk system software
berskala besar.
3) Cocok untuk system
software yang bersifat generic.
4) Pengerjaan project system
akan terjadwal dengan baik dan mudah dikontrol
9. Kelemahan
Waterfall
1) Waktu pengembangan lama. hal ini dikarenakan
input tahap berikutnya adalah output dari tahap sebelumnya. Jika satu tahap
waktunya molor, maka waktu keseluruhan pengembangan juga ikut molor.
2) Biaya juga mahal, hal ini juga dikarenakan waktu
pengembangan yang lama
3) Terkadang perangkat lunak yang dihasilkan tidak
akan digunakan karena sudah tidak sesuai dengan requirement bisnis customer.
hal ini juga dikarenakan waktu pengembangan yang lama. selain itu dikarenakan
waterfall merupakan aliran yang linear, sehingga jika requirement berubah
proses tidak dapat diulang lagi.
4) Karena tahap-tahapan pada waterfall tidak dapat
berulang, maka model ini tidak cocok untuk pemodelan pengembangan sebuah proyek
yang memiliki kompleksitas tinggi.
5) Meskipun waterfall memiliki banyak
kelemahan yang dinilai cukup fatal, namun model ini merupakan dasar bagi model-model
lain yang dikembangkan setelahnya.
Referensi :
Prototype adalah sebuah Javascript Framework yang dibuat
untuk lebih memudahkan proses dalam membangun aplikasi berbasis web.
Metode protyping sebagai suatu paradigma baru dalam
pengembangan sistem informasi, tidak hanya sekedar suatu evolusi dari metode
pengembangan sistem informasi yang sudah ada, tetapi sekaligus merupakan
revolusi dalam pengembangan sistem informasi manajemen
Ada 2 Jenis Prototype :
Jenis I : Suatu Sistem yang akan menjadi sistem operasional
Jenis II : Suatu model yang dapat dibuang yang berfungsi
sebagai cetak biru bagi sistem operasional.
Karakteristik metode prototyping meliputi langkah-langkah :
1. Pemilahan fungsi
2. Penyusunan Sistem Informasi
3. Evaluasi
4. Penggunaan Selanjutnya
1. Pemilahan fungsi
2. Penyusunan Sistem Informasi
3. Evaluasi
4. Penggunaan Selanjutnya
Jenis-jenis prototyping meliputi
1. Feasibility prototyping
2. Requirement prototyping
3. Desain Prototyping
4. Implementation prototyping
1. Feasibility prototyping
2. Requirement prototyping
3. Desain Prototyping
4. Implementation prototyping
Teknik-teknik prototyping meliputi
1. Perancangan Model
2. Perancangan Dialog
3. Simulasi
1. Perancangan Model
2. Perancangan Dialog
3. Simulasi
SISTEM YANG BERMANFAAT DARI PROTOTIPE
(SYSTEMS THAT BENEFIT FROM PROTOTYPING)
(SYSTEMS THAT BENEFIT FROM PROTOTYPING)
Sejak kebutuhan (baca Spesifikasi Fungsi) pada umumnya
berhubungan dengan pandangan user terhadap sistem, hanya dengan prototipe
tampilan bagi user sudah cukup untuk memeriksa yang dibutuhkan. Menu-menu,
bentuk tampilan input, tampilan keluaran, atau laporan yang dicetak,
pertanyaan-pertanyaan, pesan-pesan merupakan calon yang ideal untuk prototipe.
Di lain pihak, perhitungan yang rumit, kumpulan update data
dan realtime, dan sistem yang bersifat scientific sangat sulit untuk dijadikan
model.
Sistem yang paling sesuai untuk prototipe adalah satu dari
banyak hal yang bergantung pada sistem input/output dari user. Sistem dengan
transaksi on-line dikendalikan melalui menu, layar, formulir,
laporan, daftar dan perintah.
laporan, daftar dan perintah.
Keuntungan dari prototipe
Menghasilkan syarat yang lebih baik dari produksi yang
dihasilkan oleh metode ‘spesifikasi tulisan’.
User dapat mempertimbangkan sedikit perubahan selama masih
bentuk prototipe.
Memberikan hasil yang lebih akurat dari pada perkiraan
sebelumnya, karena fungsi yang diinginkan dan kerumitannya sudah dapat
diketahui dengan baik.
User merasa puas. Pertama, user dapat mengenal melalui
komputer. Dengan melakukan prototipe (dengan analisis yang sudah ada), user
belajar mengenai komputer dan aplikasi yang akan dibuatkan untuknya. Kedua,
user terlibat langsung dari awal dan memotivasi semangat untuk mendukung
analisis selama proyek berlangsung.
PROTOTYING
Adalah merupakan salah satu metode pengembangan perangat lunak yang banyak
digunakan. Dengan metode prototyping ini pengembang dan pelanggan dapat saling
berinteraksi selama proses pembuatan sistem.
Untuk mengatasi ketidakserasian antara pelanggan dan pengembang , maka harus
dibutuhakan kerjasama yanga baik diantara keduanya sehingga pengembang akan
mengetahui dengan benar apa yang diinginkan pelanggan dengan tidak mengesampingkan
segi-segi teknis dan pelanggan akan mengetahui proses-proses dalm menyelasaikan sistem
yang diinginkan. Dengan demikian akan menghasilkan sistem sesuai dengan jadwal waktu
penyelesaian yang telah ditentukan.
Kunci agar model prototype ini berhasil dengan baik adalah dengan mendefinisikan
aturan-aturan main pada saat awal, yaitu pelanggan dan pengembang harus setuju bahwa
prototype dibangun untuk mendefinisikan kebutuhan. Prototype akan dihilangkan sebagian
atau seluruhnya dan perangkat lunak aktual aktual direkayasa dengan kualitas dan
implementasi yang sudah ditentukan.
Tahapan-tahapan Prototyping
Tahapan-tahapan dalam Prototyping adalah sebagai berikut:
1. Pengumpulan kebutuhan
Pelanggan dan pengembang bersama-sama mendefinisikan format seluruh perangkat
lunak, mengidentifikasikan semua kebutuhan, dan garis besar sistem yang akan
dibuat.
2. Membangun prototyping
Membangun prototyping dengan membuat perancangan sementara yang berfokus
pada penyajian kepada pelanggan (misalnya dengan membuat input dan format
output).
PROTOTYPE,,
Sebuah Javascript Framework yang dibuat untuk lebih memudahkan proses dalam membangun aplikasi berbasis web.
Metode protyping sebagai suatu paradigma baru dalam pengembangan sistem informasi, tidak hanya sekedar suatu evolusi dari metode pengembangan sistem informasi yang sudah ada, tetapi sekaligus merupakan revolusi dalam pengembangan sistem informasi manajemen
Jenis Prototype :
Jenis I : Suatu Sistem yang akan menjadi sistem operasional
Jenis II : Suatu model yang dapat dibuang yang berfungsi sebagai cetak biru bagi sistem operasional.
Karakteristik metode prototyping meliputi langkah-langkah :
1. Pemilahan fungsi
2. Penyusunan Sistem Informasi
3. Evaluasi
4. Penggunaan Selanjutnya
Jenis-jenis prototyping :
1. Feasibility prototyping
2. Requirement prototyping
3. Desain Prototyping
4. Implementation prototyping
Teknik-Teknik Prototyping :
1. Perancangan Model
2. Perancangan Dialog
3. Simulasi
RINGKASAN:
Dalam pendekatan ini prototipe dibangun dengan gagasan bahwa hal itu akan dibuang dan sistem final akan dibangun dari awal. Langkah-langkah dalam pendekatan ini adalah:
1. Menulis persyaratan pendahuluan
2. Desain prototipe
3. Pengguna pengalaman / menggunakan prototipe, menentukan syarat-syarat baru
4. Ulangi jika perlu
5. Tulis persyaratan akhir
6. Mengembangkan produk nyata
Evolutionary prototyping
Evolutionary Prototyping (juga dikenal sebagai prototipe papan tempat memotong roti) adalah sangat berbeda dari throwaway Prototyping. Tujuan utama ketika menggunakan Evolutionary Prototyping adalah untuk membangun prototipe yang sangat kuat dengan cara yang terstruktur dan terus-menerus memperbaikinya. "Alasan untuk ini adalah bahwa evolusi prototipe, ketika dibangun, bentuk jantung dari sistem baru, dan perbaikan dan persyaratan lebih lanjut akan dibangun.
Ketika mengembangkan sistem dengan menggunakan Evolutionary Prototyping, sistem ini terus-menerus disempurnakan dan dibangun kembali.
" evolusi prototipe mengakui bahwa kita tidak memahami semua persyaratan dan membangun hanya mereka yang dipahami dengan baik." Teknik ini memungkinkan tim pengembangan untuk menambahkan fitur, atau membuat perubahan yang tidak dapat dipahami selama persyaratan dan tahap perancangan.
Untuk sistem yang akan berguna, itu harus berkembang melalui penggunaan dimaksudkan dalam lingkungan operasional. Sebuah produk tidak pernah "dilakukan;" itu selalu jatuh tempo sebagai perubahan lingkungan penggunaan? Kita sering mencoba untuk mendefinisikan sebuah sistem dengan menggunakan kita yang paling akrab --- kerangka acuan di mana kita sekarang. Kita membuat asumsi tentang cara bisnis akan dilakukan dan berbasis teknologi bisnis yang akan dilaksanakan. Sebuah rencana dijalankan untuk mengembangkan kemampuan, dan, cepat atau lambat, sesuatu yang mirip dengan sistem membayangkan dikirimkan.
Prototip evolusi memiliki keuntungan lebih throwaway Prototip dalam bahwa mereka adalah sistem fungsional. Walaupun mereka mungkin tidak memiliki semua fitur yang pengguna telah direncanakan, mereka dapat digunakan pada basis sementara sampai sistem terakhir dikirim.
"Sudah lazim dalam lingkungan prototipe bagi pengguna untuk menempatkan prototipe awal untuk penggunaan praktis sambil menunggu versi yang lebih maju? Pengguna dapat memutuskan bahwa sebuah 'cacat' sistem yang lebih baik daripada tidak ada sistem sama sekali."
Dalam Evolutionary Prototyping, pengembang dapat memfokuskan diri untuk mengembangkan bagian-bagian dari sistem yang mereka mengerti daripada bekerja pada pengembangan sistem secara keseluruhan.
Untuk meminimalkan risiko, pengembang tidak mengimplementasikan fitur kurang dipahami. Sistem parsial dikirim ke situs pelanggan. Sebagai pengguna bekerja dengan sistem, mereka mendeteksi kesempatan untuk fitur-fitur baru dan memberikan permintaan fitur ini untuk pengembang. Pengembang kemudian mengambil permintaan tambahan ini bersama-sama dengan mereka sendiri dan menggunakan konfigurasi suara-praktik manajemen untuk mengubah perangkat lunak-persyaratan spesifikasi, update desain, recode dan tes ulang.
Adalah merupakan salah satu metode pengembangan perangat lunak yang banyak
digunakan. Dengan metode prototyping ini pengembang dan pelanggan dapat saling
berinteraksi selama proses pembuatan sistem.
Untuk mengatasi ketidakserasian antara pelanggan dan pengembang , maka harus
dibutuhakan kerjasama yanga baik diantara keduanya sehingga pengembang akan
mengetahui dengan benar apa yang diinginkan pelanggan dengan tidak mengesampingkan
segi-segi teknis dan pelanggan akan mengetahui proses-proses dalm menyelasaikan sistem
yang diinginkan. Dengan demikian akan menghasilkan sistem sesuai dengan jadwal waktu
penyelesaian yang telah ditentukan.
Kunci agar model prototype ini berhasil dengan baik adalah dengan mendefinisikan
aturan-aturan main pada saat awal, yaitu pelanggan dan pengembang harus setuju bahwa
prototype dibangun untuk mendefinisikan kebutuhan. Prototype akan dihilangkan sebagian
atau seluruhnya dan perangkat lunak aktual aktual direkayasa dengan kualitas dan
implementasi yang sudah ditentukan.
Tahapan-tahapan Prototyping
Tahapan-tahapan dalam Prototyping adalah sebagai berikut:
1. Pengumpulan kebutuhan
Pelanggan dan pengembang bersama-sama mendefinisikan format seluruh perangkat
lunak, mengidentifikasikan semua kebutuhan, dan garis besar sistem yang akan
dibuat.
2. Membangun prototyping
Membangun prototyping dengan membuat perancangan sementara yang berfokus
pada penyajian kepada pelanggan (misalnya dengan membuat input dan format
output).
PROTOTYPE,,
Sebuah Javascript Framework yang dibuat untuk lebih memudahkan proses dalam membangun aplikasi berbasis web.
Metode protyping sebagai suatu paradigma baru dalam pengembangan sistem informasi, tidak hanya sekedar suatu evolusi dari metode pengembangan sistem informasi yang sudah ada, tetapi sekaligus merupakan revolusi dalam pengembangan sistem informasi manajemen
Jenis Prototype :
Jenis I : Suatu Sistem yang akan menjadi sistem operasional
Jenis II : Suatu model yang dapat dibuang yang berfungsi sebagai cetak biru bagi sistem operasional.
Karakteristik metode prototyping meliputi langkah-langkah :
1. Pemilahan fungsi
2. Penyusunan Sistem Informasi
3. Evaluasi
4. Penggunaan Selanjutnya
Jenis-jenis prototyping :
1. Feasibility prototyping
2. Requirement prototyping
3. Desain Prototyping
4. Implementation prototyping
Teknik-Teknik Prototyping :
1. Perancangan Model
2. Perancangan Dialog
3. Simulasi
RINGKASAN:
Dalam pendekatan ini prototipe dibangun dengan gagasan bahwa hal itu akan dibuang dan sistem final akan dibangun dari awal. Langkah-langkah dalam pendekatan ini adalah:
1. Menulis persyaratan pendahuluan
2. Desain prototipe
3. Pengguna pengalaman / menggunakan prototipe, menentukan syarat-syarat baru
4. Ulangi jika perlu
5. Tulis persyaratan akhir
6. Mengembangkan produk nyata
Evolutionary prototyping
Evolutionary Prototyping (juga dikenal sebagai prototipe papan tempat memotong roti) adalah sangat berbeda dari throwaway Prototyping. Tujuan utama ketika menggunakan Evolutionary Prototyping adalah untuk membangun prototipe yang sangat kuat dengan cara yang terstruktur dan terus-menerus memperbaikinya. "Alasan untuk ini adalah bahwa evolusi prototipe, ketika dibangun, bentuk jantung dari sistem baru, dan perbaikan dan persyaratan lebih lanjut akan dibangun.
Ketika mengembangkan sistem dengan menggunakan Evolutionary Prototyping, sistem ini terus-menerus disempurnakan dan dibangun kembali.
" evolusi prototipe mengakui bahwa kita tidak memahami semua persyaratan dan membangun hanya mereka yang dipahami dengan baik." Teknik ini memungkinkan tim pengembangan untuk menambahkan fitur, atau membuat perubahan yang tidak dapat dipahami selama persyaratan dan tahap perancangan.
Untuk sistem yang akan berguna, itu harus berkembang melalui penggunaan dimaksudkan dalam lingkungan operasional. Sebuah produk tidak pernah "dilakukan;" itu selalu jatuh tempo sebagai perubahan lingkungan penggunaan? Kita sering mencoba untuk mendefinisikan sebuah sistem dengan menggunakan kita yang paling akrab --- kerangka acuan di mana kita sekarang. Kita membuat asumsi tentang cara bisnis akan dilakukan dan berbasis teknologi bisnis yang akan dilaksanakan. Sebuah rencana dijalankan untuk mengembangkan kemampuan, dan, cepat atau lambat, sesuatu yang mirip dengan sistem membayangkan dikirimkan.
Prototip evolusi memiliki keuntungan lebih throwaway Prototip dalam bahwa mereka adalah sistem fungsional. Walaupun mereka mungkin tidak memiliki semua fitur yang pengguna telah direncanakan, mereka dapat digunakan pada basis sementara sampai sistem terakhir dikirim.
"Sudah lazim dalam lingkungan prototipe bagi pengguna untuk menempatkan prototipe awal untuk penggunaan praktis sambil menunggu versi yang lebih maju? Pengguna dapat memutuskan bahwa sebuah 'cacat' sistem yang lebih baik daripada tidak ada sistem sama sekali."
Dalam Evolutionary Prototyping, pengembang dapat memfokuskan diri untuk mengembangkan bagian-bagian dari sistem yang mereka mengerti daripada bekerja pada pengembangan sistem secara keseluruhan.
Untuk meminimalkan risiko, pengembang tidak mengimplementasikan fitur kurang dipahami. Sistem parsial dikirim ke situs pelanggan. Sebagai pengguna bekerja dengan sistem, mereka mendeteksi kesempatan untuk fitur-fitur baru dan memberikan permintaan fitur ini untuk pengembang. Pengembang kemudian mengambil permintaan tambahan ini bersama-sama dengan mereka sendiri dan menggunakan konfigurasi suara-praktik manajemen untuk mengubah perangkat lunak-persyaratan spesifikasi, update desain, recode dan tes ulang.
Referensi :
3. SPIRAL
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.
Model spiral dibagi menjadi enam wilayah tugas yaitu:
1. Customer communication: Aktivitas yang
dibutuhkan untuk membangun komunikasi yang efektif antara developer dengan user
/ customer terutama mengenai kebutuhan dari customer.
2. Planning: Aktivitas perencanaan ini dibutuhkan
untuk menentukan sumberdaya, perkiraan waktu pengerjaan, dan informasi lainnya
yang dibutuhkan untuk pengembangan software.
3. 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.
4. Engineering: Aktivitas yang dibutuhkan untuk
membangun 1 atau lebih representasi dari aplikasi secara teknikal.
5. 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.
6. 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
ü 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
Kekurangan model Spiral
ü Memerlukan tenaga ahli untuk memperkirakan
resiko, dan harus mengandalkannya supaya sukses
ü Model spiral ini merupakan model yang masih
baru sehingga belum terbukti apakah model ini efisien atau tidak.
Referensi :
http://ayip7shortcutsharing.blogspot.co.id/2013/06/pengertian-model-proses-spiral.html
https://hansiaditya.wordpress.com/2007/09/25/spiral-model/
http://gunawan13.blog.upi.edu/2015/02/13/rekayasa-perangkat-lunak-pengertian-dan-model-proses-pengembangan/
4. Model
Rapid Application Development (RAD)
Pengertian
Rapid
application development (RAD) atau rapid prototyping adalah model proses
pembangunan perangkat lunak yang tergolong dalam teknik incremental
(bertingkat). RAD menekankan pada siklus pembangunan pendek, singkat, dan
cepat. Waktu yang singkat adalah batasan yang penting untuk model ini. Rapid
application development menggunakan metode iteratif (berulang) dalam
mengembangkan sistem dimana working model (model bekerja) sistem
dikonstruksikan di awal tahap pengembangan dengan tujuan menetapkan kebutuhan
(requirement) user dan selanjutnya disingkirkan. Working model digunakan
kadang-kadang saja sebagai basis desain dan implementasi sistem final.
Sejarah
Rapid
Application Development ( RAD ) adalah istilah awalnya digunakan untuk
menggambarkan proses pengembangan perangkat lunak pertama kali dikembangkan dan
berhasil digunakan selama pertengahan 1970-an oleh Sistem Pusat Pengembangan
New York Telephone Co di bawah arahan Dan Gielan. Setelah serangkaian implementasi
sangat berhasil dari proses ini, Gielan kuliah secara ekstensif di berbagai
forum pada metodologi , praktek, dan manfaat dari proses ini.
RAD
melibatkan pengembangan dan pembangunan prototipe iteratif . Pada tahun 1990, dalam
buku RAD, Rapid Application Development, James Martin didokumentasikan
penafsirannya tentang metodologi. Baru-baru ini, istilah dan singkatan yang
telah datang untuk digunakan dalam lebih luas, pengertian umum yang mencakup
berbagai metode yang bertujuan untuk mempercepat pengembangan aplikasi, seperti
penggunaan kerangka perangkat lunak dari berbagai jenis, seperti kerangka kerja
aplikasi web.
Pengembangan
aplikasi yang cepat merupakan respon terhadap proses yang dikembangkan pada
1970-an dan 1980-an, seperti Structured Sistem Metode Analisis dan Desain dan
model Waterfall lainnya. Satu masalah dengan metodologi sebelumnya adalah bahwa
aplikasi begitu lama untuk membangun bahwa persyaratan telah berubah sebelum
sistem itu selesai, sehingga sistem tidak memadai atau bahkan tidak dapat
digunakan. Masalah lain adalah asumsi bahwa persyaratan metodis tahap analisis
saja akan mengidentifikasi semua persyaratan penting. Membuktikan fakta bahwa
ini adalah jarang terjadi, bahkan untuk proyek-proyek dengan profesional yang
sangat berpengalaman di semua tingkatan.
Dimulai
dengan ide-ide dari Brian Gallagher, Alex Balchin, Barry Boehm dan Scott
Shultz, James Martin mengembangkan pendekatan pengembangan aplikasi yang cepat
selama tahun 1980 di IBM dan akhirnya diresmikan itu dengan menerbitkan sebuah
buku pada tahun 1991, Rapid Application Development.
Fase dan Tahapan Pengembangan Aplikasi
Menurut
Kendall (2010), terdapat tiga fase dalam RAD yang melibatkan penganalisis dan
pengguna dalam tahap penilaian, perancangan, dan penerapan. Adapun ketiga fase
tersebut adalah requirements planning (perencanaan syarat-syarat), RAD design
workshop (workshop desain RAD), dan implementation (implementasi).
Sesuai dengan metodologi RAD menurut Kendall (2010), berikut ini adalah
tahap-tahap pengembangan aplikasi dari tiap-tiap fase pengembangan aplikasi :
1) Requirements Planning (Perencanaan
Syarat-Syarat)
Dalam fase ini, pengguna dan penganalisis bertemu untuk
mengidentifikasikan tujuan-tujuan aplikasi atau sistem serta untuk megidentifikasikan
syarat-syarat informasi yang ditimbulkan dari tujuan-tujuan tersebut. Orientasi
dalam fase ini adalah menyelesaikan masalah-masalah perusahaan. Meskipun
teknologi informasi dan sistem bisa mengarahkan sebagian dari sistem yang
diajukan, fokusnya akan selalu tetap pada upaya pencapaian tujuan-tujuan
perusahaan (Kendall, 2010).
2) RAD Design Workshop (Workshop Desain
RAD)
Fase ini adalah fase untuk merancang dan memperbaiki yang
bisa digambarkan sebagai workshop. Penganalisis dan dan pemrogram dapat
bekerja membangun dan menunjukkan representasi visual desain dan pola kerja
kepada pengguna. Workshop desain ini dapat dilakukan selama beberapa
hari tergantung dari ukuran aplikasi yang akan dikembangkan. Selama workshop desain
RAD, pengguna merespon prototipe yang ada dan penganalisis memperbaiki
modul-modul yang dirancang berdasarkan respon pengguna. Apabila sorang
pengembangnya merupakan pengembang atau pengguna yang berpengalaman, Kendall
menilai bahwa usaha kreatif ini dapat mendorong pengembangan sampai pada
tingkat terakselerasi (Kendall, 2010).
3) Implementation (Implementasi)
Pada fase implementasi ini, penganalisis bekerja dengan para
pengguna secara intens selama workshop dan merancang aspek-aspek
bisnis dan nonteknis perusahaan. Segera setelah aspek-aspek ini disetujui dan
sistem-sistem dibangun dan disaring, sistem-sistem baru atau bagian dari sistem
diujicoba dan kemudian diperkenalkan kepada organisasi (Kendall, 2010).
TAHAPAN-TAHAPAN DALAM RAD
RAD di gunukan pada aplikasi system konstruksi, maka
menekankan fase-fase. Ada Tiga Fase dalam RAD yaitu :
REQUIREMENT PLANING, dalam tahap ini di ketahui apa saja
yang menjadi kebutuhan system yaitu dengan mengidentifikasikan kebutuhan
informasi dan masalah yang di hadapi untuk menentukan tujuan, batasan –batasan
system, kendala dan juga alternative pemecahan masalah analisis di gunakan
untuk mengetahui perilaku system dan juga untuk mengetahui aktifitas apa saja
yang ada dalam system tersebut.
DESIGN WORKSHOP, yaitu mengidentifikasi solusi alternative
dan memilih solusi yang terbaik. Kemudian membuat design proses bisnis dan
design pemrograman untuk data-data yang telah di dapatkan dan di modelkan dalam
arsitektur system informasi.
IMPLENTATION, setelah design workshop di lakukan,
selanjutnya system di implikasikan (coding) ke dalam bentuk yang di mengerti
oleh mesin yang di wujudkan dalam bentuk program atauunit program.
KEUNTUNGAN RAD
Beberapa keuntungan dalam menggunakan metode RAD adalah
sebagai berikut:
– Membeli sistem yang baru memungkinkan untuk lebih menghemat biaya ketimbang mengembangkan sendiri.
– Proses pengiriman menjadi lebih mudah, hal ini dikarenakan proses pembuatan lebih banyak menggunakan potongan-potongan script.
– Mudah untuk diamati karena menggunakan model prototype, sehingga user lebih mengerti akan sistem yang dikembangkan.
– Lebih fleksibel karena pengembang dapat melakukan proses desain ulang pada saat yang bersamaan.
– Bisa mengurangi penulisan kode yang kompleks karena menggunakan wizard.
– Keterlibatan user semakin meningkat karena merupakan bagian dari tim secara keseluruhan.
– Mampu meminimalkan kesalahan-kesalahan dengan menggunakan alat-alat bantuan (CASE tools).
– Mempercepat waktu pengembangan sistem secara keseluruhan karena cenderung mengabaikan kualitas.
– Tampilan yang lebih standar dan nyaman dengan bantuan software-software pendukung.
– Membeli sistem yang baru memungkinkan untuk lebih menghemat biaya ketimbang mengembangkan sendiri.
– Proses pengiriman menjadi lebih mudah, hal ini dikarenakan proses pembuatan lebih banyak menggunakan potongan-potongan script.
– Mudah untuk diamati karena menggunakan model prototype, sehingga user lebih mengerti akan sistem yang dikembangkan.
– Lebih fleksibel karena pengembang dapat melakukan proses desain ulang pada saat yang bersamaan.
– Bisa mengurangi penulisan kode yang kompleks karena menggunakan wizard.
– Keterlibatan user semakin meningkat karena merupakan bagian dari tim secara keseluruhan.
– Mampu meminimalkan kesalahan-kesalahan dengan menggunakan alat-alat bantuan (CASE tools).
– Mempercepat waktu pengembangan sistem secara keseluruhan karena cenderung mengabaikan kualitas.
– Tampilan yang lebih standar dan nyaman dengan bantuan software-software pendukung.
KERUGIAN RAD
Beberapa kerugian dalam menggunakan metode RAD adalah
sebagai berikut :
– Dengan melakukan pembelian belum tentu bisa menghemat biaya dibandingkan dengan mengembangkan sendiri.
– Membutuhkan biaya tersendiri untuk membeli peralatan-peralatan penunjang seperti misalnya software dan hardware.
– Kesulitan melakukan pengukuran mengenai kemajuan proses.
– Kurang efisien karena apabila melakukan pengkodean dengan menggunakan tangan bisa lebih efisien.
– Ketelitian menjadi berkurang karena tidak menggunakan metode yang formal dalam melakukan pengkodean.
– Lebih banyak terjadi kesalahan apabila hanya mengutamakan kecepatan dibandingkan dengan biaya dan kualitas.
– Fasilitas-fasilitas banyak yang dikurangi karena terbatasnya waktu yang tersedia.
– Sistem sulit diaplikasikan di tempat yang lain.
– Fasilitas yang tidak perlu terkadang harus disertakan, karena menggunakan komponen yang sudah jadi, sehingga hal ini membuat biaya semakin meningkat.
– Dengan melakukan pembelian belum tentu bisa menghemat biaya dibandingkan dengan mengembangkan sendiri.
– Membutuhkan biaya tersendiri untuk membeli peralatan-peralatan penunjang seperti misalnya software dan hardware.
– Kesulitan melakukan pengukuran mengenai kemajuan proses.
– Kurang efisien karena apabila melakukan pengkodean dengan menggunakan tangan bisa lebih efisien.
– Ketelitian menjadi berkurang karena tidak menggunakan metode yang formal dalam melakukan pengkodean.
– Lebih banyak terjadi kesalahan apabila hanya mengutamakan kecepatan dibandingkan dengan biaya dan kualitas.
– Fasilitas-fasilitas banyak yang dikurangi karena terbatasnya waktu yang tersedia.
– Sistem sulit diaplikasikan di tempat yang lain.
– Fasilitas yang tidak perlu terkadang harus disertakan, karena menggunakan komponen yang sudah jadi, sehingga hal ini membuat biaya semakin meningkat.
5. Rekayasa
perangkat lunak RUP (Rational Unified Process)
Apa sebetulnya RUP itu? Berdasarkan buku Agility and
Discipline Made Easy: Practices from OpenUP and RUP, RUP merupakan framework proses
yang banyak diadopsi dan digunakan oleh puluhan ribu proyek mulai dari tim
dengan dua anggota hingga tim dengan ratusan anggota, pada berbagai industri di
seluruh dunia. RUP bercabang, salah atunya adalah EPF (Eclipse Process
Framework) dengan sebuah volume tambahan konten proses yang besar, memungkinkan
tim pengembangan untuk mengukur proses mereka untuk melakukan hal berikut:
§ Melakukan distribusi atau pengembangan skala
besar yang membutuhkan lebih banyak serangkaian aturan, seperti persyaratan traceability,
model analisis, model-driven architecture (MDA), atau pengujian beban dan
kinerja secara komprehensif.
§ Mengembangkan sistem yang menggunakan alat IBM,
memberikan panduan khusus tentang teknologi yang relevan seperti J2EE dan .NET,
dan menggunakan IBM beserta turunan-turunan atau keluarganya.
§ Mengembangkan sistem yang mengikuti standar
industri seperti ISO 9001, SEI CMMI, atau SOX.
§ Mengatur proses berorientasi projek menjadi
proses enterprise, seperti program dan portofolio manajemen; rekayasa
sistem; penggunaan ulang enterprise; pemodelan bisnis dan simulasi; atau SOA
berskala enterprise.
Dalam buku Software Engineering for Small Project disebutkan
bahwa salah satu keuntungan nyata penggunaan RUP adalah fleksibel.
Pada bukunya Gary menyebutkan pendekatan RUP adalah dengan
memikirkan artefak (requirements, tests, code, dan seterusnya) yang dibutuhkan
oleh projekt, lalu mempertimbangkan apa aktivitas untuk melakukan pembuatan
artefak tersebut. Sebuah kunci utama yang perlu dingat adalah, bahwa tujuannya
adalah untuk membangun software, bukan membuat artefak.
Berikut adalah artefak dasar yang kita percaya setiap tim
membutuhkannya:
§ Sebuah Visi. Hal ini membantu tim proyek
memahami untuk membangun apa dan kemudian membantu mereka tahu kapan mereka
selesai membangun itu.
§ Sebuah Daftar Risiko. Apa resiko yang
sebenarnya Anda hadapi dan bagaimana Anda akan menanggulanginya? Ketika Anda
berpikir tentang risiko, pertimbangkan elemen ini proyek Anda: orang, proses,
dan alat-alat.
§ Masalah Pengembangan. Ini menjelaskan bagaimana
Anda akan beradaptasi RUP dengan kebutuhan Anda. Salah satu bagian penting dari
kasus pembangunan adalah bahwa ia menjelaskan tanggung jawab masing-masing
peran yang berbeda pada proyek.
§ Use Case. Ini mendefinisikan serangkaian
interaksi antara sistem dan aktor (biasanya seorang pengguna) yang menghasilkan
hasil yang dapat diamati dari nilai.
§ Seperangkat Tes yang Baik. Jika Anda
menggunakan RUP, maka Anda dapat mulai menghasilkan tes segera setelah Anda menyelesaikan use
case pertama Anda.
§ Sebuah Arsitektur. Ini mungkin sangat informal.
Beberapa kelompok merilis versi pertama mereka tanpa arsitektur formal, maka
(dengan asumsi sukses) ketika mereka sedang merencanakan versi kedua, mereka
mulai dengan mendokumentasikan arsitektur sejauh ini dan bagaimana
mengembangkannya.
§ Sebuah Rencana Proyek. Perencanaan ini harus
menguraikan iterasi dan jadwal. Desainlah iterasi agar Anda mengatasi item
risiko utama selama fase Elaborasi (salah satu dari empat fase RUP). Ini akan
membantu Anda mengurangi kemungkinan kejutan teknis atau pekerjaan ulang yang
tak terduga di akhir proyek
§ Sebuah Glosarium. Glosarium harus berisi
definisi untuk menjaga bahasa tim Anda konsisten, proyek yang luas. Jika tim,
termasuk pelanggan Anda dan semua pemangku kepentingan, yang akrab dengan
domain dan semua hal yang mungkin Anda gunakan saat bekerja pada proyek, Anda
mungkin tidak perlu menulis glosarium.
Berbeda halnya pada buku The Rational Unified Process:
An Introduction (2nd Edition), Rational Unified Process adalah
proses rekayasa perangkat lunak. RUP menyediakan pendekatan disiplin untuk
menetapkan tugas dan tanggung jawab dalam pengembangan organisasi. Tujuannya
adalah untuk memastikan produksi perangkat lunak berkualitas tinggi yang
memenuhi kebutuhan pengguna akhir pada jadwal dan anggaran yang dapat
diprediksi.
Rational Unified Process adalah sebuah proses poduk. Hal ini
dikembangkan dan dikelola oleh Rational Software dan terintegrasi dengan
seperangkat alat pengembangan perangkat lunak. Perangkat ini tersedia
pada CD-ROM Software Rational atau melalui internet. Rational Unified Process
juga sebuah framework proses yang dapat disesuaikan dan dikembangkan
sesuai dengan kebutuhan adopsi organisasi.
RUP Online
Phase RUP
RUP menguraikan empat fase (Inception, Elaboration, Construction dan Transition)
yang mana sebuah projek melaluinya. Fase Inception adalah tentang
menciptakan visi, mengembangkan kasus bisnis, dan prototipe software atau
solusi parsial agar orang mengusahakannya mendapat dukungan dan pendanaan. Fase Elaboration berakhir
dengan eksekusi arsitektur di mana keputusan arsitektur utama telah dibuat dan
risiko telah dikurangi. Eksekusi arsitekur software menunjukkan sebuah
implementasi dari kunci keputusan arsitektur. Fase Constrction adalah
tentang mengisi fungsi yang diidentifikasi dalam arsitektur, dan fase Transition berfokus
pada penyampaian software untuk para penggunanya.
Tahapan dibagi menjadi iterasi. Iterasi adalah “time-boxed”
dan memiliki tujuan tertentu. Iterasi disimpan sesingkat mungkin, tapi cukup
lama bagi Anda untuk menerapkan kelengkapan use case atau
skenario use case yang memberikan nilai nyata bagi pengguna. Pada
akhir setiap iterasi, Anda memegang penilaian di mana Anda menyesuaikan rencana
untuk iterasi mendatang, berdasarkan hasil dari iterasi saat ini. Selama
penilaian, tim Anda juga mencerminkan tentang manfaat proses dan penyesuaian
seperlunya. RUP adalah tentang menciptakan visi dari apa yang Anda inginkan,
menciptakan kerangka kerja untuk mencapai visi tersebut, dan menilai di poin
yang diberikan apakah Anda mencapai sesuai dengan yang direncanakan.
Referensi :
Extreme Programming (berikutnya akan disingkat sebagai XP)
adalah sebuah pendekatan atau model pengembangan perangkat lunak yang mencoba
menyederhanakan berbagai tahapan dalam proses pengembangan tersebut sehingga
menjadi lebih adaptif dan fleksibel. XP bukan hanya berfokus pada coding tetapi
meliputi seluruh area pengembangan perangkat lunak. XP mengambil pendekatan
‘ekstrim’ dalam iterative development.
Sejarah XP
Proyek pengembangan perangkat lunak yang dianggap sebagai
yang pertama kali menerapkan extreme programming adalah C3 (Chrysler
Comprehensive Compensation) Project dari Chrysler. Proyek ini adalah
proyek penggajian 10.000 karyawan Chrysler, terdiri dari kira-kira 2000 classdan
30.000 method. Proyek yang dimulai pertengahan dekade 90-an ini terancam
gagal karena rumitnya sistem yang dibangun dan kegagalan pada saat testing.
Chrysler kemudian menyewa Kent Beck, seorang pakar software engineering yang
di kemudian hari dikenal sebagai pencetus awal dari XP, untuk menyelamatkan
proyek tersebut. Beck bersama rekannya Ron Jeffries dengan kewenangan yang
diberikan oleh Chrysler melakukan berbagai perubahan di C3 Project untuk
membuatnya lebih efisien, adaptif, dan fleksibel. Hal yang paling penting bagi
mereka adalah harus mampu memenuhi permintaan utama dari Chrysler, untuk
melakukan launchingperangkat lunak tersebut dalam waktu tidak lebih dari
dua tahun sejak saat Beck dikontrak.
Beck dan Jeffries pada akhirnya berhasil menyelesaikan
target Chrysler dengan menerapkan berbagai metode dalam proses pengembangan
perangkat lunak tersebut. Kumpulan metode inilah yang kemudian dikenal sebagai
model atau pendekatan XP dalam pengembangan perangkat lunak. Begitu
sederhananya metode-metode tersebut sehingga bagi orang yang belum menerapkan,
XP terlihat sebagai kumpulan ide lama yang terlalu sederhana dan tidak akan
memberikan efek apapun pada sebuah proyek pengembangan perangkat lunak.
Kent Beck sendiri mengakui dan menegaskan bahwa XP tidak
selalu cocok untuk setiap proyek pengembangan perangkat lunak. Kelebihan XP
adalah sesuai untuk digunakan pada proyek yang memiliki dynamic
requirements. Proyek semacam ini memerlukan adaptasi cepat dalam mengatasi
perubahan-perubahan yang terjadi selama proses pengembangan perangkat lunak. XP
juga cocok untuk proyek dengan jumlah anggota tim tidak terlalu banyak (sekitar
10-20 orang) dan berada pada lokasi yang sama.
Nilai-nilai Dasar XP
Berikut adalah nilai-nilai mendasar yang menjadi roh dari XP pada setiap
tahapan proses pengembangan perangkat lunak:
1. Communication
XP mengfokuskan pada hubungan komunikasi yang baik antar
anggota tim. Para anggota tim harus membangun saling pengertian, mereka juga
wajib saling berbagi pengetahuan dan keterampilan dalam mengembangkan perangkat
lunak. Ego dari para programer yang biasaanya cukup tinggi harus ditekan dan
mereka harus membuka diri untuk bekerjasama dengan programer lain dalam
menuliskan kode program.
2. Courage
Para anggota tim dan penanggungjawab pengembangan perangkat
lunak harus selalu memiliki keyakinan dan integritas dalam melakukan tugasnya.
Integritas ini harus selalu dijaga bahkan dalam kondisi adanya tekanan dari
situasi sekitar (misalnya oleh klien atau pemilik perusahaan). Untuk dapat
melakukan sesuatu dengan penuh integritas terlebih dahulu para anggota tim
harus terlebih dahulu memiliki rasa saling percaya. Rasa saling percaya inilah
yang coba dibangun dan ditanamkan oleh XP pada berbagai aspeknya.
3. Simplicity
Lakukan semua dengan sederhana. Hal tersebut adalah salah
satu nilai dasar dari XP. Gunakan method yang pendek dan simpel,
jangan terlalu rumit dalam membuat desain, hilangkan fitur yang tidak ada
gunanya, dan berbagai proses penyederhanaan lain akan selalu menjadi nilai
utama dari setiap aspek XP.
4. Feedback
Berikan selalu feedback kepada sesama anggota tim
maupun pihak-pihak lain yang terlibat dalam pengembangan perangkat lunak.
Utarakan selalu pikiran anda dan diskusikan kesalahan-kesalahan yang muncul
selama proses pengembangan. Dengarkan selalu pendapat rekan yang lain, dengan
adanya feedback inilah seringkali kita menyadari bagian mana yang
salah atau bisa ditingkatkan lagi dari perangkat lunak yang dikembangkan.
5. Quality Work
Semua nilai di atas berujung pada sebuah kondisi di mana
kita melakukan pekerjaan dengan berkualitas. Dengan proses yang berkualitas
maka implikasinya akan muncul pula perangkat lunak yang berkualitas sebagai
hasil akhirnya.
Aspek Dasar XP
Aspek dasar XP terdiri dari berbagai teknik atau metode yang
diterapkan Beck dan Jeffries pada C3 Project. Teknik-teknik tersebut dapat
diamati pada gambar berikut ini:
1. The Planning Game
Pendekatan XP dalam perencanaan sangat mirip dengan metode
yang diterapkan pada RAD (Rapid Application Development). Proses pendek
dan cepat, mengutamakan aspek teknik, memisahkan unsur bisnis dengan unsur
teknis dan pertemuan intensif antara klien dengan developer. Pada XP
proses ini menggunakan terminologi “game” karena Beck menyarankan untuk
menggunakan teknik score card dalam menentukan requirements.
Semakin sulit aspek teknis yang dibutuhkan semakin tinggi pula skor pada kartu
rencana tersebut.
2. Small Releases
Setiap release dilakukan dalam lingkup sekecil
mungkin pada XP. Setiap developermenyelesaikan sebuah unit atau bagian
dari perangkat lunak maka hasil tersebut harus segera dipresentasikan dan
didiskusikan dengan klien. Jika memungkinkan untuk menerapkan unit tersebut
pada perusahaan, hal itu juga dapat dilakukan sekaligus sebagai tes awal dari
penerapan keseluruhan sistem. Kendati demikian hal ini tidak selalu perlu
dilakukan karena harus dihitung terlebih dahulu sumberdaya yang dibutuhkan.
Apakah lebih menguntungkan langsung melakukan tes terhadap unit tersebut atau
melakukan tes setelah unit tersebut terintegrasi secara sempurna pada sistem.
3. Metaphor
Metaphor pada dasarnya sama dengan arsitektur perangkat
lunak. Keduanya menggambarkan visi yang luas terhadap tujuan dari pengembangan
perangkat lunak. Beck sendiri seperti para penandatangan Agile Manifesto
lainnya bercita-cita menyederhanakan proses pengembangan perangkat lunak yang
saat ini sudah dianggap terlalu rumit. Arsitektur yang saat ini banyak berisi
diagram dan kode semacam UML dianggap terlalu rumit untuk dimengerti, terutama
oleh klien. Metaphor, walaupun mirip dengan arsitektur lebih bersifat
naratif dan deskriptif. Dengan demikian diharapkan komunikasi antara klien
dengan developer akan berlangsung lebih baik dan lancar dengan
penggunaan metaphor.
4. Simple Design
Sebagai salah seorang penandatangan Agile Manifesto, Beck
adalah seorang yang tidak menyukai desain yang rumit dalam sebuah pengembangan
perangkat lunak. Tidak heran jika dia memasukkan Simple Design sebagai
salah satu unsur XP. Pada XP desain dibuat dalam lingkup kecil dan sederhana.
Tidak perlu melakukan antisipasi terhadap berbagai perubahan di kemudian hari.
Dengan desain yang simpel apabila terjadi perubahan maka membuat desain baru
untuk mengatasi perubahan tersebut dapat dengan mudah dilakukan dan resiko
kegagalan desain dapat diperkecil.
5. Refactoring
Refactoring adalah salah satu aspek paling khas dari
XP. Refactoring seperti didefinisikan oleh Martin Fowler adalah
”Melakukan perubahan pada kode program dari perangkat lunak dengan tujuan
meningkatkan kualitas dari struktur program tersebut tanpa mengubah cara
program tersebut bekerja”. Refactoring sendiri sangat sesuai untuk
menjadi bagian XP karena Refactoringmengusung konsep penyederhanaan dari
proses desain maupun struktur baris kode program. Dengan Refactoring tim
pengembang dapat melakukan berbagai usaha untuk meningkatkan kualitas program
tanpa kembali mengulang-ulang proses desain. Fowler adalah salah satu kolega
dekat dari Kent Beck karena itu tidak mengherankan bahwa cara berpikir mereka
terhadap proses pengembangan perangkat lunak sangat mirip satu dengan lainnya.
6. Testing
XP menganut paradigma berbeda dalam hal tes dengan model
pengembangan perangkat lunak lainnya. Jika pada pengembangan perangkat lunak
lainnya tes baru dikembangkan setelah perangkat lunak selesai menjalani proses coding maka
pada XP tim pengembang harus membuat terlebih dahulu tes yang hendak dijalani
oleh perangkat lunak. Berbagai model tes yang mengantisipasi penerapan
perangkat lunak pada sistem dikembangkan terlebih dahulu. Saat proses coding selesai
dilakukan maka perangkat lunak diuji dengan model tes yang telah dibuat
tersebut. Pengetesan akan jauh lebih baik apabila dilakukan pada setiap unit
perangkat lunak dalam lingkup sekecil mungkin daripada menunggu sampai seluruh
perangkat lunak selesai dibuat. Dengan memahami tahap ini kita dapat melihat
bahwa siklus pada XP adalah requirement analysis à test à code à design.
Sekilas terlihat hal ini tidak mungkin dilakukan tetapi pada kenyataannya memang
gambaran inilah yang paling dapat menjelaskan tentang XP.
7. Pair Programming
Pair programming adalah melakukan proses menulis
program dengan berpasangan. Dua orang programer saling bekerjasama di komputer
yang sama untuk menyelesaikan sebuah unit. Dengan melakukan ini maka keduanya
selalu dapat berdiskusi dan saling melakukan koreksi apabila ada kesalahan
dalam penulisan program. Aspek ini mungkin akan sulit dijalankan oleh para
programer yang memiliki ego tinggi dan sering tidak nyaman untuk berbagi
komputer bersama rekannnya.
8. Collective Ownership
Tidak ada satupun baris kode program yang hanya dipahami
oleh satu orang programer. XP menuntut para programer untuk berbagi pengetahuan
untuk tiap baris program bahkan beserta hak untuk mengubahnya. Dengan pemahaman
yang sama terhadap keseluruhan program, ketergantungan pada programer tertentu
ataupun berbagai hambatan akibat perbedaan gaya menulis program dapat
diperkecil. Pada level yang lebih tinggi bahkan dimungkinkan para programer
dapat bertukar unit yang dibangunnya.
9. Coding Standards
Pair programming dan collective ownership hanya
akan dapat berjalan dengan baik apabila para programer memiliki pemahaman yang
sama terhadap penulisan kode program. Dengan adanya coding standards yang
telah disepakati terlebih dahulu maka pemahaman terhadap program akan menjadi
mudah untuk semua programer dalam tim. Hal ini dapat diterapkan sebagai contoh
pada penamaan variabel dan penggunaan tipe data yang sama untuk tiap elemen
semua record atau array pada program.
10. Continous Integration
Melakukan build setiap hari kerja menjadi sebuah
model yang disukai oleh berbagai tim pengembang perangkat lunak. Hal ini
terutama didorong oleh keberhasilan penerapan sistem ini oleh Microsoft dan
telah sering dipublikasikan. Dengan melakukan build sesering mungkin
berbagai kesalahan pada program dapat dideteksi dan diperbaiki secepat mungkin.
Apabila banyak tim pengembang perangkat lunak meyakini bahwa build sekali
sehari adalah minimum maka pada XP hal tersebut adalah maksimum. Pada XP tim
disarankan untuk melakukan buildsesering mungkin misalnya setiap 4 jam
atau bahkan lebih cepat lagi.
11. 40-hours Week
Beck berpendapat bekerja 8 jam sehari dan 5 hari seminggu
adalah maksimal untuk tiap programer. Lebih dari itu programer akan cenderung
membuat berbagai error pada baris-baris kode programnya karena
kelelahan.
12. On-Site Customer
Sebuah pendekatan klasik, di mana XP menganjurkan bahwa ada
anggota dari klien yang terlibat pada proses pengembangan perangkat lunak. Yang
lebih penting lagi ia harus ada di tempat pemrogaman dan turut serta dalam
proses build dan test yang dilakukan. Apabila ada kesalahan dalam pengembangan
diharapkan klien dapat segera memberikan masukan untuk koreksinya.
Kelebihan dan Kekurangan XP
Kelebihan :
Meningkatkan kepuasan kepada klien
Pembangunan system dibuat lebih cepat
Menjalin komunikasi yang baik dengan client.
Meningkatkan komunikasi dan sifat saling menghargai antar
developer.
Kekurangan :
User story kemungkinan besar tidak lengkap
sehingga 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).
XP tidak memiliki dokumentasi formal yang dibuat selama
pengembangan. Satu-satunya dokumentasi adalah dokumentasi awal yang dilakukan
oleh user.
Referensi :
http://ganiamanda.blog.widyatama.ac.id/2016/02/13/extreme-programming-xp-model/
Komentar
Posting Komentar