MODEL SEKUENSIAL LINIER
Model sekuensial linier untuk software engineering yang
disebut dengan siklus kehidupan klasik atau model air terjun. Model ini
mengusulkan sebuah pendekatan kepada perkembangan software yang sistematik dan
sekuensial. Dimodelkan setelah siklus rekysa konvensional, model sekuensial
linier melingkupi aktivitas-aktivitas sebagai berikut :
1. Feasibility
Kerja dimulai dengan membangun syarat dari semua elemen
sistem dan mengalokasikan beberapa subset dari kebutuhan ke software tersebut.
Pandangan sistem ini penting ketika software harus berhubungan dengan
elemen-elemen yang lain seperti software, manusia, dan database. Rekayasa dan
anaslisis sistem menyangkut pengumpulan kebutuhan pada tingkat sistem dengan
sejumlah kecil analisis serta disain tingkat puncak. Rekayasa informasi
mencakup juga pengumpulan kebutuhan pada tingkat bisnis strategis dan tingkat area
bisnis .
2. Analisis kebutuhan Software
Proses pengumpulan kebutuhan diintensifkan dan difokuskan,
khusunya pada software. Untuk memahami sifat program yang dibangun, analis
harus memahami domain informasi, tingkah laku, unjuk kerja, dan interface yang
diperlukan. Kebutuhan baik untuk sistem maupun software didokumentasikan dan
dilihat lagi dengan pelanggan .
3. Desain
Desain software sebenarnya adalah proses multi langkah yang
berfokus pada empat atribut sebuah program yang berbeda; struktur data, arsitektur
software, representasi interface, dan detail (algoritma) prosedural. Proses
desain menterjemahkan syarat/kebutuhan ke dalam sebuah representasi software
yang dapat diperkirakan demi kualitas sebelum dimulai pemunculan kode.
Sebagaimana persyaratan, desain didokumentasikan dan menjadi bagian dari
konfigurasi software.
4. Implementasi
Desain harus diterjemahkan kedalam bentuk mesin yang bisa
dibaca. Langkah pembuatan kode melakukan tugas ini. Jika desain dilakukan
dengan cara yang lengkap, pembuatan kode dapat diselesaikan secara mekanis.
5. Pengujian
Sekali program dibuat, pengujian program dimulai. Proses
pengujian berfokus pada logika internal software, memastikan bahwa semua
pernyataan sudah diuji, dan pada eksternal fungsional, yaitu mengarahkan
pengujian untuk menemukan kesalahan-kesalahan dan memastikan bahwa input yang
dibatasi akan memberikan hasil aktual yang sesuai dengan hasil yang dibutuhkan.
MODEL PROTOTIPE
Prototype adalah sebuah Javascript Framework yang dibuat
untuk lebih memudahkan proses dalam membangun aplikasi berbasis web. Paradigma
dari metode prototyping adalah sistem informasi yang menggambarkan hal-hal
penting dari sistem informasi yang akan datang. Prototipe sistem informasi
bukanlah merupakan sesuatu yang lengkap, tetapi sesuatu yang harus dimodifikasi
kembali, dikembangkan, ditambahkan atau digabungkan dengan sistem informasi
yang lain bila perlu. Model ini digunakan jika customer tidak menjelaskan
detail kebutuhan input, proses atau output, sehingga developer tidak dapat
memastikan algoritma yang akan dipakai, kesesuaian sistem operasi atau bentuk
user interface. Prototyping model dimulai dengan mendengarkan kebutuhan user.
Engineer dan customer bertemu dan menentukan semua tujuan software dan
menentukan kebutuhan-kebutuhan. Developer kemudian membangun prototype dan user
menguji coba prototype untuk memberikan feedback. Prototype dapat dijalankan
sebagai sistem yang pertama. User bisa mendapatkan pengertian dari sistem yang
sesungguhnya dan developer dapat membangun sistem dengan segera. Kekurangan :
kontrak akan merugikan, dirugikan oleh keinginan customer yang meminta
penambahan-penambahan. Kelebihan : akan mengurangi waktu pembuatan program, kebutuhan
customer akan lebih terpenuhi dengan baik, jika kebutuhannya belum jelas, maka
dengan prototype akan lebih menguntungkan.
Metode pengembangan
perangkat lunak ini dimulai dengan pengumpulan kebutuhan. Pendekatan
prototyping model digunakan jika pemakai hanya mendefenisikan secara umum dari
perangkat lunak tanpa merinci kebutuhan input, pemrosesan dan outputnya,
sementara pengembang tidak begitu yakin akan efisiensi algoritma, adaptasi
sistem operasi, atau bentuk antarmuka manusia-mesin yang harus diambil.
2. Kelebihan dan Kekurangan
Keunggulan prototyping adalah :
1) Adanya
komunikasi yang baik antara pengembang dan pelanggan.
2) Pengembang
dapat bekerja lebih baik dalam menentukan kebutuhan pelanggan.
3) Pelanggan
berperan aktif dalam pengembangan sistem.
4) Lebih menghemat
waktu dalam pengembangan sistem.
5) Penerapan
menjadi lebih mudah karena pemakai
mengetahui apa yang diharapkannya
Sedangkan kelemahan prototyping adalah :
1) Pelanggan tidak
melihat bahwa perangkat lunak belum mencerminkan kualitas perangkat lunak
secara keseluruhan dan belum memikirkan peneliharaan dalam jangka waktu yang
lama.
2) Pengembang
biasanya ingin cepat menyelesaikan proyek sehingga menggunakan algoritma dan
bahasa pemrograman sederhana.
3) Hubungan
pelanggan dengan komputer mungkin tidak menggambarkan teknik perancangan yang
baik.
3. Bentuk Prototipe
Berdasarkan karakteristiknya prototipe sebuah sistem dapat
berupa low fidelity dan high fidelity. Fidelity mengacu kepada tingkat
kerincian sebuah sistem (Walker et al, 2003).
Low fidelity prototype tidak terlalu rinci menggambarkan
sistem. Karakteristik dari low fidelity prototype adalah mempunyai fungsi atau
interaksi yang terbatas, lebih menggambarkan kosep perancangan dan layout
dibandingkan dengan model interaksi, tidak memperlihatkan secara rinci
operasional sistem, mendemostrasikan secara umum feel and look dari antarmuka
pengguna dan hanya menggambarkan konsep pendekatan secara umum (Walker et al,
2003).
High fidelity protoype lebih rinci menggambarkan sistem.
Prototipe ini mempunyai interaksi penuh dengan pengguna dimana pengguna dapat
memasukkan data dan berinteraksi dengan dengan sistem, mewakili fungsi-fungsi
inti sehingga dapat mensimulasikan sebagian besar fungsi dari sistem akhir dan
mempunyai penampilan yang sangat mirip dengan produk sebenarnya (Walker et al,
2003).
Fitur yang akan diimplementasikan pada prototipe sistem
dapat dibatasi dengan teknik vertikal atau horizontal. Vertical prototype
mengandung fungsi yang detail tetapi hanya untuk beberapa fitur terpilih, tidak
pada keseluruhan fitur sistem. Horizontal prototype mencakup seluruh fitur
antarmuka pengguna namun tanpa fungsi pokok hanya berupa simulasi dan belum dapat
digunakan untuk melakukan pekerjaan yang sebenarnya (Walker et al, 2003).
4. Proses
Pembuatan Prototipe
Proses pembuatan prototipe merupakan proses yang interaktif
dan berulang-ulang yang menggabungkan langkah-langkah siklus pengembangan
tradisional. Prototipe dievaluasi beberapa kali sebelum pemakai akhir
menyatakan protipe tersebut diterima
.png)
Tahapan-tahapan Prototyping
- Pengumpulan kebutuhan : Pelanggan dan pengembang bersama-sama mendefinisikan format seluruh perangkat lunak, mengidentifikasikan semua kebutuhan, dan garis besar sistem yang akan dibuat.
- Membangun prototyping : Membangun prototyping dengan membuat perancangan sementara yang berfokus pada penyajian kepada pelanggan (misalnya dengan membuat input dan format output)
- Evaluasi prototyping : Evaluasi ini dilakukan oleh pelanggan apakah prototyping yang sudah dibangun sudah sesuai dengan keinginann pelanggan. Jika sudah sesuai maka langkah 4 akan diambil. Jika tidak prototyping direvisi dengan mengulangu langkah 1, 2 , dan 3.
- Mengkodekan sistem : Dalam tahap ini prototyping yang sudah di sepakati diterjemahkan ke dalam bahasa pemrograman yang sesuai
- Menguji sistem : 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
- Evaluasi Sistem : Pelanggan mengevaluasi apakah sistem yang sudah jadi sudah sesuai dengan yang diharapkan . Jika ya, langkah 7 dilakukan; jika tidak, ulangi langkah 4 dan 5.
- Menggunakan sistem : Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk digunakan.\
MODEL 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.
Fase-fase dalam RAD
1. Bussines Modelling. Aliran informasi diantara funsi-fungsi bisnis dimodelkan
dengan suatu cara untuk
menjawab pertanyaan-pertanyaan berikut: Informasi apa yg
mengendalikan proses bisnis? Informasi apa yg dimunculkan? Siapa yg
memunculkan? Ke mana informasi itu pergi? Siapa yg memprosesnya?
2. Data Modelling Aliran informasi yg di definisikan sebagai bagian dari fase
bussiness modelling di
saring ke dalam serangkaian objek data yg dibutuhkan untuk
menopang bisnis tersebut. Karakteristik (disebut atribut) masing-masing
objek diidentifikasi dan hubungan antara objek-objek tersebut didefinisikan.
3. Prosess Modeling Aliran informasi yg didefinisikan di dalam fase data
modelling ditransformasikan untuk mencapai aliran informasi yg perlu bagi implementasi
sebuah fungsi bisnis. Gambaran pemrosesan digunakan untuk menambah, memodifikasi,
menghapus, atau mendapatkan kembali sebuah objek data.
perangkat lunak dengan menggunakan bahasa pemrograman
generasi ke-tiga yg konvensional, RAD lebih banyak memproses kerja untuk memakai
lagi komponen program yg ada (pada saat memungkinkan) atau menciptakan
komponen yg bisa dipakai lagi (bila perlu). Pada semua kasus, alat-alat bantu
otomatis dipakai untuk memfasilitasi konstruksi perangkat lunak.
5. Testing and turnover Karena proses RAD menekankan pada pemakaian kembali, banyak
komponen
program telah diuji. Hal ini mengurangi keseluruhan waktu
pengujian. Tetapi komponen baru harus diuji dan semua interface harus dilatih
secara penuh.
Rencana Kebutuhan (Requirement Planning)
Pada tahap ini, user dan analyst melakukan semacam pertemuan
untuk melakukan identifikasi tujuan dari aplikasi atau sistem dan melakukan
identifikasi kebutuhan informasi untuk mencapai tujuan. Pada tahap ini hal
terpenting adalah adanya keterlibatan dari kedua belah pihak, bukan hanya
sekedar persetujuan akan proposal yang sudah dibuat. Untuk lebih jauh lagi,
keterlibatan user bukan hanya dari satu tingkatan pada suatu organisasi,
melainkan beberapa tingkatan organisasi sehingga informasi yang dibutuhkan
untuk masingmasing user dapat terpenuhi dengan baik. Di samping itu, dapat juga
melakukan koordinasi dengan Chief Information Office (CIO) atau bagian
perencana strategis terutama untuk mengembangkan suatu aplikasi E-commerce
berbasis Web untuk mendapatkan informasi yang lebih detail akan tujuan dari
suatu organisasi. Pertemuan semacam ini seringkali disebut Joint Aplication
Development.
Proses Desain (Design Workshop)
Pada tahap ini adalah melakukan proses desain dan melakukan
perbaikan-perbaikan apabila masih terdapat ketidaksesuaian desain antara user
dan analyst. Untuk tahap ini maka keaktifan user yang terlibat sangat
menentukan untuk mencapai tujuan, karena user bisa langsung memberikan komentar
apabila terdapat ketidaksesuaian pada desain. Biasanya, user dan analyst
berkumpul menjadi satu dan duduk di meja melingkar dimana masing-masing orang
bisa melihat satu dengan yang lain tanpa ada halangan.
Apabila memungkinkan, maka masingmasing user diberikan satu
komputer yang terhubung satu dengan yang lain, sehingga masing-masing bisa
melihat desain yang dibuat dan langsung memberikan komentar. Hal ini sering
kali disebut dengan Group Decision Support System (GDSS). Pada beberapa kasus,
GDSS ini merupakan suatu langkah yang ideal, karena user dan analyst dapat
menyetujui desain yang dibuat untuk kemudian dilanjutkan oleh programmer dalam
pembuatan prototype dari aplikasi yang dimaksud dengan langsung menampilkan
kepada user hasilnya dengan cepat. Pada tahap desain ini membutuhkan waktu
beberapa hari, akan tetapi bisa semakin lebih lama, tergantung dari besar
kecilnya sistem yang dibuat. Pada selang waktu tersebut, user bisa memberikan
tanggapan akan sistem yang sudah dikembangkan untuk selanjutnya dilakukan
perbaikan-perbaikan. Dengan demikian proses pengembangan suatu sistem
membutuhkan waktu yang cepat.
Implementasi (Implementation)
Setelah desain dari sistem yang akan dibuat sudah disetujui
baik itu oleh user dan Analyst, maka pada tahap ini programmer mengembangkan
desain menjadi suatu program. Setelah program selesai baik itu sebagian maupun
secara keseluruhan, maka dilakukan proses pengujian terhadap program tersebut
apakah terdapat kesalahan atau tidak sebelum diaplikasikan pada suatu
organisasi. Pada saat ini maka user bisa memberikan tanggapan akan sistem yang
sudah dibuat serta persetujuan mengenai sistem tersebut. Adapun hal terpenting
adalah bahwa keterlibatan user sangat diperlukan supaya sistem yang
dikembangkan dapat memberikan kepuasan kepada user, dan di samping itu, sistem
yang lama tidak perlu dijalankan secara paralel dengan sistem yang baru.
1. Model RAD memerlukan sumber
daya yang cukup besar, terutama untuk proyek dengan skala besar
2. Model ini cocok untuk proyek
dengan skala besar.
3. Model RAD memerlukan komitmen yang
kuat antara pengembang dan pemesssan, bahkan keduanya bisa tergabung dalam 1
tim
4. kinerja dari perangkat lunak
yang dihasilkan dapat menjadi masalah manakala
kebutuhan-kebutuhan diawal proses tidak dapat dimodulkan, sehingga pendekatan dengan model ini
kurang bagus.
5. sisttem yang tidak bisa
dimodularisasi tidak cocok untuk model ini.
6. penghalusan dan penggabungan
dari beberapa tim di akhir proses sangat diperlukan dan ini memerlukan kerja
keras.
7. proyek bisa gagal karena waktu
yang disepakati tidak dipenuhi
8. risiko tekns yang tinggi juga
kurang cocok untuk model ini.
