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.
Metode Prototyping Dalam Pengembangan Sistem
Informasi
Proses pengembangan sistem seringkali menggunakan
pendekatan prototipe (prototyping). Metode
ini sangat baik digunakan untuk menyelesesaikan masalah kesalahpahaman antara user dan analis yang timbul akibat user tidak mampu mendefinisikan secara
jelas kebutuhannya (Mulyanto, 2009).
Prototyping
adalah pengembangan yang cepat dan pengujian terhadap model kerja (prototipe)
dari aplikasi baru melalui proses interaksi dan berulang-ulang yang biasa
digunakan ahli sistem informasi dan ahli bisnis. Prototyping disebut juga desain aplikasi cepat (rapid application design/RAD) karena menyederhanakan dan
mempercepat desain sistem (O'Brien, 2005).
Sebagian user
kesulitan mengungkapkan keinginannya untuk mendapatkan aplikasi yang sesuai
dengan kebutuhannya. Kesulitan ini yang perlu diselesaikan oleh analis dengan
memahami kebutuhan user dan
menerjemahkannya ke dalam bentuk model (prototipe). Model ini selanjutnya
diperbaiki secara terus menerus sampai sesuai dengan kebutuhan user.
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.
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. Gambar di bawah ini
mengilustrasikan proses pembuatan prototipe :
 |
Langkah-Langkah Prototyping
|
a. Analisis
Kebutuhan Sistem
Pembangunan sistem informasi memerlukan penyelidikan
dan analisis mengenai alasan timbulnya ide atau gagasan untuk membangun dan
mengembangkan sistem informasi. Analisis dilakukan untuk melihat berbagai
komponen yang dipakai sistem yang sedang berjalan meliputi hardware, software, jaringan dan sumber daya manusia. Analisis juga
mendokumentasikan aktivitas sistem informasi meliputi input, pemrosesan, output,
penyimpanan dan pengendalian (O'Brien, 2005).
Selanjutnya melakukan studi kelayakan (feasibility study) untuk merumuskan
informasi yang dibutuhkan pemakai akhir, kebutuhan sumber daya, biaya, manfaat
dan kelayakan proyek yang diusulkan (Mulyanto,
2009).
Analisis kebutuhan sistem sebagai bagian dari studi
awal bertujuan mengidentifikasi masalah dan kebutuhan spesifik sistem.
Kebutuhan spesifik sistem adalah spesifikasi mengenai hal-hal yang akan
dilakukan sistem ketika diimplementasikan
(Mulyanto, 2009).
Analisis kebutuhan sistem harus mendefinisikan
kebutuhan sistem yang spesifik antara lain :
1) Masukan
yang diperlukan sistem (input)
2)
Keluaran
yang dihasilkan (output)
3)
Operasi-operasi
yang dilakukan (proses)
4)
Sumber
data yang ditangani
5)
Pengendalian
(kontrol)
 |
Spesifikasi Kebutuhan Sistem
|
Tahap analisis kebutuhan sistem memerlukan evaluasi
untuk mengetahui kemampuan sistem dengan mendefinisikan apa yang seharusnya
dapat dilakukan oleh sistem tersebut kemudian menentukan kriteria yang harus
dipenuhi sistem. Beberapa kriteria yang harus dipenuhi adalah pencapaian
tujuan, kecepatan, biaya, kualitas informasi yang dihasilkan, efisiensi dan
produktivitas, ketelitian dan validitas dan kehandalan atau reliabilitas (Mulyanto, 2009).
b. Desain
Sistem
Analisis sistem (system
analysis) mendeskripsikan apa yang harus dilakukan sistem untuk memenuhi
kebutuhan informasi pemakai. Desain sistem
(system design) menentukan
bagaimana sistem akan memenuhi tujuan tersebut. Desain sistem terdiri dari
aktivitas desain yang menghasilkan spesifikasi fungsional. Desain sistem dapat
dipandang sebagai desain interface,
data dan proses dengan tujuan menghasilkan spesifikasi yang sesuai dengan
produk dan metode interface pemakai,
struktur database serta pemrosesan
dan prosedur pengendalian (Ioanna et al., 2007).
Desain sistem akan menghasilkan paket software prototipe, produk yang baik
sebaiknya mencakup tujuh bagian :
1)
Fitur
menu yang cepat dan mudah.
2)
Tampilan
input dan output.
3)
Laporan
yang mudah dicetak.
4)
Data dictionary
yang menyimpan informasi pada setiap field termasuk panjang field, pengeditan
dalam setiap laporan dan format field
yang digunakan.
5)
Database
dengan format dan kunci record yang
optimal.
6) Menampilkan
query online secara tepat ke data
yang tersimpan pada database.
7)
Struktur
yang sederhana dengan bahasa pemrograman yang mengizinkan pemakai melakukan
pemrosesan khusus, waktu kejadian, prosedur otomatis dan lain-lain.
c. Pengujian
Sistem
Paket software
prototipe diuji, diimplementasikan, dievaluasi dan dimodifikasi berulang-ulang
hingga dapat diterima pemakainya (O'Brien, 2005).
Pengujian sistem bertujuan menemukan kesalahan-kesalahan yang terjadi pada
sistem dan melakukan revisi sistem. Tahap ini penting untuk memastikan bahwa
sistem bebas dari kesalahan (Mulyanto, 2009).
Menurut Sommerville (2001)
pengujian sistem terdiri dari :
1)
Pengujian
unit untuk menguji komponen individual secara independen tanpa komponen sistem
yang lain untuk menjamin sistem operasi yang benar.
2)
Pengujian
modul yang terdiri dari komponen yang saling berhubungan.
3)
Pengujian
sub sistem yang terdiri dari beberapa modul yang telah diintegrasikan.
4)
Pengujian
sistem untuk menemukan kesalahan yang diakibatkan dari interaksi antara
subsistem dengan interfacenya serta
memvalidasi persyaratan fungsional dan non fungsional.
5)
Pengujian
penerimaan dengan data yang dientry
oleh pemakai dan bukan uji data simulasi.
6)
Dokumentasi
berupa pencatatan terhadap setiap langkah pekerjaan dari awal sampai akhir
pembuatan program.
Pengujian sistem informasi berbasis web dapat menggunakan teknik dan metode
pengujian perangkat lunak tradisional. Pengujian aplikasi web meliputi pengujian tautan, pengujian browser, pengujian usabilitas, pengujian muatan, tegangan dan
pengujian malar (Simarmata, 2009).
Penerimaan pengguna (user) terhadap sistem dapat dievaluasi dengan mengukur kepuasan user terhadap sistem yang diujikan.
Pengukuran kepuasan meliputi tampilan sistem, kesesuaian dengan kebutuhan user, kecepatan dan ketepatan sistem
untuk menghasilkan informasi yang diinginkan user. Ada beberapa model pengukuran kepuasan user terhadap sistem, diantaranya adalah Technology Acceptance Model (TAM), End User Computing (EUC)
Satisfaction, Task Technology Fit (TTF) Analysis dan Human Organizational Technology
(HOT) Fit Model.
Salah satu model pengukuran yang telah diterjemahkan
ke dalam beberapa bahasa berbeda dan tidak menunjukkan perbedaan hasil
pengukuran yang signifikan adalah End
User Computing (EUC) Satisfaction. Model ini menekankan kepuasan user terhadap aspek teknologi meliputi
aspek isi, keakuratan, format, waktu dan kemudahan penggunaan sistem (Chin
& Mathew, 2000).
d. Implementasi
Setelah prototipe diterima maka pada tahap ini
merupakan implementasi sistem yang siap dioperasikan dan selanjutnya terjadi
proses pembelajaran terhadap sistem baru dan membandingkannya dengan sistem
lama, evaluasi secara teknis dan operasional serta interaksi pengguna, sistem dan teknologi
informasi.
Perancangan sistem membutuhkan peralatan berupa alat
alat perancangan proses dan alat
perancangan data. Alat perancangan proses terdiri dari diagram aliran data dan
diagram arus sistem. Sedangkan alat perancangan data terdiri dari diagram
relasi entitas (entity relationship)
dan kamus data (data dictionary).
a. Diagram
Aliran Data
Diagram aliran data (data flow diagram/DFD) adalah sebuah alat dokumentasi grafik yang
menggunakan simbol-simbol untuk menjelaskan sebuah proses. Diagram ini
menunjukkan aliran proses seluruh sistem kepada pemakai dan dapat diatur
detailnya sesuai dengan kemampuan pemahaman pemakai. DFD terdiri dari tiga
elemen yaitu lingkungan, pemrosesan, aliran data dan penyimpanan data. Salah
satu keuntungan menggunakan DFD adalah memudahkan pemakai yang kurang menguasai
bidang komputer untuk mengerti sistem yang sedang akan dikerjakan (Ladjamudin, 2005).
b.Diagram
Arus Sistem
Diagram arus sistem (Sistem Flow chart) adalah peralatan yang digunakan untuk
menggambarkan proses sistem secara rinci untuk menggambarkan aliran sistem
informasi dan diagram arus sistem untuk menggambarkan aliran program .
c.Diagram
Relasi Entitas
Diagram relasi entitas menunjukkan antar entitas
satu dengan yang lain dan bentuk hubungannya sehingga data tergabung dalam satu
kesatuan yang terintegrasi .
d.Kamus
Data
Kamus data adalah penjelasan tertulis lengkap dari
data yang diisikan ke dalam database .
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.
4. Aplication generation
RAD mengasumsikan pemakaian teknik generasi
ke-empat. Selain menciptakan
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.
model waterfall dan pembangunan dalam waktu singkat
yang
dicapai dengan menerapkan :
1. Component based construction ( pemrograman
berbasis komponen ).
2. Penekanan pada penggunaan ulang (reuse) komponen
perangkat lunak yang
telah ada.
3. Pembangkitan kode program otomatis/semi otomatis.
4. Multiple team (banyak tim), tiap tim
menyelesaikan satu tugas yang selevel tapi
tidak sama. Banyaknya tim tergantung dari area dan
komplekstasnya sstem yang
dibangun.
Jika keutuhan yang diinginkan pada tahap analisa
kebutuhan telah lengkap dan jelas,
maka waktu yang dibutuhkan untuk menyelesakan secara
lengkap perangkat lunak yang
dibuat adalah berkisar 60 sampai 90 hari. Model RAD
hampr sama dengan model
waterfall, bedanya siklus pengembangan yang ditempuh
model in sangat pendek
dengan penerapan teknik yang cepat.
Sistem dibagi-bagi menjadi beberapa modul dan
dikerjakan beberapa tmm dalam waktu
yang hampir bersamaan dalam waktu yang sudah
ditentukan. Model in melibatkan
banyak tim, dan setiap tim mengerjakan tugas yang
selevel, namun berbeda. Sesuai
dengan pembagian modul sistem.
Kelebihan dan Kelemahan
Beberapa hal (kelebhan dan kekurangan) yang perlu
diperhatikan dalam implementasi
pengembangan menggunakan model RAD :
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.
