aep_pea blog
blog pribadi aep apipudin sebagai tugas kuliah, dan juga sharing pengetahuan umum
Use case dengan study kasus :
- Sistem Informasi Koperasi
- Sistem Informasi Akademik
- Sistem Informasi POS (Point Of Sales)
USE CASE adalah suatu model yang dangat fungsional dalam sebuah sistem yang
menggunakan actor dan use case. Sedangkan pengertian dari use case sendiri
adalah layanan atau fungsi-fungsi yang tersedia pada sistem untuk penggunannya.
Use case
diagram menggambarkan efek fungsionalitas yang telah diharapkan oleh
sistem. Use case diagram dapat sangat
membantu bila kita sedang menyusun requitment sebuah sistem, mengkomunikasikan
sebuah rancangan aplikasi dengan konsumen, serta merancang test case untuk
semua feature yang ada pada sistem. aturannya, sebuah use case dapat di masukan
lebih dari use case lain, sehingga duplikasi fungsionalitas dapat dihindaro
dengan cara menarik keluar fungsional yang common.
1. Sistem Informasi Koperasi
1.
waterfall
Permodelan dalam suatu perangkat lunak merupakan suatu hal yang
dilakukan di tahapan awal. Di dalam suatu rekayasa perangkat lunak, sebenarnya
masih memungkinkan tanpa melakukan permodelan. Hal ini tidak dapat lagi
dilakukan dalam suatu industri perangkat lunak. Permodelan dalam perangkat
lunak merupakan suatu yang harus dikerjakan di bagian awal rekayasa, dan
permodelan ini akan mempengaruhi pekerjaan-pekerjaan dalam rekayasa perangkat
lunak tersebut. Model proses perangkat lunak masih menjadi obyek penelitian,
tapi sekarang ada banyak model umum atau paradigma yang berbeda dari
pengembangan perangkat lunak, antara lain: Pengembangan waterfall Pengembangan
secara evolusioner Transformasi formal
Penggabungan sistem dengan menggunakan komponen-komponen yang
dapat digunakan kembali. Waterfall model pertama kali diperkenalkan oleh
Winston Royce tahun 1970. Waterfall Model merupakan model klasik yang sederhana
dengan aliran sistem yang linier. Output dari setiap tahap merupakan input bagi
tahap berikutnya. Model ini telah diperoleh dari proses rekayasa lainnya dan
menawarkan cara pembuatan rekayasa perangkat lunak secara lebih nyata. Model
ini melibatkan tim SQA (Software Quantity Assurance) dengan 5 tahapan, dimana
setiap tahapan selalu dilakukan verifikasi atau testing.
Tahapan model Waterfall meliputi :
Requirment
Dalam tahapan ini jasa, kendala dan tujuandari konsultasi dengan
pengguna sistem. Kemudian semuanya dibuat dalam bentuk yang dapat dimengerti
oleh user dan staf pengembang. Dengan kata lain, dalam tahapan ini dilakukan
analisa kebutuhan, kemudian diverifikasi klien dan tim SQA.
Dalam tahapan ini jasa, kendala dan tujuandari konsultasi dengan
pengguna sistem. Kemudian semuanya dibuat dalam bentuk yang dapat dimengerti
oleh user dan staf pengembang. Dengan kata lain, dalam tahapan ini dilakukan
analisa kebutuhan, kemudian diverifikasi klien dan tim SQA.
Specification
Dokumentasi spesifikasi, kemudian diperiksa oleh tim SQA.
Selanjutnya jika disetujui oleh klien, maka dokumen tersebutmerupakan kontrak
kerjaantaraklien dan pengembang s0ftware. Selanjutnya merencanakan jadwal
pengembangan software. Jika disetujui oleh SQA, tahap desain baru dilakukan.
Dokumentasi spesifikasi, kemudian diperiksa oleh tim SQA.
Selanjutnya jika disetujui oleh klien, maka dokumen tersebutmerupakan kontrak
kerjaantaraklien dan pengembang s0ftware. Selanjutnya merencanakan jadwal
pengembangan software. Jika disetujui oleh SQA, tahap desain baru dilakukan.
Design
Proses design sistem membagi kebutuhan-kebutuhan menjadi sistem
perangkat lunak atau perangkat keras. Proses tersebut menghasilkan sebuah
arsitektur keseluruhan. Desain perangkat lunak termasuk menghasilkan fungsi
sistem perangkatlunak dalam bentuk yang mungkin ditransformasi kedalam satu
atau lebih program yang dapat dijalankan. Tahapan ini telah menentukan alur
software hingga pada tahap algoritma detail. di akhir tahap ini, kembali
diperksa tim SQA.
Proses design sistem membagi kebutuhan-kebutuhan menjadi sistem
perangkat lunak atau perangkat keras. Proses tersebut menghasilkan sebuah
arsitektur keseluruhan. Desain perangkat lunak termasuk menghasilkan fungsi
sistem perangkatlunak dalam bentuk yang mungkin ditransformasi kedalam satu
atau lebih program yang dapat dijalankan. Tahapan ini telah menentukan alur
software hingga pada tahap algoritma detail. di akhir tahap ini, kembali
diperksa tim SQA.
Implementation
Selama tahap ini, desain perangkat lunak disadari sebagai sebuah
program lengkap atau unit program. Desain yang telah disetujui, diubah dalam
bentuk kode-kode program. Tahap ini, kode-kode program yang dihasilkan masih
pada tahap modul-modul. Diakhir Tahap ini, tiap modul di testing tanpa
diintegrasikan.Selama tahap ini, desain perangkat lunak disadari sebagai sebuah
program lengkap atau unit program. Desain yang telah disetujui, diubah dalam
bentuk kode-kode program. Tahap ini, kode-kode program yang dihasilkan masih
pada tahap modul-modul. Diakhir Tahap ini, tiap modul di testing tanpa
diintegrasikan.
Integration
Unit program diintegrasikan dandiuji menjadi sistem yang lengkap
untuk meyakinkan bahwa persyaratan perangkat lunak telah dipenuhi. Setelah uji
coba, sistem disampaikan ke konsumen.
Unit program diintegrasikan dandiuji menjadi sistem yang lengkap
untuk meyakinkan bahwa persyaratan perangkat lunak telah dipenuhi. Setelah uji
coba, sistem disampaikan ke konsumen.
Operation model
& retirement
Normalnya, ini adalah tahap yang terpanjang. Sistem dipasang dan
digunakan. Pemeliharaan termasuk pembetulan kesalahan yang tidak ditemukan pada
langkah sebelumnya. Perbaikan inmplementasi unit sistem dan peningkatan jasa
sistem sebagai kebutuhan baru ditemukan.Setiap tahap dari modelini menggunakan
Document Drivent, yaitu tahap selanjutnya selalu bekerja berdasarkan dokumen
yang telah diberikan sebelumnya. Tahapan pada waterfall model tidak akan
selesai jika tidak disetujui SQA. Modifikasi pada tahap tertentu (tidak sesuai
dengan dokumen sebelumnya), proses harus kembali pada tahap sebelumnya untuk
penyesuaian dan peninjauan ulang.Dalamprakteknya, setiap langkah sering tumpang
tindih dan saling memberi informasi satu sama lain. Proses perangkat lunak
tidak linierdan sederhana, tapi mengandung urutan iterasi dari aktifitas
pengembangan. Selama di langkah terakhir, perangkat lunak telah digunakan.
Kesalahan dan kelalaian dalam menentukan kebutuhan perangkat lunak original
dapat diatasi.Sayangnya model yang banyak mengandung iterasi, sehingga membuat
sulit bagi pihak manajemen untuk memeriksa seluruh rencana dan laporan. Maka
dari itu, setelah sedikit iterasi, biasanya bagian yang telah dikembangkan akan
dihentikan dan dilanjutkan dengan langkah pengembangan selanjutnya.
Masalah-masalah selama resolusi selanjutnya, dibiarkan atau diprogram.
Pemberhentian yang prematur dari persyaratan akan berarti bahwa sistem tidak
akan sesuai dengan keinginan user. Mungkin juga sistem terstruktur secarajelek
yang sebenarnya merupakan masalah deain akan dibiarkan karenaterkalahkan
olehtrik implementasi.Masalah pendekatan waterfall adalah ketidakluwaesan
pembagian proyek ke dalam langkah yang jelas/nyata. Sistem yang disampaikan
kadang-kadang tidak dapatdigunakan sesuai keinginan konsumen. Namun demikian,
model waterfall mencerminkan kepraktisan rekayasa. Konsekuensinya, model proses
perangkat lunak yang berdasarkan pada pendekatan ini, digunakan dalam
pengembangan sistem perangkat lunak dan hardware yang luas.
referensi :
http://kun.ilearning.me/2015/10/19/contoh-waterfall-model/
2. prototyping
Dalam pembuatan software,
dikenal beberapa metode untuk membuat software yang dibutuhkan untuk memenuhi
kebutuhan user yang memerlukan software tersebut.
Sebelum
memasuki lebih mendalam mengenai pembuatan software menggunakan metode
prototype, kita harus terlebih dahulu mengetahui apa yang dimaksud dengan
prototype itu sendiri. Prototype adalah model atau simulasi dari semua aspek
produk sesungguhnya yang akan dikembangkan yang dimana model tersebut harus
representative dari produk akhirnya. Setelah mengetahui arti prototype mungkin
masih menganjal dibenak kita bagaimana sih software itu terbentuk menggunakan
metode prototype? Apakah model prototype lebih bagus digunakan daripada model
lain? Apakah resiko-resiko dari penggunaan model tersebut? Dan mungkin masih
banyak pertanyaan lain yang akan muncul. Oleh sebab itu, pada postingan kali
ini saya sendiri akan menjelaskan lebih lanjut mengenai pembuatan software
dengan menggunakan metode prototype tersebut.Model Prototype
Model Prototype
Menurut saya sendiri prototyping model adalah suatu proses pembuatan software yang yang bersifat berulang dan dengan perencanaan yang cepat yang dimana terdapat umpan balik yang memungkinkan terjadinya perulangan dan perbaikan software sampai dengan software tersebut memenuhi kebutuhan dari si pengguna. Sedangkan dari beberapa referensi yang saya temukan, prototyping model adalah salah satu model sederhana pembuatan software yang dimana mengijinkan pengguna memiliki suatu gambaran awal/dasar tentang program serta melakukan oengujian awal yang didasarkan pada konsep model kerja(working model).
Menurut saya sendiri prototyping model adalah suatu proses pembuatan software yang yang bersifat berulang dan dengan perencanaan yang cepat yang dimana terdapat umpan balik yang memungkinkan terjadinya perulangan dan perbaikan software sampai dengan software tersebut memenuhi kebutuhan dari si pengguna. Sedangkan dari beberapa referensi yang saya temukan, prototyping model adalah salah satu model sederhana pembuatan software yang dimana mengijinkan pengguna memiliki suatu gambaran awal/dasar tentang program serta melakukan oengujian awal yang didasarkan pada konsep model kerja(working model).
Tujuan Prototype
Prototyping model sendiri mempunyai tujuan yaitu mengembangkan model awal software menjadi sebuah sistem yang final.
Prototyping model sendiri mempunyai tujuan yaitu mengembangkan model awal software menjadi sebuah sistem yang final.
A. Proses
Proses-proses dalam
model prototyping menurut saya yaitu:
- Komunikasi terlebih dahulu yang dilakukan antara pelanggan
dengan tim pemgembang perangkat lunak mengenai spesifikasi kebutuhan yang
diinginkan
- Akan dilakukan perencanaan dan pemodelan secara cepat
berupa rancangan cepat(quick design) dan kemudian akan memulai konstruksi
pembuatan prototype
- Prototipe kemudian akan diserahkan kepada para stakeholder
untuk dilakukan evaluasi lebih lanjut sebelum diserahkan kepada para
pembuat software
- Pembuatan software sesuai dengan prototype yang telah
dievaluasi yang kemudian akan diserahkan kepada pelanggan
- Jika belum memenuhi kebutuhan dari pelanggan maka akan
kembali ke proses awal sampai dengan kebutuhan dari pelanggan telah
terpenuhi
Sedangkan
proses-proses dalam model prototyping secara umum adalah sebagai berikut:
1. Pengumpulan kebutuhan
developer dan klien akan bertemu terlebih dahulu dan kemudian menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya
developer dan klien akan bertemu terlebih dahulu dan kemudian menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya
2. Perancangan
Perancangan dilakukan dengan cepat dan rancangan tersebut mewakili semua aspek software yang diketahui, dan rancangan ini menjadi dasar pembuatan prototype
Perancangan dilakukan dengan cepat dan rancangan tersebut mewakili semua aspek software yang diketahui, dan rancangan ini menjadi dasar pembuatan prototype
3. Evaluasi Prototype
Klien akan mengevaluasi prototype yang dibuat dan digunakan untuk memperjelas kebutuhan software.
Klien akan mengevaluasi prototype yang dibuat dan digunakan untuk memperjelas kebutuhan software.
B. Tahapan
Selain itu, untuk
memodelkan sebuah perangkat lunak dibutuhkan beberapa tahapan di dalam proses
pengembangannya. Tahapan inilah yang akan menentukan keberhasilan dari sebuah
softwareitu .Pengembang perangkat lunak harus memperhatikan tahapan dalam
metode prototyping agar software finalnya dapat diterima oleh penggunanya. Dan
tahapan-tahapan dalam prototyping tersebut adalah sebagai berikut :
1. Pengumpulan kebutuhan
Pelanggan dan pengembang bersama-sama mendefinisikan format dan kebutuhan kesseluruhan perangkat lunak, mengidentifikasikan semua kebutuhan, dan garis besar sistem yang akan dibuat.
Pelanggan dan pengembang bersama-sama mendefinisikan format dan kebutuhan kesseluruhan perangkat lunak, mengidentifikasikan semua kebutuhan, dan garis besar sistem yang akan dibuat.
2. Membangun prototyping
Membangun prototyping dengan membuat perancangan sementara yang berpusat pada penyajian kepada pelanggan (misalnya dengan membuat input dan contoh outputnya).
Membangun prototyping dengan membuat perancangan sementara yang berpusat pada penyajian kepada pelanggan (misalnya dengan membuat input dan contoh outputnya).
3. Evaluasi protoptyping
Evaluasi ini dilakukan oleh pelanggan apakah prototyping yang sudah dibangun sudah sesuai dengan keinginan pelanggan. Jika sudah sesuai maka langkah keempat akan diambil. Jika tidak, maka prototyping diperbaiki dengan mengulang langkah 1, 2 , dan 3.
Evaluasi ini dilakukan oleh pelanggan apakah prototyping yang sudah dibangun sudah sesuai dengan keinginan pelanggan. Jika sudah sesuai maka langkah keempat akan diambil. Jika tidak, maka prototyping diperbaiki dengan mengulang langkah 1, 2 , dan 3.
4. Mengkodekan system
Dalam tahap ini prototyping yang sudah disepakati diterjemahkan ke dalam bahasa pemrograman yang sesuai.
Dalam tahap ini prototyping yang sudah disepakati diterjemahkan ke dalam bahasa pemrograman yang sesuai.
5. Menguji system
Setelah sistem sudah menjadi suatu perangkat lunak yang siap pakai, harus dites dahulu sebelum digunakan. Pengujian ini dilakukan dengan White Box, Black Box, Basis Path, pengujian arsitektur dan lain-lain.
Setelah sistem sudah menjadi suatu perangkat lunak yang siap pakai, harus dites dahulu sebelum digunakan. Pengujian ini dilakukan dengan White Box, Black Box, Basis Path, pengujian arsitektur dan lain-lain.
6. Evaluasi Sistem
Pelanggan mengevaluasi apakah sistem yang sudah jadi sudah sesuai dengan yang diharapkan . Jika sudah, maka langkah ketujuh dilakukan, jika belum maka mengulangi langkah 4 dan 5.
Pelanggan mengevaluasi apakah sistem yang sudah jadi sudah sesuai dengan yang diharapkan . Jika sudah, maka langkah ketujuh dilakukan, jika belum maka mengulangi langkah 4 dan 5.
7. Menggunakan system
Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk digunakan
Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk digunakan
C. Keunggulan dan kelemahan
metode prototype
Keunggulan prototyping :
- Komunikasi akan terjalin baik antara pengembang dan
pelanggan.
- Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan
setiap pelanggannya.
- Pelanggan berperan aktif dalam proses pengembangan sistem.
- Lebih menghemat waktu dalam pengembangan sistem.
- Penerapan menjadi lebih mudah karena pemakai mengetahui apa
yang diharapkannya
Kelemahan prototyping :
- Pelanggan kadang tidak melihat atau menyadari bahwa perangkat
lunak yang ada belum mencantumkan kualitas perangkat lunak secara
keseluruhan dan juga belum memikirkan kemampuan pemeliharaan untuk jangka
waktu lama.
- Pengembang biasanya ingin cepat menyelesaikan proyek sehingga
menggunakan algoritma dan bahasa pemrograman yang sederhana untuk membuat
prototyping lebih cepat selesai tanpa memikirkan lebih lanjut bahwa
program tersebut hanya merupakan sebuah kerangka kerja(blueprint) dari
sistem .
- Hubungan pelanggan dengan komputer yang disediakan mungkin
tidak mencerminkan teknik perancangan yang baik dan benar.
Dalam setiap metode
mempunyai kelebihan maupun kekurangan, namun kekurangan tersebut dapat
diminimalisir yaitu dengan mengetahui kunci dari model prototype tersebut. 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.
3.
SPIRAL
Proses model yang lain, yang cukup populer adalah Spiral Model.
Model ini juga cukup baru ditemukan, yaitu pada sekitar tahun 1988 oleh Barry
Boehm pada artikel A Spiral Model of Software Development and Enhancement.
Spiral model adalah salah satu bentuk evolusi yang menggunakan metode iterasi
natural yang dimiliki oleh model prototyping dan digabungkan dengan aspek
sistimatis yang dikembangkan dengan model waterfall. Tahap desain umumnya
digunakan pada model Waterfall, sedangkan tahap prototyping adalah suatu model
dimana software dibuat prototype (incomplete model), “blue-print”-nya, atau
contohnya dan ditunjukkan ke user / customer untuk mendapatkan feedback-nya.
Jika prototype-nya sudah sesuai dengan keinginan user / customer, maka proses
SE dilanjutkan dengan membuat produk sesungguhnya dengan menambah dan
memperbaiki kekurangan dari prototype tadi.Model ini juga mengkombinasikan
top-down design dengan bottom-up design, dimana top-down design menetapkan
sistem global terlebih dahulu, baru diteruskan dengan detail sistemnya,
sedangkan bottom-up design berlaku sebaliknya. Top-down design biasanya
diaplikasikan pada model waterfall dengan sequential-nya, sedangkan bottom-up
design biasanya diaplikasikan pada model prototyping dengan feedback yang
diperoleh. Dari 2 kombinasi tersebut, yaitu kombinasi antara desain dan
prototyping, serta top-down dan bottom-up, yang juga diaplikasikan pada model
waterfall dan prototype, maka spiral model ini dapat dikatakan sebagai model
proses hasil kombinasi dari kedua model tersebut. Oleh karena itu, model ini
biasanya dipakai untuk pembuatan software dengan skala besar dan kompleks.
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.
Berikut adalah gambar dari spiral model secara umum :
Satu lingkaran dari bentuk spiral pada spiral model dibagi
menjadi beberapa daerah yang disebut dengan region. Region tersebut dibagi
sesuai dengan jumlah aktivitas yang dilakukan dalam spiral model. Tentunya
lingkup tugas untuk project yang kecil dan besar berbeda. Untuk project yang
besar, setiap region berisi sejumlah tugas-tugas yang tentunya lebih banyak dan
kompleks daripada untuk project yang kecil. SE berjalan dari inti spiral
berjalan mengitari sirkuit per sirkuit. Sebagai contoh untuk sirkuit pertama
dilakukan untuk pembangunan dari spesifikasi dari software dengan mencari
kebutuhan dari customer. Untuk sirkuit pertama harus menjalani semua aktivitas
yang didefinisikan. Setelah 1 sirkuit terlewati lanjut ke tugas selanjutnya
misalnya membangun prototype. Tugas ini juga harus mengitari 1 sirkuit dan
begitu terus selanjutnya sampai project selesai.
Tidak seperti model-model konvesional dimana setelah SE selesai,
maka model tersebut juga dianggap selesai. Akan tetapi hal ini tidak berlaku
untuk spiral model, dimana model ini dapat digunakan kembali sepanjang umur
dari software tersebut. Pada umumnya, spiral model digunakan untuk beberapa
project seperti Concept Development Project (proyek pengembangan konsep), New
Product Development Project (proyek pengembangan produk baru), Product
Enhancement Project (proyek peningkatan produk), dan Product Maintenance
Project (proyek pemeliharaan proyek). Keempat project tersebut berjalan
berurutan mengitari sirkuit dari spiral. Sebagai contoh setelah suatu konsep
dikembangkan dengan melalui aktivitas2 dari spiral model, maka dilanjutkan dengan
proyek selanjutnya yaitu pengembangan produk baru, peningkatan produk, sampai
pemeliharaan proyek. Semuanya melalui sirkuit2 dari spiral model.
Mengapa spiral model begitu populer? Pendekatan
dengan model ini sangat baik digunakan untuk pengembangan sistem software
dengan skala besar. Karena progres perkembangan dari SE dapat dipantau oleh
kedua belah pihak baik developer maupun user / customer, sehingga mereka dapat
mengerti dengan baik mengenai software ini begitu juga dengan resiko yang
mungkin didapat pada setiap aktivitas yang dilakukan. Selain dari kombinasi 2
buah model yaitu waterfall dan prototyping, kelebihan dari software ini ada
pada analisis resiko yang dilakukan, sehingga resiko tersebut dapat direduksi
sebelum menjadi suatu masalah besar yang dapat menghambat SE. Model ini
membutuhkan konsiderasi langsung terhadap resiko teknis, sehingga diharapkan
dapat mengurangi terjadinya resiko yang lebih besar. Sebenarnya dengan menggunakan
prototype juga bisa menghindari terjadinya resiko yang muncul, tetapi kelebihan
dari model ini yaitu dilakukannya proses prototyping untuk setiap tahap dari
evolusi produk secara kontinu. Model ini melakukan tahap2 yang sudah sangat
baik didefinisikan pada model waterfall dan ditambah dengan iterasi yang
menyebabkan model ini lebih realistis untuk merefleksikan dunia nyata. Hal-hal
itulah yang menjadi kelebihan menggunakan spiral model.
Referensi : https://tonyjustinus.wordpress.com/2007/11/11/spiral-model/
4. RAPID APPLICATION DEVELOPMENT (RAD)
Rapid Application Development (RAD) adalah strategi
siklus hidup yang ditujukan untuk menyediakan pengembangan yang jauh lebih
cepat dan mendapatkan hasil dengan kualitas yang lebih baik dibandingkan dengan
hasil yang dicapai melalui siklus tradisional (McLeod, 2002). RAD
merupakan gabungan dari bermacam-macam teknik terstruktur dengan teknik prototyping dan teknik pengembangan joint application untuk mempercepat pengembangan
sistem/aplikasi (Bentley, 2004). Dari definisi-definisi konsep RAD ini, dapat
dilihat bahwa pengembangan aplikasi dengan menggunakan metode RAD ini dapat
dilakukan dalam waktu yang relatif lebih cepat.
Pemaparan
konsep yang lebih spesifik lagi dijelaskan oleh Pressman (2005) dalam bukunya, “Software Engineering: A
Practition’s Approach”. Ia mengatakan bahwa RAD adalah proses model
perangkat lunak inkremental yang menekankan siklus pengembangan yang singkat.
Model RAD adalah sebuah adaptasi “kecepatan tinggi” dari model waterfall, di mana
perkembangan pesat dicapai dengan menggunakan pendekatan konstruksi berbasis
komponen. Jika tiap-tiap kebutuhan dan batasan ruang lingkup projek telah
diketahui dengan baik, proses RAD memungkinkan tim pengembang untuk menciptakan
sebuah “sistem yang berfungsi penuh” dalam jangka waktu yang sangat singkat.
Dari penjelasan Pressman (2012) ini, satu perhatian khusus mengenai metodologi
RAD dapat diketahui, yakni implementasi metode RAD akan berjalan maksimal jika
pengembang aplikasi telah merumuskan kebutuhan dan ruang lingkup pengembangan
aplikasi dengan baik.
Sedangkan menurut Kendall (2010), RAD
adalah suatu pendekatan berorientasi objek terhadap pengembangan sistem yang
mencakup suatu metode pengembangan serta perangkat-perangkat lunak. RAD
bertujuan mempersingkat waktu yang biasanya diperlukan dalam siklus hidup
pengembangan sistem tradisional antara perancangan dan penerapan suatu sistem
informasi. Pada akhirnya, RAD sama-sama berusaha memenuhi syarat-syarat bisnis
yang berubah secara cepat.
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).
Kelebihan dan Kekurangan RAD
Metode pengembangan sistem RAD
relatif lebih sesuai dengan rencana pengembangan aplikasi yang tidak memiliki
ruang lingkup yang besar dan akan dikembangkan oleh tim yang kecil. Namun, RAD
pun memiliki kelebihan dan kekurangannya sebagai sebuah metodoligi pengembangan
aplikasi. Berikut ini adalah kelebihan metodologi RAD menurut Marakas (2006):
1. Penghematan
waktu dalam keseluruhan fase projek dapat dicapai.
2. RAD
mengurangi seluruh kebutuhan yang berkaitan dengan biaya projek dan sumberdaya
manusia.
3. RAD
sangat membantu pengembangan aplikasi yang berfokus pada waktu penyelesaian
projek.
4. Perubahan
desain sistem dapat lebih berpengaruh dengan cepat dibandingkan dengan
pendekatan SDLC tradisional.
5. Sudut
pandang user disajikan dalam sistem akhir baik melalui fungsi-fungsi sistem
atau antarmuka pengguna.
6. RAD
menciptakan rasa kepemilikan yang kuat di antara seluruh pemangku kebijakan
projek.
Sedangkan, mengacu pada pendapat
Kendall (2010), maka dapat diketahui bahwa kekurangan penerapan metode RAD
adalah sebagai berikut:
1. Dengan
metode RAD, penganalisis berusaha mepercepat projek dengan terburu-buru.
2. Kelemahan
yang berkaitan dengan waktu dan perhatian terhadap detail. Aplikasi dapat
diselesaikan secara lebih cepat, tetapi tidak mampu mengarahkan penekanan
terhadap permasalahan-permasalahan perusahaan yang seharusnya diarahkan.
3. RAD
menyulitkan programmer yang tidak berpengalaman menggunakan prangkat ini di
mana programmer dan analyst dituntut untuk menguasai kemampuan-kemampuan baru
sementara pada saat yang sama mereka harus bekerja mengembangkan sistem.
Sumber :
https://rakucileo.wordpress.com/2013/07/12/rad-rapid-application-development-model/
5. RUP (Rational
Unified Process
Rational Unified Process (RUP)
merupakan suatu metode rekayasa perangkat lunak yang dikembangkan dengan
mengumpulkan berbagai best practises yang terdapat dalam industri
pengembangan perangkat lunak. Ciri utama metode ini adalah menggunakan use-case
driven dan pendekatan iteratif untuk siklus pengembangan perankat lunak.
Gambar dibawah menunjukkan secara keseluruhan arsitektur yang dimiliki RUP.
RUP menggunakan konsep object
oriented, dengan aktifitas yang berfokus pada pengembangan model dengan
menggunakan Unified Model Language (UML). Melalui gambar dibawah dapat
dilihat bahwa RUP memiliki, yaitu:
§
Dimensi
pertama digambarkan secara horizontal. Dimensi ini mewakili aspek-aspek
dinamis dari pengembangan perangkat lunak. Aspek ini dijabarkan dalam tahapan
pengembangan atau fase. Setiap fase akan memiliki suatu major milestone
yang menandakan akhir dari awal dari phase selanjutnya. Setiap phase dapat
berdiri dari satu beberapa iterasi.
Dimensi ini terdiri atas Inception, Elaboration, Construction,
dan Transition.
§
Dimensi kedua digambarkan secara vertikal. Dimensi ini mewakili
aspek-aspek statis dari proses pengembangan perangkat lunak yang dikelompokkan
ke dalam beberapa disiplin. Proses pengembangan perangkat lunak yang dijelaskan
kedalam beberapa disiplin terdiri dari empat elemen penting, yakni who is
doing, what, how dan when. Dimensi ini terdiri
atas
Business Modeling, Requirement,
Analysis and Design, Implementation, Test, Deployment, Configuration dan Change Manegement,
Project Management, Environtment.
Gambar Arsitektur Rational Unified Process
Pada penggunaan kedua standard tersebut diatas yang
berorientasi obyek (object orinted) memiliki manfaat yakni:
• Improve productivity
Standard ini dapat memanfaatkan
kembali komponen-komponen yang telah tersedia/dibuat sehingga dapat
meningkatkan produktifitas
• Deliver high quality system
Kualitas sistem informasi dapat
ditingkatkan sebagai sistem yang dibuat pada komponenkomponen yang telah
teruji (well-tested dan well-proven) sehingga dapat mempercepat delivery
sistem informasi yang dibuat dengan kualitas yang tinggi.
• Lower maintenance cost
Standard ini dapat membantu
untuk menyakinkan dampak perubahan yang terlokalisasi dan masalah dapat dengan mudah
terdeteksi sehingga hasilnya biaya pemeliharaan dapat dioptimalkan atau lebih
rendah dengan pengembangan informasi tanpa standard yang jelas.
• Facilitate reuse
Standard ini memiliki kemampuan
yang mengembangkan komponen-komponen yang dapat digunakan kembali untuk
pengembangan aplikasi yang lainnya.
• Manage complexity
Standard ini mudah untuk mengatur dan memonitor semua proses
dari semua tahapan yang ada sehingga suatu pengembangan sistem informasi yang
amat kompleks dapat dilakukan dengan aman dan sesuai dengan harapan semua
manajer proyek IT/IS yakni deliver good quality software within cost and
schedule time and the users accepted.
Fase
RUP
§
Inception/insepsi
§
Elaboration/elaborasi
§
Construction/konstruksi
§
Transition/transisi
•
Inception
–
Menentukan Ruang lingkup proyek
–
Membuat ‘Business Case’
–
Menjawab pertanyaan “apakah yang dikerjakan
dapat menciptakan ‘good business sense’ sehingga proyek dapat dilanjutkan
•
Elaboration
–
Menganalisa berbagai persyaratan dan resiko
–
Menetapkan ‘base line’
–
Merencanakan fase berikutnya yaitu construction
•
Construction
–
Melakukan sederetan iterasi
–
Pada setiap iterasi akan melibatkan proses
berikut: analisa desain, implementasi dan testing
•
Transistion
–
Membuat apa yang sudah dimodelkan menjadi suatu
produk jadi
–
Dalam fase ini dilakukan:
•
Beta dan performance testing
•
Membuat dokumentasi tambahan seperti; training,
user guides dan sales kit
•
Membuat rencana peluncuran produk ke komunitas
pengguna
Peran
Use Case Pada Setiap Fase
•
Inception
–
Menolong mengembangkan scope proyek
–
Menolong menetapkan penjadwalan dan anggaran
•
Elaboration
–
Menolong dalam melakukan analisa resiko
–
Menolong
mempersiapkan fase berikutnya yaitu konstruksi
•
Construction
–
Melakukan sederetan iterasi
–
Pada
setiap iterasi akan akan melibatkan proses berikut: analisa desain,
implementasi dan testing
•
Transistion
–
Membuat apa yang sudah dimodelkan menjadi suatu
produk jadi
–
Dalam fase ini dilakukan:
•
Beta dan performance testing
•
Membuat dokumentasi tambahan seperti; training,
user guides dan sales kit
•
Membuat rencana peluncuran produk ke komunitas
pengguna
Penerapan
Tahapan Metodologi Pengembagan Perangkat Lunak dengan Menggunakan RUP (Contoh Kasus)
Metodologi
Rational Unified Process (RUP). Metode
RUP merupakan metode pengembangan kegiatan yang berorientasi pada proses. Dalam metode ini, terdapat empat tahap
pengembangan perangkat lunak yaitu:
§ Inception
Pada tahap ini pengembang mendefinisikan batasan
kegiatan, melakukan analisis kebutuhan user, dan melakukan
perancangan awal perangkat lunak (perancangan
arsitektural dan use case). Pada
akhir fase ini, prototipe perangkat lunak versi Alpha harus sudah
dirilis
§
Elaboration :
Pada tahap ini dilakukan perancangan perangkat lunak
mulai dari menspesifikasikan fitur perangkat lunak hingga perilisan prototipe
versi Betha dari perangkat lunak.
§ Construction
Pengimplementasian
rancangan perangkat lunak yang telah dibuat dilakukan pada tahap ini. Pada
akhir tahap ini, perangkat lunak versi akhir yang sudah disetujui administrator
dirilis beserta dokumentasi perangkat lunak.
§ Transition
Instalasi
, deployment dan sosialisasi perangkat lunak dilakukan pada tahap ini.
Sumber :
https://amen88.wordpress.com/2010/01/30/metodologi-rup/
6. Extreme Programming
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 class dan 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 launching perangkat 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 developer menyelesaikan 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 Refactoring mengusung 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 build sesering 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.
sumber : http://ganiamanda.blog.widyatama.ac.id/2016/02/13/extreme-programming-xp-model/
Langganan:
Komentar (Atom)











