Pada model rancangan interaksi sederhana ini input atau masukan
hanya memiliki satu titik. yang mana masukan tersebut, lalu lakukan
langkah-langkah berikut :
·
Identifikasi kebutuhan
dan persyaratan sistem disini suatu sistem akan di identifikasi sesuai dengan
kebutuhan sistem itu sendiri.
·
Pengembangan desain
alternatif (desain konseptual dan fisikal)
·
Membuat versi interaktif
dari desain yang dihasilkan
·
Mengevaluasi desain
(usabilitas dan user experience)
Evaluasi dapat dilakukan dimana saja, rancangan yang telah di evakuasi dapat
kambali didesain ulang atau apakah rancangan tersebut tidak sesuai dengan
kebutuhan user, maka alur tersebut akan terus berputar hingga pada tahap
evaluasi tidak lagi terjadi kesalahan, baik dalam penetapan kebutuhan user
maupun pendesainannya, sehingga pada tahap evaluasi terciptalah sebuah hasil
akhir yang valid.
Identifikasi kemampuan user, strategi yang digunakan untuk meningkatkan
ketrampilannya, alat yang saat ini dipakai, masalah-masalah yang dialami, perubahan
yang diinginkan baik dalam ketrampilan maupun peralatan.
Metode : tanya kemampuan user dan buat daftar dengan skala prioritas,
observasi ketrampilan di lapangan.
- Evaluasi kompetisi
Tentukan kekuatan dan kelemahan rancangan
Metode : pengguna diminta untuk mencoba menggunakan berbagi
produk dan minta untuk menyebutkan kelebihan dan kelemahan dari masing-masing
produk.
-Rancang sambil jalan
Gunakan hasil analisa untuk membuat alternatif solusi, minta
masukan sampai dengan penentuan pilihan yang terbaik.
Metode : tanyai user sehubungan dengan pengalaman menggunakan
prototipe.
- Evaluasi dan validasi
Secara periodik user memberikan masukan selama pengembangan dan
perancangan akan diulang berdasarkan masukan tadi.
Metode : amati kebutuhan pokok user dalam menggunakan sistem.
Metode : amati kebutuhan pokok user dalam menggunakan sistem.
- Benchmark
Memadukan hal-hal terbaik yang dimiliki pesaing untuk diterapkan
dalam sistem yang dibangun Metode : menggali informasi dari user hal-hal yang
sebaiknya ada dibandingkan dengan kompetitor, contoh : situs IBM.
Dalam
Siklus permodelan ini pengujian dilakukan terus menerus, tidak harus dikahir.
Misalnya dimulai dari menentukan kosep desain (conceptual design ) dalam proses
ini akan langsung terjadi evaluasi untuk langsung ternilai apakah sudah sesuai
dengan kebutuhan user, bila belum maka akan terus berulang di evaluasi hingga
benar-benar pas, selanjutnya apabila sudah pas, maka dari tahap evaluasi yang
pertama aka lanjut ke proses yg selanjutnya yakni requirements/specification
yakni memverifikasikan persyaratan rancangan tersebut, dan pada tahap itu juga
langsung terjadi pengevaluasian seperti tahap pertama, dan selanjutnya akan
tetap sama terjadi pada tahapan-tahapan selanjutnya yakni task
analysis/fungsion analysis, pengimplementasian, prototyping hingga pada
akhirnya terciptalah sebuah aplikasi yang sesuai dengan kebutuhan user. Intinya
pada rancangan model ini pengevaluasian dilakukan disetiap tahapan tidak hanya
pada tahapan akhir seperti model-model rancangan yang lainnya.
Model ini merupakan perluasan dari model waterfall. Disebut
sebagai perluasan karena tahap-tahapnya mirip dengan yang yang dalam model
waterfall. Jika dalam model waterfall proses dijalankan secara linier, maka
dalam model V proses dalikukan bercabang dalam model V ini digambarkan hubungan
antara tahap pengembangan software dengan tahap pengujiannya.
Bisa dikatakan model ini merupakan perluasan dari model
waterfall. Disebut sebagai perluasan karena tahap-tahapnya mirip dengan yang
terdapat dalam model waterfall. Jika dalam model waterfall proses dijalankan secara
linear, maka dalam model V proses dilakukan bercabang. Dalam model V ini
digambarkan hubungan antara tahap pengembangan software dengan tahap
pengujiannya.
Berikut penjelasan masing-masing tahap beserta tahap pengujiannya:
Berikut penjelasan masing-masing tahap beserta tahap pengujiannya:
1. Requirement Analysis & Acceptance Testing
Tahap Requirement Analysis sama seperti yang
terdapat dalam model waterfall. Keluaran dari tahap ini adalah dokumentasi
kebutuhan pengguna. Acceptance Testing merupakan tahap yang akan mengkaji
apakah dokumentasi yang dihasilkan tersebut dapat diterima oleh para pengguna
atau tidak.
2. System Design & System Testing
Dalam tahap ini analis sistem mulai
merancang sistem dengan mengacu pada dokumentasi kebutuhan pengguna yang sudah
dibuat pada tahap sebelumnya. Keluaran dari tahap ini adalah spesifikasi
software yang meliputi organisasi sistem secara umum, struktur data, dan yang
lain. Selain itu tahap ini juga menghasilkan contoh tampilan window dan juga
dokumentasi teknik yang lain seperti Entity Diagram dan Data Dictionary.
3. Architecture Design & Integration Testing
3. Architecture Design & Integration Testing
Sering juga disebut High Level Design. Dasar
dari pemilihan arsitektur yang akan digunakan berdasar kepada beberapa hal
seperti: pemakaian kembali tiap modul, ketergantungan tabel dalam basis data, hubungan
antar interface, detail teknologi yang dipakai.
4. Module Design & Unit Testing
Sering juga disebut sebagai Low Level Design. Perancangan
dipecah menjadi modul-modul yang lebih kecil. Setiap modul tersebut diberi
penjelasan yang cukup untuk memudahkan programmer melakukan coding. Tahap ini
menghasilkan spesifikasi program seperti: fungsi dan logika tiap modul, pesan
kesalahan, proses input-output untuk tiap modul, dan lain-lain.
5. Coding
Dalam tahap ini
dilakukan pemrograman terhadap setiap modul yang sudah dibentuk.
V Model
memiliki beberapa kelebihan. Kelebihan-kelebihan tersebut secara garis besar
dapat dijelaskan seperti berikut:
· V Model sangat fleksibel. V Model mendukung project tailoring dan penambahan dan pengurangan method dan tool secara dinamik. Akibatnya sangat mudah untuk melakukan tailoring pada V Model agar sesuai dengan suatu proyek tertentu dan sangat mudah untuk menambahkan method dan tool baru atau menghilangkan method dan tool yang dianggap sudah obsolete.
· V
Model dikembangkan dan di-maintain oleh publik. User dari V Model
berpartisipasi dalam change control board yang memproses semua change request
terhadap V Model.
· V
Model juga memiliki beberapa kekurangan. Kekurangan-kekurangan tersebut yaitu:
· V
Model adalah model yang project oriented sehingga hanya bisa digunakan sekali
dalam suatu proyek.
· V
Model terlalu fleksibel dalam arti ada beberapa activity dalam V Model yang
digambarkan terlalu abstrak sehingga tidak bisa diketahui dengan jelas apa yang
termasuk dalam activity tersebut dan apa yang tidak.
Siklus Hidup Untuk
Pengembangan (RAD: Linier Sequential)
·
Versi
cepat dari Water Fall, dengan pengembangan modular
·
Menggunakan
Joint Application Development
Rapid Aplication Development (RAD)
adalah sebuah model proses perkembangan software sekuensial linier yang
menekankan siklus perkembangan yang sangat pendek. Model RAD ini merupakan
sebuah adaptasi “kecepatan tinggi” dari model sekuensial linier di mana
perkembangan cepat dicapai dengan menggunakan pendekatan kontruksi berbasis
komponen. Jika kebutuhan dipahami dengan baik, proses RAD memungkinkan tim
pengembangan menciptakan “sistem fungsional yang utuh” dalam periode waktu yang
sangat pendek (kira-kira 60 sampai 90 hari). Karena dipakai terutama pada
aplikasi sistem konstruksi, pendekatan RAD melingkupi fase – fase sebagai
berikut :
Business modeling. Aliran informasi
di antara fungsi – fungsi bisnis dimodelkan dengan suatu cara untuk menjawab
pertanyaan – pertanyaan berikut :informasi
apa yang mengendalikan proses bisnis? Informasi apa yang di munculkan? Siapa
yang memunculkanya? Ke mana informasi itu pergi? Siapa yang memprosesnya
Data modeling. Aliran informasi yang
didefinisikan sebagai bagian dari fase business modelling disaring ke dalam
serangkaian objek data yang dibutuhkan untuk
menopang bisnis tersebut. Karakteristik (disebut atribut) masing-masing objek diidentifikasi dan hubungan antara objek – objek tersebut didefinisikan.
Proses modeling. Aliran informasi
yang didefinisikan di dalam fase data modeling ditransformasikan untuk mencapai
aliran informasi yang perlu bagi implementasi
sebuah fungsi bisnis. Gambaran pemrosesan diciptakan untuk menambah,
memodifikasi, menghapus, atau mendapatkan kembali sebuah objek data.
Application Generation. RAD
mengasumsikan pemakaian teknik generasi ke empat. Selain menciptakan perangkat
lunak dengan menggunakan bahasa pemrograman generasi ketiga yang konvensional,
RAD lebih banyak memproses
kerja untuk memkai lagi komponen program yang ada ( pada saat memungkinkan)
atau menciptakan komponen yang bisa dipakai lagi (bila perlu). Pada semua
kasus, alat – alat bantu otomatis dipakai untuk memfasilitasi konstruksi
perangkat lunak.
Testing and turnover.Karena proses
RAD menekankan pada pemakaian kembali, banyak komponen program telah diuji. Hal
ini mengurangi keseluruhan
waktu pengujian. Tetapi komponen baru harus di uji dan semua interface harus
dilatih secara penuh.
Kelebihan :
- RAD
mengikuti tahapan pengembangan sistem sepeti umumnya, tetapi mempunyai kemampuan untuk menggunakan kembali komponen yang ada (reusable
object)
- Setiap
fungsi dapat dimodulkan dalam waktu tertentu dan dapat dibicarakan oleh tim RAD yang terpisah dan kemudian diintegrasikan sehingga waktunya lebih efesien
Kekurangan
model RAD adalah:
- Bagi proyek yang besar tetapi berskala, RAD memerlukan sumber daya manusia yang memadai untuk menciptakan jumlah tim RAD yang baik.
- Bagi proyek yang besar tetapi berskala, RAD memerlukan sumber daya manusia yang memadai untuk menciptakan jumlah tim RAD yang baik.
- RAD
menuntut pengembangan dan pelanggan memiliki komitmen di dalam aktivitas
rapid-fire yang diperlukan untuk melengkapi sebuah sistem, di dalam kerangka waktu
yang sangat diperpendek. Jika komitmen tersebut tidak ada, proyek RAD akan
gagal.
Salah satu strategi yang sering dipakai sebagai model
proses atau paradigma rekayasa perangkat lunak yaitu
dengan menggunakan model water fall yang dikembangkan sejak tahun
1970-an.
Model waterfall merupakan
pendekatan perangkat lunak yang sistematik dan sekuensial yang dimulai dari
tahap analisis, desain, kode, pengujian dan pemeliharaaan Model waterfall
juga dikenal sebagai Linier Sequential atau classic
life cycle, model ini mempunyai keterbatasan yang mengakomodasi persyaratan
(requirement) berubah. Pelanggan tidak akan melihat suatu hasil
kerja suatu proyek yang secara fungsional belum dapat digunakan.
a. System Engineering
Proses penilaian sistem lama yang sedang berjalan dan studi
kelayakan pengembangan sistem baru berdasarkan aspek teknologi, ekonomis dan
sumber daya manusia.
b. Analisis
Perolehan kebutuhan pengguna sistem dari user serta pilihan
solusi jenis sistem informasi yang akan dikembangkan.
c. Desain
Proses ini digunakan untuk mengubah kebutuhan-kebutuhan diatas
menjadi representasi ke dalam bentuk software. Desain harus dapat
mengimplementasikan kebutuhan yang telah disebutkan pada tahap sebelumnya maka
proses ini juga harus didokumentasikan sebagai konfigurasi dari software.
d. Coding Dan Testing
Desain harus diubah bentuknya menjadi bentuk yang dapat
dimengerti oleh komputer, yaitu ke dalam bahasa pemrograman melalui proses
coding. Tahap ini merupakan implementasi dari tahap desain yang secara teknis
akan dikerjakan oleh programmer. Proses Coding ini harus dilakukan Testing
untuk menguji kesalahan-kesalahan program maupun fungsi dari sistem.
e. Implementasi
Setelah semua fungsi-fungsi software harus di ujicoba agar
software bebas dari kesalahan, dan hasilnya harus benar-benar sesuai dengan
kebutuhan yang sudah didefinisikan sebelumnya. Maka proses selanjutnya adalah
bagaimana sistem baru akan diinstall dan dijalankan di perusahaan dengan
pengoperasian yang dilakukan oleh user.
f. Pemeliharaan
Pemeliharaan
suatu software sangat diperlukan, termasuk di dalamnya adalah pengembangan,
karena software yang dibuat tidak selamanya hanya seperti itu. Ketika
dijalankan mungkin saja masih ada kesalahan kecil yang tidak ditemukan
sebelumnya, atau ada penambahan fitur-fitur yang belum ada pada software
tersebut. Pengembangan diperlukan ketika adanya perubahan dari perusahaan
seperti ketika ada pergantian sistem operasi atau perangkat lainnya.
Alat Bantu ( Tool Pemodelan Sistem)
Alat Bantu, Tool Pemodelan Sistem diperlukan untuk metodologi
pengembangan system, pada metode waterfall tool yang tersedia diantaranya :
Bagan Alir System System Flow Chart), Diagram Arus Data (Data
Flow Diagram), Kamus Data (data dictionary), Bagan
Alir Program (program flow chart), pseudocode, Tabel
Keputusan (decision table). Alat bantu tersebut digunakan oleh
analis system untuk berkomunikasi dengan pemakai system dan teknisi system
(pemrogram dan teknisi lainnya).
1. Alat Bantu Analisis
Analis system perlu
berkomunikasi dengan pengguna system. Pada tahap ini analis system perlu
menyampaikan hasil analisisnya kepada pengguna system. Hasil analisis adalah
pemahaman tentang system yang lama dan kebutuhan-kebutuhan informasi yang
dibutuhkan oleh pengguna system. Alat-alat komunikasi yang digunakan pada tahap
ini adalah : Bagan Alir System System Flow Chart),Diagram Arus
Data (Data Flow Diagram), Kamus Data (data
dictionary).
Tool yang tersedia untuk membuat alat-alat komunikasi tersebut
diantaranya: Microsoft Office Visio, DIA, Microsoft Word, Microsoft Excell, dan
lain-lain.
2. Alat Bantu Desain
Pada tahap desain,
analis system banyak berkomunikasi dengan teknisi system yaitu dengan programmer, ahli
basis data, ahli telekomunikasi, dan sebagainya. Analis system membutuhkan alat
komunikasi yang efektif supaya teknisi system dapat memahami dan memudahkan
hasil analisis untuk diubah menjadi system secara fisik. Dalam hal ini desain
system membutuhkan alat bantu: Bagan Alir System System Flow Chart), Diagram
Arus Data (Data Flow Diagram), Kamus Data (data
dictionary), ERD(Entitas Relation Diagram),Normalisasi data, dan
lainnya.
Tool yang mendukung diantaranya : Microsoft Office Visio, DIA,
Microsoft Word, Microsoft Excell, dan lain-lain.
3. Alat Bantu Coding /
Programming
Pada tahap ini dilakukan
proses coding dengan menggunakan toolpseudocode yang membantu
programmer dalam membangun system, dan untuk tool yang digunakan dalam
programming banyak yang tersedia seperti Delphi, Visual Basic, PHP, Java, dan
lainnya.
4. Alat bantu Testing /
Pengujian
Perangkat lunak yang telah dikembangkan perlu diuji sebelum
digunakan secara penuh didalam system. Pengujian dikatakan berhasil jika mampu
menemukan kesalahan-kesalahan yang tersembunyi dalam perangkat lunak. Terdapat
dua pendekatan pengujian perangkat lunak, yaitu: white box testing,
black box testing. White box testing dilakukan dengan
menguji detail procedural, yaitu mengamati jalur logical yang dibentuk oleh
struktur pengendalian program (perulangan dan percabangan), apabila mengungkap
100% kesalahan logika yang mungkin muncul dan bersifat exhaustive (melelahkan)
karena terjadi ledakan kombinasi berbagai modul / program yang besar dan
komplek, dan dilakukan pada tahap awal pengujian. Metode yang digunakan
pada white box testing jalur dasar (basis path) pengujian
kondisi, pengujian aliran data, pengujian perulangan.
Black box testing dilakukan
pada persyaratan fungsional dari perangkat lunak, dilakukan tidak diawal tahap
pengujian, mengungkap kesalahan-kesalahan pada fungsi yang salah satu hilang,
antar muka, akses ke basis data eksternal, kinerja, inisialisasi dan terminasi
program. Metode yang dapat digunakan untuk pengujian black box testing Equivalence
partitioning, Analisis nilai batas, Teknik grafik sebab akibat.
Strategi yang dilakukan dalam pengujian perangkat lunak meliputi
proses berbentuk spiral dan debugging. Proses pengujian berbentuk
spiral dengan urutan aktivitas pengujian unit, pengujian integrasi, pengujian
validasi, pengujian system.Debugging merupakan konsekuensi dari
pengujian perngkat lunak, debuggingbersifat seni yang dipengaruhi
oleh aspek psikologis (intuisi dan keberuntungan), pendekatan yang dapat
dilakukan dalam proses debugging meliputi: tanpa metode
tertentu (uji coba), backtracking (dimulai dari tempat ditemukannya
gejala kesalahan, kemudian dilakukan pelacakan kembali ke program hingga
diharapkan sumber kesalahan dapat ditemukan, cause elimination (eliminasi
penyebab= partisi biner / binary partitioning) yaitu dibuat
hipotesis penyebab yang kemudian diuji kebenarannya dengan data yang
berhubungan dengan kesalahan yang terjadi.
Tool yang digunakan dalam pengujian perangkat lunak yaitu:
pelacak program (program tracer), test case (pembangkit kasus
pengujian, memory dumps, pemetaan referensi silang.
5. Pemeliharaan Perangkat
Lunak
Pemeliharaan perangkat
lunak meliputi: korektif (pemeliharaan yang dilakaukan apabila terjadi
kerusakan atau kesalahan), adaptif atau produktif (pemeliharaan yang dilakukan
secara terus menerus melalui proses monitoring, penyempurnaan (pemeliharaan
sebagai hasil dari penemuan perawatan adaptif), preventif (pemeliharaan yang
dilakukan untuk pencegahan kerusakan).
D. Kebutuhan pada saat
pembuatan system yang meliputi: sumber daya, waktu, biaya, resiko, upgrade.
1. Kebutuhan
sumber daya
Membutuhkan jumlah sumber daya yang banyak, karena banyak proses
yang dilakukan serta banyak tenaga ahli yang dibutuhkan.
2. Kebutuhan
waktu
Membutuhkan
waktu yang lama karena harus menyelesaikan tahap demi tahap dalam pengembangan.
3. Kebutuhan
biaya
Kebutuhan biaya besar karena menggunakan sumber daya yang
banyak, waktu yang cukup lama, dan tahapan proses yang panjang.
4. Kebutuhan
resiko
Resiko dalam menggunakan metode ini sangat besar, kemungkinan
terjadinya kegagalan system sehingga harus mengulang dari awal yang menyebabkan
pembekakan biaya diluar rencana anggaran. Kegagalan system sangat berpengaruh
besar, kemungkinan system tidak dapat digunakan atau harus diperbaiki dari
awal.
5. Kebutuhan
upgrade
Dalam melakukan upgrade akan terjadi kesulitan karena harus
menyesuikan banyak hal, diantaranya kesesuaian dukungan hardware, software baik
software program maupun database, karena dimungkinkan pada saat system dibuat
belum mengalami / menggunakan adanya spesifikasi hardware maupun software yang
baru sesuai yang dibutuhkan saat ini. Pada metode ini proses upgrade tidak
fleksibel, akan mempengaruhi system secara keseluruhan.
e. Kesimpulan
Penggunaan metode waterfall dalam
pengembangan perangkat lunak dapat disimpulkan sebagai berikut :
1 .
Keunggulan:
Ø Proses
pengembangan sangat terstruktur dan sistematik
Ø Melalui
definisi kebutuhan, sehingga gap atau kesenjangan yang terjadi
antara kebutuhan dan sistem yang dihasilkan dapat dikurangi.
Ø Menghasilkan
petunjuk arah pengembangan yang jelas bagi manajemen.
.
Kelemahan:
Ø Tidak
adaptif terhadap perubahan yang dapat terjadi selama proses pengembangan (kaku
atau rigid).
Ø Melelahkan
karena membutuhkan waktu pengembangan yang lama dan biaya yang tinggi
Ø Proyek
yang sebenarnya jarang mengikuti aliran sequential yang ditawarkan model ini.
Ø Iterasi (Pengulangan) selalu terjadi dan menimbulkan masalah pada aplikasi yang dibentuk oleh model ini.
Ø Seringkali
pada awalnya customer sulit menentukan semua kebutuhan secara explisit.
Ø Klien
harus sabar karena versi program yang sedang jalan tidak akan tersedia sampai
proyek pengembangan selesai
Sumber : http://erniwijayanti07.blogspot.com/
0 komentar:
Posting Komentar