Tahapan dalam Analisis Web Engineering

Rekayasa Web

Rekayasa web adalah proses yang diunakan untuk menciptakan aplikasi web yang berkualitas tinggi. Rekayasa web mengadaptasi rekayasa perangkat lunak dalam hal konsep dasar yang menekankan pada aktifitas teknis dan manajemen. Namun demikian adaptasi tidak secara utuh, tapi dengan perubahan dan penyesuaian. Rekayasa web gabungan antara web publishing (suatu konsep yang berasal dari printed publishing) dan aktifitas rekayasa perangkat lunak. Dikatakan demikian karena desain sebuah aplikasi web menekankan pada desain grafis, desain informasi, teori hypertext, desain sistem dan pemrograman.

Tahapan-tahapan dalam rekayasa web

Formulasi

Kegiatan yang berfungsi untuk merumuskan tujuan dan ukuran dari aplikasi berbasis web serta menentukan batasannya sistem. Beberapa pertanyaan berikut dapat membantu menentukan tujuan :

- Apa motivasi utama pembangunan WebApp?

- Mengapa WebApp diperlukan?

- Siapa yang akan menggunakan WebApp?

Ada dua macam tujuan:

- Informational goals

Menyediakan suatu informasi tertentu kepada pengguna, berupa teks, grafik, audio, dan video

- Applicative goals

Kemampuan untuk melakukan suatu fungsi yang dibutuhkan pengguna, misal dengan menggunakan aplikasi tersebut seorang dosen dapat memperoleh nilai akhir dan statistik nilai mahasiswa dari data-data ujian, tugas, kuis yang ia input ke dalam aplikasi

Perencanaan

Kegiatan yang digunakan untuk menghitung estimasi biaya proyek pembuatan aplikasi berbasis web ini, estimasi jumlah pengembang, estimasi waktu pengembangan, evaluasi resiko pengembangan proyek, dan mendefinisikan jadwal pengembangan untuk versi selanjutnya (jika diperlukan)

Analisis

Ada 4 tipe analisis dalam rekayasa web:

1. Content Analysis

Mengidentifikasi isi yang akan ditampilkan pada aplikasi berbasis web ini. Isi informasi dapat berupa teks, grafik, audio, maupun video

2. Interaction Analysis

Analisis yang menunjukkan hubungan antara web dengan pengguna

3. Functional Analysis

Menentukan operasi yang akan diaplikasikan pada WebApp dan termasuk di dalamnya fungsi-fungsi yang melakukan proses. Semua operasi dan fungsi dideskripsikan secara detil

4. Configuration Analysis

Konfigurasi yang digunakan pada aplikasi berbasis web, internet, intranet, atau extranet. Selain itu, analisis ini juga meliputi relasi database dengan web jika diperlukan

Desain Web

1. Architectural design: menggambarkan struktur WebApp
a. Struktur linier

- urutan interaksi sudah bisa dipastikan

- misal untuk presentasi tutorial, pemesanan produk yang harus mengikuti urutan tertentu

b. Struktur Grid:
    

- isi dapat dikatagorikan dalam 2 atau lebih dimensi

- misal: e-commerce menjual handphone. Horizontal adalah katagori berdasarkan feature hp, sedang vertikal adalah merek HP

c. Struktur jaringan:

- komponen pada struktur ini terhubung satu sama lain

- sekalipun bersifat fleksibel, struktur ini membingungkan user

d. Struktur Hirarki:

- struktur paling umum digunakan

- memungkinkan aliran secara horizontal selain jalur vertikal yang umum

- aliran secara horizontal juga bisa mengakibatkan kebingungan user

2. Navigation design: menentukan navigasi halaman-halaman web. Setelah arsitektur WebApp sudah terbentuk dan komponen-komponen seperti halaman, scripts, applet dan fungsi lain sudah ada, developer menentukan navigasi yang memungkinkan user mengakses isi WebApp dan layananlayanannya. Jika user tidak bisa berpindah ke halaman lain dalam web dengan mudah dan cepat maka mungkin karena grafik, dan isi tidak relevant, ini masalah navigasi.

Dalam desain navigasi beberapa hal perlu dilakukan :

- menentukan semantik (arti ) dari navigasi untuk user yang berbeda

- menentukan cara yang tepat: pilihannya adalah text-based links, icons, buttons and switches, dan graphical metaphors

3. Interface design: membangun interaksi dengan user yang konsisten dan efektif. User interface pada WebApp adalah kesan pertama. Sekalipun nilai isinya baik, kemampuan prosesnya canggih, layanannya lengkap namun jika user interfacenya buruk maka hal lain tidak berguna, karena akan membuat user

berpindah ke web lain. Beberapa petunjuk dalam merancang interface design :

- Server errors, menyebabkan user pindah ke website

- Membaca di layar monitor lebih lambat 25% dari pada di kertas, karena itu teks jangan terlalu banyak

- Hindari tanda “under construction”

- User tidak suka scroll. Pastikan informasi cukup dalam satu layar

- Navigasi menu dan headbar harus konsisten

- Keindahan tidak seharusnya lebih penting dari pada fungsinya

- Opsi navigasi harus jelas sehingga tahu bagaimana berpindah atau mencari hal lain pada halaman aktif

Pengujian pada Rekayasa web

1. Check isi/informasi untuk kesalahan yang mungkin terjadi, misalnya salah ketik

2. design model WebApp di- review untuk menemukan navigation errors

3. processing components an Web pages diuji

4. Integration test untuk arsitektur web :

- Struktur linier, grid, atau hirarki sederhana seperti pada software dengan pemrograman terstruktur (modular)

- Struktur hirarki campuran atau network (Web) seperti pada Object oriented software

5. Uji WebApp secara keseluruhan setelah disatukan semua komponennya secara lengkap

6. WebApp yang diimplementasikan pada konfigurasi yang berbeda diuji kompatibilitasnya. Misalnya jika membuat di IE, coba di Netscape, dan Firefox

7. WebApp diuji oleh sekelompok pengguna dengan kemampuan yang berbeda.Bagian yang diuji adalah isi, navigation, kemudahan penggunaan, kehandalan dan unjuk kerja

COUPLING

Coupling  adalah ketergantungan antar modul satu dengan modul lainnya. Jadi Coupling adalah sebuah ukuran untuk mengukur seberapa kuatnya sebuah element terhubung dengan element lain. Ukuran ini dipakai juga untuk mengetahui seberapa kuat informasi yang dimilikinya, atau ketergantungan ke element lain. Bayangkan jika anda mengubah 1 modul A tapi karena modul lain memiliki ketergantungan terhadap modul A, maka efek perubahan ini mungkin saja punya impact terhadap modul lain. Karena itu low coupling sangat penting dalam perancangan software.
Ada tiga kelompok besar coupling yaitu :
    1. Normal Coupling
    2. Common Coupling
    3. Content Coupling


Dalam konsep rancangan yang baik maka :
    - Normal Coupling adalah kopling yang baik dan dapat diterima
    - Common Coupling adalah kopling yang tidak dapat diterima
    - Content Coupling adalah kopling yang tidak boleh ada


Kopling yang termasuk di dalam kelompok Normal Coupling adalah :
    > Data Coupling
    > Stamp Coupling
    > Control Coupling


Dua modul dikatakan mempunyai Data Coupling bila saling berkomunikasi melalui parameter dan tiap parameternya adalah sebuah data elementer.
Dua modul dikatakan mempunyai Stamp Coupling bila saling berkomunikasi melalui  sekumpulan data yang terstruktur (record).
Dua modul dikatakan mempunyai Control Coupling bila sebuah modul mengirimkan informasi dengan tujuan mengontrol logika didalam modul yang lain.
Dua modul dikatakan mempunyai Common Coupling atau kadang disebut juga Global Coupling bila menggunakan struktur data yang ataupun elemen data yang berada pada sebuah area data global.
Dua modul dikatakan mempunyai Content Coupling atau kadang disebut juga Pathological Coupling bila dari dalam sebuah modul terdapat perintah yang langsung menunjuk kepada instruksi didalam modul lainnya.

Coupling dapat juga disebut dependency. Makna bebasnya adalah suatu ketergantungan yang dimiliki suatu class terhadap class yang lain. Batasan coupling dimulai dari "high coupling" hingga "low coupling". Disebut "no coupling" jika benar2 tidak ada ketergantungan antar class. Sebuah aplikasi dikatakan baik, jika modulnya bersifat low coupling.

Sebagai contoh , kita membuat class manusia. Lalu menciptakan variabel object dari class tangan, class badan, class kaki, dan class kepala. Setelah itu kita definisikan method tidur, makan, bicara, berjalan. Dapat terbayang untuk makan saja, kita harus mendeskripsikan aktivitas cuci tangan (yang dilakukan class tangan), proses makan (yang dilakukan class kepala), lalu kenyang (diekspresikan oleh class badan).

Hal diatas "high coupling", ketergantungan dengan class lain begitu tinggi. Dan sebaiknya, modul itu harus diubah menjadi "low coupling". Kenapa? salah satunya karena ini menyebabkan proses testing menjadi "tanggung", karena class manusia tergantung dengan class-class lain yang bisa saja isinya berubah. Ini menyebabkan class menjadi tidak reusable.

Bagaimana mengubahnya menjadi low coupling? Dengan membuat class-class anggota tubuh tadi menjadi interface, lalu biarkan class manusia mengimplementasi abstraksinya. Dengan demikian ini tidak akan mengganggu perubahan di masing2 sisi class.

Secara ga langsung class yang low coupling akan mengarahkan class berkarakter ‘high cohesion’. Vice versa.

ACTIVITY DIAGRAM

ACTIVITY DIAGRAM

•       Salah satu cara untuk memodelkan aliran kerja (workflow) dari business use case dalam bentuk grafik.

•    Diagram ini menunjukkan langkah-2 dalam aliran kerja, titik-titik keputusan dalam aliran kerja, siapa yang bertanggungjawab menyelesaikan masing-masing aktivitas dan objek-objek yang digunakan dalam aliran kerja.

FUNGSI ACTIVITY DIAGRAM

ž  Menggambarkan proses bisnis dan urutan aktivitas dalam sebuah proses

ž  Dipakai pada business modeling untuk memperlihatkan urutan aktifitas proses bisnis

ž  Struktur diagram ini mirip flowchart atau Data Flow Diagram pada perancangan terstruktur

ž Sangat bermanfaat apabila kita membuat diagram ini terlebih dahulu dalam memodelkan sebuah proses untuk membantu memahami proses secara keseluruhan

ž  Activity diagram dibuat berdasarkan sebuah atau beberapa use case pada use case diagram

ELEMEN2 ACTIVITY DIAGRAM

•      Swimlanes, menunjukkan siapa yang bertanggung jawab melakukan aktivitas dalam suatu diagram

•      Activities State, adalah kegiatan dalam aliran kerja

•   Action State, adalah langkah-langkah dalam sebuah activity. Action bisa terjadi saat memasuki activity, meningggalkan activity, saat di dalam activity, atau pada event yang spesifik

•      Business object, adalah entitas-entitas yang digunakan dalam aliran kerja

•      Transition, menunjukkan bagaimana aliran kerja itu berjalan dari satu aktivitas ke aktivitas lainnya

•      Decision point, menunjukkan dimana sebuah keputusan perlu dibuat dalam aliran kerja

•     Syncronization, menunjukkan dua atau lebih langkah dalam aliran kerja berjalan secara serentak à Fork dan Join

•      Start state, menunjukkan dimana aliran kerja itu dimulai

•      End state, menunjukkan dimana aliran kerja itu berakhir

SIMBOL-SIMBOL ACTIVITY DIAGRAM

CONTOH ACTIVITY DIAGRAM 

       

Activity Diagram

Activity diagrams menggambarkan berbagai alir aktivitas dalam sistem yang sedang dirancang, bagaimana masing-masing alir berawal, decision yang mungkin terjadi, dan bagaimana mereka berakhir. Activity diagram juga dapat menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi.
Activity diagram merupakan state diagram khusus, di mana sebagian besar state adalah action dansebagian besar transisi di-trigger oleh selesainya state sebelumnya (internal processing). Oleh karena itu activity diagram tidak menggambarkan behaviour internal sebuah sistem (dan interaksi antar subsistem) secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur aktivitas dari level atas secara umum.
Sebuah aktivitas dapat direalisasikan oleh satu use case atau lebih. Aktivitas menggambarkan proses yang berjalan, sementara use case menggambarkan bagaimana aktor menggunakan sistem untuk melakukan aktivitas.

Fungsi :
1. Menggambarkan proses bisnis dan urutan aktivitas dalam sebuah proses
2 .Menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi.
3. Sangat bermanfaat apabila kita membuat diagram ini terlebih dahulu dalam memodelkan sebuah proses untuk membantu memahami proses secara keseluruhan

contoh:

ACTIVITY DIAGRAM

Diagram ini menunjukkan langkah-2 dalam aliran kerja, titik-titik keputusan dalam aliran kerja, siapa yang bertanggungjawab menyelesaikan masing-masing aktivitas dan objek-objek yang digunakan dalam aliran kerja.state diagram khusus, dimana sebagian besar state adalah actiondan sebagian besar transisi di trigger oleh selesainya state sebelumnya.
Activity diagram dapat dibagi menjadi beberapa object swimlanes untuk menggambarkan objek mana yang bertanggung jawab untuk aktifitas tertentu.

Activity diagram menggambarkan alur kerja sistem perilaku. Activity diagram yang mirip dengan diagram negara kegiatan karena menggambarkan keadaan kegiatan dengan menunjukkan urutan kegiatan yang dilakukan. Activity diagram dapat menunjukkan kegiatan yang bersyarat atau paralel. Activity diagram harus digunakan dalam hubungannya dengan teknik model lain seperti interaksi diagram. 

Alasan utama untuk menggunakan diagram activity diagram unutk memodelkan alur kerja di belakang sistem yang di rancang. Activity diagram juga berguna untuk menganalisis sebuah kasus penggunaan dengan menggambarkan tindakan apa yang perlu dilakukan dan kapan mereka harus terjadi.

Elemen dari activity diagram :

•Swimlanes, menunjukkan siapa yang bertanggung jawab melakukan aktivitas dalam suatu diagram

•Activities State, adalah kegiatan dalam aliran kerja

•Action State, adalah langkah-langkah dalam sebuah activity. Action bisa terjadi saat
memasuki activity, meningggalkan activity, saat di dalam activity, atau pada event yang
spesifik

•Business object, adalah entitas-entitas yang digunakan dalam aliran kerja

•Transition, menunjukkan bagaimana aliran kerja itu berjalan dari satu aktivitas ke
aktivitas lainnya

•Decision point, menunjukkan dimana sebuah keputusan perlu dibuat dalam aliran kerja

•Syncronization, menunjukkan dua atau lebih langkah dalam aliran kerja berjalan secara
serentak à Fork dan Join

•Start state, menunjukkan dimana aliran kerja itu dimulai

•End state, menunjukkan dimana aliran kerja itu berakhir

       RAD

      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 .

Model RAD mengadopsi model waterfall dan pembangunan dalam waktu singkat yang dicapai dengan menerapkan :

1.     Component based construction ( pemrograman berbasis komponen bukan prosedural).

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 kompleksitasnya sistem yang dibangun.

Jika keutuhan yang diinginkan pada tahap analisis kebutuhan telah lengkap dan jelas, maka waktu yang dibutuhkan untuk menyelesaikan secara lengkap perangkat lunak yang dibuat adalah berkisar 60 sampai 90 hari. Model RAD hampir sama dengan model waterfall, bedanya siklus pengembangan yang ditempuh model ini sangat pendek dengan penerapan teknik yang cepat.

Sistem dibagi-bagi menjadi beberapa modul dan dikerjakan beberapa tim dalam waktu yang hampir bersamaan dalam waktu yang sudah ditentukan. Model ini melibatkan banyak tim, dan setiap tim mengerjakan tugas yang selevel, namun berbeda. Sesuai dengan pembagian modul sistem.

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.     Sistem 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 teknis yang tinggi juga kurang cocok untuk model ini.

ABSTRAK: Rapid Application Development (RAD) sebagai salah satu alternatif dari System

Development Life Cycle belakangan ini seringkali digunakan untuk mengatasi keterlambatan yang terjadi apabila menggunakan metode konvensional. Adapun keunggulan yang bisa didapatkan dengan menggunakan metode ini adalah kecepatan, ketepatan, dan biaya yang relatif lebih rendah dibanding dengan metode konvensional. Di samping itu dengan melibatkan user pada proses desain menyebabkan kebutuhan user dapat terpenuhi dengan baik dan secara otomatis kepuasan user sebagai pengguna sistem semakin meningkat. Akan tetapi di dalam menggunakan metode Rapid Aplication Development perlu untuk memperhatikan hal-hal yang penting, terutama kesiapan tim, ruang lingkup sistem, kebutuhan user, dan kinerja sistem. Pada akhirnya, sebagai salah satu alternatif dari System Development Life Cycle, maka Rapid Aplication Development dapat dijadikan acuan untuk menghasilkan sistem informasi yang dapat memenuhi kebutuhan user.

Kata kunci: Rapid Application Development (RAD), System Development life Cycle (SDLC).

ABSTRACT: Rapid Application Development is one of the alternatives of System Development

Life Cycle which is lately used to cope with the “slowness” of the conventional method. The

Strength of using this method is the speed, accuracy and relatively lower cost than the conventional method. Moreover, the user’s needs can be fulfilled well by involving the user in the design process. As a result, the user’s satisfaction will increase. However, there are several things that should be considered in using the Rapid Application Development such as the team’s preparation, the system territory, user’s needs, and system operation. Finally, as one of the alternatives of System Development Life Cycle, Rapid Application Development can be used as the fundamental to produce an information system which is able to fulfill the user’s needs.

Keywords: Rapid Application Development (RAD), System Development life Cycle (SDLC).

1. LATANG BELAKANG

Rapid Application Development (RAD)

adalah salah satu metode pengembangan suatu sistem informasi dengan waktu yang relatif singkat. Untuk pengembangan suatu sistem informasi yang normal membutuhkan waktu minimal 180 hari, akan tetapi dengan menggunakan metode RAD suatu sistem dapat diselesaikan hanya dalam waktu 30-90 hari.

Tujuan utama dari semua metode sistem development adalah memberikan suatu sistem yang dapat memenuhi harapan dari para pemakai, akan tetapi sering kali di dalam melakukan pengembangan suatu sistem tidak melibatkan para pemakai sistem secara langsung, sehingga hal ini menyebabkan sistem informasi yang dibuat jauh dari harapan pemakai yang dapat berakibat sistem tersebut walaupun dapat diterima tetapi para pemakai enggan untuk menggunakannya atau bahkan para pemakai menolak untuk menggunakannya.

Pada saat RAD diimplementasikan, maka para pemakai bisa menjadi bagian dari keseluruhan proses pengembangan sistem dengan bertindak sebagai pengambil keputusan pada setiap tahapan pengembangan.

RAD bisa menghasilkan suatu sistem dengan cepat karena sistem yang dikembangkan dapat memenuhi keinginan dari para pemakai sehingga dapat mengurangi waktu untuk pengembangan ulang setelah tahap implementasi.

2. KELEMAHAN-KELEMAHAN METODE KONVENSIONAL

Adapun kelemahan-kelemahan yang terdapat pada metode konvensional adalah sebagai berikut:

- Dengan metode konvensional, maka terdapat batas waktu yang cukup lama mulai dari pembuatan sistem sampai dengan konsumen dapat menggunakan sistem tersebut.

- Dengan metode konvensional, apabila proses pengembangan suatu sistem membutuhkan waktu yang lama maka kebutuhan konsumen pada sistem akan mengalami perubahan seiring dengan perubahan proses bisnis yang dilakukan oleh konsumen.

- Dengan metode konvensional, sistem yang dikembangkan tidak akan mempunyai manfaat apabila belum diselesaikan seluruhnya.

3. ALASAN MEMILIH METODE RAD

Di dalam memilih metode RAD harus memperhatikan alasan-alasan berikut ini:

3.1 Alasan yang Buruk

- Apabila menggunakan RAD hanya untuk menghemat biaya pengembangan suatu sistem. Hal ini disebabkan karena dengan menggunakan metode RAD membutuhkan suatu tim yang mengerti betul mengenai manajemen biaya. Sebab bila tidak, maka biaya yang dikeluarkan akan menjadi lebih besar.

- Apabila menggunakan RAD hanya untuk menghemat waktu pengembangan suatu sistem. Hal ini disebabkan karena dengan menggunakan metode RAD membutuhkan suatu tim yang mengerti betul mengenai manajemen waktu. Sebab bila tidak maka waktu yang dibutuhkan akan menjadi lebih lama.

3.2 Alasan yang Baik

- Apabila menggunakan RAD untuk mendapatkan suatu desain yang dapat diterima oleh konsumen dan dapat dikembangkan dengan mudah.

- Apabila menggunakan RAD untuk memberikan batasan-batasan pada suatu sistem supaya tidak mengalami perubahan.

- Apabila menggunakan RAD untuk menghemat waktu, dan kalau memungkinkan bisa menghemat biaya serta menghasilkan produk yang berkualitas.

4. SCHEDULE vs EKONOMI vs KUALITAS PRODUK

Ada beberapa hal yang perlu diperhatikan di dalam mengembangkan suatu sistem dengan menggunakan metode RAD dengan berdasarkan pada schedule, ekonomi dan kualitas produk antara lain model pengembangan, negosiasi, dan tujuan.

4.1 Model Pengembangan

Pada saat mengembangkan suatu sistem pasti dihadapkan dengan 3 pilihan model yaitu:

- Efficient Development (model pengembangan yang mengutamakan schedule, ekonomi dan kualitas produk secara seimbang).

· Schedule àlebih cepat dari rata-rata

· Ekonomi àbiaya lebih murah dari rata-rata

· Produk àlebih baik daripada kualitas rata-rata

- Sensible RAD (model pengembangan yang mengutamakan schedule dibandingkan dengan ekonomi dan kualitas produk).

· Schedule àlebih cepat dari rata-rata

· Ekonomi àbiaya lebih murah sedikit dari rata-rata

· Produk àlebih baik sedikit dari kualitas rata-rata

- All-out RAD (model pengembangan yang mengutamakan schedule dengan mengorbankan ekonomi dan kualitas produk).

· Schedule àpaling cepat

· Ekonomi àbiaya lebih mahal dari rata-rata

· Produk àlebih buruk dari kualitas rata-rata

4.2 Negosiasi

Untuk menghasilkan suatu sistem yang sesuai dengan kebutuhan dan keinginan user maka perlu melakukan suatu negosiasi dan bukan hanya lebih mementingkan schedule.

- RAD dapat dilakukan dengan cukup sukses apabila konsumen mampu melakukan negosiasi untuk menentukan ekonomi atau kualitas dari suatu sistem.

- RAD bisa memperoleh kesuksesan yang lebih baik apabila konsumen mampu melakukan negosiasi untuk menentukan ekonomi dan kualitas dari suatu sistem.

- Akan tetapi hal yang perlu diperhatikan adalah bahwa yang dimaksud negosiasi mengenai kualitas adalah bukan berarti konsumen bisa menerima kesalahan yang semakin banyak, tetapi yang dimaksud negosiasi adalah produk yang diterima mempunyai kekurangan baik itu pada penggunaan, kelengkapan fasilitas atau kurang efisien.

4.3 Tujuan

Dengan menggunakan RAD maka ada satu atau beberapa tujuan berikut ini yang tidak akan dapat dicapai secara bersamasama yaitu:

- Kemungkinan terjadi kesalahan yang kecil, karena pihak pengembang tidak mempunyai hak untuk mengubah komponen- komponen yang digunakan dalam mengembangkan suatu sistem.

- Tingkat kepuasan konsumen yang tertinggi, karena kebutuhan-kebutuhan sekunder dari konsumen harus dikorbankan supaya suatu sistem dapat diselesaikan sesuai jadwal.

- Biaya pengembangan yang termurah, karena dengan menggunakan komponen yang sudah ada dapat menyebabkan biaya yang lebih besar apabila dibandingkan dengan mengembangkan komponen sendiri.

5. TAHAPAN-TAHAPAN PADA RAD

Metode RAD mempunyai 3 tahapan utama seperti yang terlihat pada gambar 1.

Gambar 1. Tahapan RAD

5.1 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.

5.2 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.

5.3 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.

5.4 Tahapan keseluruhan

Dengan berdasarkan pada tahapantahapan tersebut di atas maka proses utama pengembangan suatu sistem dengan menggunakan metode RAD adalah sebagai berikut :

- Pengembang membuat prototype berdasarkan kebutuhan-kebutuhan yang sudah didefinisikan sebelumnya

- Desainer melakukan penilaian terhadap prototype

- User melakukan uji coba pada prototype dan memberikan masukan mengenai kebutuhan-kebutuhan yang kurang.

- User dan developer melakukan pertemuan untuk memberikan penilaian terhadap produk secara bersama-sama, menyesuaikan kebutuhan serta memberikan komentar apabila diperlukan perubahan.

- Semua kebutuhan akan sistem dan perubahan-perubahan yang terjadi dilakukan proses “timeboxed” dengan mempunyai

2 kemungkinan :

· Perubahan yang tidak dapat ditampung seperti yang sudah direncanakan harus dihilangkan.

· Jika diperlukan, kebutuhan-kebutuhan yang bersifat sekunder ditiadakan.

6. KONDISI-KONDISI YANG MEMPENGARUHI RAD

Pada saat akan menggunakan metode RAD perlu memperhatikan kondisi-kondisi yang bisa menunjang dan menghambat keberhasilan dari suatu sistem.

6.1 Kondisi Penunjang

Beberapa kondisi yang dapat menunjang keberhasilan dari RAD adalah sebagai berikut :

- Sistem berjalan sendiri (standalone).

- Kinerja dari sistem bukan faktor terpenting.

- Distribusi produk yang bersifat sempit.

- Ruang lingkup yang terbatas.

- Kehandalan dari sistem bukan faktor terpenting.

- Membutuhkan teknologi yang tidak terlalu baru (lebih dari 1 tahun).

- Sistem dapat dipecah-pecah menjadi bagian-bagian yang lebih kecil.

6.2 Kondisi Penghambat

Beberapa kondisi yang dapat menghambat keberhasilan dari RAD adalah sebagai berikut :

- Sistem harus dapat berjalan secara bersamaan dengan sistem yang lama.

- Komponen-komponen penunjang sangat langka untuk didapatkan.

- Kinerja yang optimal merupakan faktor terpenting.

- Distribusi produk yang bersifat luas.

- Ruang lingkup yang luas.

- Apabila digunakan untuk membuat Sistem Operasi, dimana membutuhkan sistem yang handal.

- Sistem tidak dapat dipecah-pecah menjadi bagian-bagian yang lebih kecil.

7. KEUNTUNGAN DAN KERUGIAN RAD

Dalam menggunakan RAD ada beberapa hal yang perlu diperhatikan terutama berkaitan dengan keuntungan dan kerugian.

7.1 Keuntungan RAD

Beberapa keuntungan dalam menggunakan metode RAD adalah sebagai berikut:

- Membeli sistem yang baru memungkinkan untuk lebih menghemat biaya ketimbang mengembangkan sendiri.

- Proses pengiriman menjadi lebih mudah, hal ini dikarenakan proses pembuatan lebih banyak menggunakan potonganpotongan script.

- Mudah untuk diamati karena menggunakan model prototype, sehingga user lebih mengerti akan sistem yang dikembangkan.

- Lebih fleksibel karena pengembang dapat melakukan proses desain ulang pada saat yang bersamaan.

- Bisa mengurangi penulisan kode yang kompleks karena menggunakan wizard.

- Keterlibatan user semakin meningkat karena merupakan bagian dari tim secara keseluruhan.

- Mampu meminimalkan kesalahan-kesalahan dengan menggunakan alat-alat bantuan (CASE tools).

- Mempercepat waktu pengembangan sistem secara keseluruhan karena cenderung mengabaikan kualitas.

- Tampilan yang lebih standar dan nyaman dengan bantuan software-software pendukung.

7.2 Kerugian RAD

Beberapa kerugian dalam menggunakan metode RAD adalah sebagai berikut :

- Dengan melakukan pembelian belum tentu bisa menghemat biaya dibandingkan dengan mengembangkan sendiri.

- Membutuhkan biaya tersendiri untuk membeli peralatan-peralatan penunjang seperti misalnya software dan hardware.

- Kesulitan melakukan pengukuran mengenai kemajuan proses.

- Kurang efisien karena apabila melakukan pengkodean dengan menggunakan tangan bisa lebih efisien.

- Ketelitian menjadi berkurang karena tidak menggunakan metode yang formal dalam melakukan pengkodean.

- Lebih banyak terjadi kesalahan apabila hanya mengutamakan kecepatan dibandingkan dengan biaya dan kualitas.

- Fasilitas-fasilitas banyak yang dikurangi karena terbatasnya waktu yang tersedia.

- Sistem sulit diaplikasikan di tempat yang

lain.

- Fasilitas yang tidak perlu terkadang harus disertakan, karena menggunakan komponen yang sudah jadi, sehingga hal ini membuat biaya semakin meningkat karena harga komponen yang lebih lengkap semakin mahal.

8. KESIMPULAN

Berdasarkan pembahasan di atas, maka di dalam menggunakan metode RAD dapat disimpulkan sebagai berikut:

- Penggunaan RAD harus digunakan secara tepat, sebab bila tidak maka akan menimbulkan kerugian-kerugian seperti misalnya biaya yang semakin membengkak dan waktu yang semakin lama.

- Penggunaan metode RAD harus digunakan dengan mempertimbangkan aspek waktu dan biaya secara seimbang, tidak bisa diprioritaskan satu per satu.

- Sebagai salah satu alternatif dari SDLC maka RAD dapat dijadikan acuan untuk Mengembangkan suatu sistem informasi yang unggul dalam hal kecepatan, ketepatan dan biaya yang lebih rendah.

- Dengan menggunakan RAD, maka keterlibatan user menjadi semakin meningkat yang pada akhirnya dapat meningkatkan kepuasan user terhadap sistem yang dikembangkan.

DAFTAR PUSTAKA

Jeffrey A. Hoffer, Joey F. George, Joseph S. Valacich. Modern Systems Analysis and Design Second Edition. Addison-Wesley. 1997.

Jeffrey L. Whitten, Lonnie D. Bentley, Kevin C. Dittman. Systems Analysis and Design Methods. McGraw-Hill. 2001.

Kendal & Kendal. Systems Analysis and Design Fifth Edition. Prentice-Hall International, Inc. 2002.

Ramez El Masri, Shamkant B. Navache. Fundamental of Database Systems. The Benjamin/Cummings Publishing Company, Inc. 1994.

Raymond McLeod, George Schell. Management Information Systems 8/e. Prentice-Hall, Inc. 2001.