Catatan Seorang Prajurit Kecil

Ikon

biarlah semua itu berjalan sesuai "skenario" NYA – jika kau telusuri, semua logika itu akan kau temukan

Rekayasa Perangkat Lunak – (Bagian 3)


Pada postingan sebelumnya saya sudah sharing pengertian mengenai rekayasa perangkat lunak, nah berikut ini saya akan sharing lagi sedikit mengenai Model dan Paradigma Rekayasa Perangkat Lunak, mungkin dalam tulisan kali ini terdapat banyak kesalahan dan/atau  perbedaan pendapat dari teman-teman, untuk itu saya mohon koreksi nya, demi kemajuan kita bersama…

oke langsung aja…

Seperti yang sudah penulis bahas pada Bab – 1 sebelumnya, bahwa banyak para pengembang perangkat lunak yang salam dalam memahami model dan paradigma, sehingga berdampak pada ambigu terhadap disiplin rekayasa perangkat lunak yang digunakan. Sebelum lebih jauh membahas model dan paradigma rekayasa perangkat lunak, penulis akan mengulangi sedikit penjelasan dasar mengeani model dan paradigma itu sendiri.

Model merupakan kerangka bagi jalur yang harus dilalui aktivitas-aktivias pengembangan perangkat lunak, sebagai contoh: waterfall, spiral, prototype dan lain sebagainya, sementara paradigma mengacu kepada cara pandang spesifik dalam usaha pencarian solusi, yaitu: menyagkut konseptualisasi permasalahan dan solusi, bukan berkaitan dengan urutan aktivitas penyelesaian.

Pada paper ini, penulis akan menjelaskan 4 (empat) model dasar yang sering digunakan dalam pengembangan prangkat lunak, yaitu:

  1. 1. Linear Sequential Model
  2. 2. Prototyping Model
  3. 3. Rapid Application Development (RAD) Model
  4. 4. Evolutionary Software Process Model

Dan 5 (lima) paradigma yang sering digunakan dalam pengembangan perangkat lunak, yaitu:

  1. Paradigma Konvensional
  2. Paradigma Berorientasi Objek
  3. Paradigma Metode Formal
  4. Paradigma Cleanroom
  5. Paradigma Berbasis Komponen

Sebelum lebih jauh dalam menjelaskan model dan paradigma diatas, penulis akan menjelaskan aktivitas dasar dalam pengembangan perangkat lunak, yaitu:

No Aktifitas Artifaks Keluaran
1 Analisis kebutuhan Studi Kelayakan

Kerangka Kebutuhan

2 Pendefinisian Kebutuhan Dokumen kebutuhan
3 Spesifikasi Sistem Spesifikasi Fungsi

Rencana Pengujian Penerimaan

Draft Buku Petunjuk Pemakaian

4 Perancangan Arsitektur Spesifikasi Arsitektur

Rencana Pengujian Sistem

5 Perancangan Antarmuka Spesifikasi Antarmuka

Rencana Pengujian Integrasi

6 Perancangan Rinci Spesifikasi Rancangan

Rencana Pengujian Unit

7 Pengkodean Kode Program
8 Pengujian Unit Laporan Pengujian Unit
9 Pengujian Modul Laporan Pengujian Modul
10 Pengujian Integrasi Laporan Pengujian Integrasi

Buku Petunjuk Pemakaian oleh Pemakai

11 Pengujian Sistem Laporan Pengujian Sistem
12 Pengujian Penerimaan Sistem akhir beserta dokumentasi

Table: Daftar Aktivitas Dasar Teknis Pengembangan Perangkat Lunak (diadopsi dari: Bambang Hariyanto, 2004)

Sedangkan jika kita mengacu kepada standar IEEE Computer Society (2004), aktifitas dasar dalam pengembangan perangkat lunak secara umum adalah sebagai berikut:

Gambar: Aktifitas dasar dalam pengembangan perangkat lunak (Diadopsi dari: SWEBOK 2004)

Berdasarkan kedua referensi mengenai aktifitas dasar dalam pengembangan perangkat lunak diatas, berikut ini akan penulis jelaskan kempat model pengembang perangkat, yaitu:

Linear Sequential Model,

Nama lain dari linear sequential model adalah waterfall yang merupakan model rekayasa perangkat lunak tertua. Dalam model ini terdapat seluruh aktivitas dasar dalam pengembangan perangkat lunak yang sudah penulis jelaskan diatas. Tahapan proses dari setiap aktivitas adalah secara berurutan, sebagai ilustrasi perhatikan gambar berikut:

Gambar: Model pengembangan perangkat lunak Linear Sequential (Waterfall)

Kelemahan dari model ini adalah:

  1. Kebanyakan proyek yang terjadi dilapangan tidak mengikuti alur sequen yang sudah ditetapkan, meskipun pengembang bisa melakukan iterasi terhadap proses, namun model melakukannya secara tidak langsung yang menyebabkan perubahan-perubahan yang terjadi sering membuat para tim pengembang mengalami kebingungan.
  2. User harus menyatakan kebutuhannya secara explisit pada saat awal proyek, dan hal ini hampir tidak mungkin dilakukan mengingat keterbatasan manusia dalam mengakomodir kemungkinan-kemungkinan yang akan terjadi dimasa yang akan datang.
  3. User harus memiliki kesabaran, karena versi yang dapat bekerja dari program tidak akan tersedia sebelum proyek diselesaikan.

Walaupun demikian, model ini mengakomodir semua aktifitas dasar yang terdapat dalam pengembangan perangkat lunak, sehingga bisa dijadikan acuan dasar dalam pengembangan perangkat lunak. Model-model yang lain adalah merupakan pengembangan dari model linear sequential.

Prototyping Model

Model ini diawali dengan penentuan kebutuhan oleh user. Pengembang akan mengumpulkan informasi-informasi mengenai kebutuhan user tersebut dan kemudian membuat sebuah prototype dari perangkat lunak yang akan dikembangkan. Model ini sangat cocok bagi user awam, sehingga dengan adanya prototype pemahaman mereka akan terbantu dan mereka mempunyai landasan dan acuan dalam tahapan selanjutnya, misalnya pada tahapan pengujian perangkat lunak.

McLeod dan Schell (2007) mendifiniskan 2 (dua) tipe dari prototype yaitu:

  1. 1. Evolutionary Prototype
  2. 2. Requirements Prototype

Evolutionary prototype yaitu, prototype yang secara terus menerus dikembangkan hingga prototype tersebut memenuhi fungsi dan prosedur yang dibutuhkan oleh sistem.  Berikut gambar dari tahapan evolutionary prototype:

Gambar: Evolutionary Prototyping Model.

  1. Analisis kebutuhan user, pengembang dan pengguna atau pemilik sistem melakukan diskusi dimana pengguna atau pemilik sistem menjelaskan kepada pengembang tentang kebutuhan sistem yang mereka inginkan.
  2. Membuat prototype, pengembang membuat prototype dari sistem yang telah dijelaskan oleh pengguna atau pemilik sistem.
  3. Menyesuaikan prototype dengan keinginan user, pengembang menanyakan kepada pengguna atau pemilik sistem tentang prototype yang sudah dibuat, apakah sesuai atau tidak dengan kebutuhan sistem.
  4. Menggunakan prototype, sistem mulai dikembangkan dengan prototype yang sudah dibuat.

Requirement prototype merupakan prototype yang dibuat oleh pengembang dengan mendifiniskan fungsi dan prosedur sistem dimana pengguna atau pemilik sistem tidak bisa mendefinisikan sistem tersebut. Berikut ini langkah-langkah dari requirement prototype :

Gambar: Requirement Prototype Model

  1. Analisis kebutuhan user, pengembang dan pengguna atau pemilik sistem melakukan diskusi dimana pengguna atau pemilik sistem menjelaskan kepada pengembang tentang kebutuhan sistem yang mereka inginkan.
  2. Membuat prototype, pengembang membuat prototype dari sistem yang telah dijelaskan oleh pengguna atau pemilik sistem.
  3. Menyesuaikan prototype dengan keinginan user, pengembang menanyakan kepada pengguna atau pemilik sistem tentang prototype yang sudah dibuat, apakah sesuai atau tidak dengan kebutuhan sistem.
  4. Membuat sistem baru, pengembang menggunakan prototype yang sudah dibuat untuk membuat sistem baru.
  5. Melakukan testing sistem, pengguna atau pemilik sistem melakukan uji coba terhadap sistem yang dikembangkan
  6. Menyesuaikan dengan keinginan user, sistem disesuaikan dengan keinginan user dan kebutuhan sistem, jika sudah sesuai sistem siap digunakan.
  7. Menggunakan sistem.

Kelebihan dari teknik pengembangan prototyping yaitu :

  1. Menghemat waktu pengembangan.
  2. Menghemat biaya pengembangan.
  3. Pengguna atau pemilik sistem ikut terlibat dalam pengembangan, sehingga kemungkinan-kemungkinan  terjadinya kesalahpahaman dalam sistem bisa diminimalisir.
  4. Implementasi akan menjadi mudah, karena pengguna atau pemilik sistem sudah mempunyai gambaran tentang sistem.
  5. Kualitas sistem yang dihasilkan baik.
  6. Memungkinan  tim pengembang sistem  memprediksi dan memperkirakan  pengembangan-pengembangan sistem selanjutnya.

Sedangkan kelemahannya adalah :

Pengguna atau pemilik sistem bisa terus menerus menambah kompleksitas sitem hingga sistem menjadi sangat kompleks, hal ini bisa menyebabkan pengembang meninggalkan pekerjaanya sehingga sistem yang dikerjaan tidak akan pernah terselesaikan.

Rapid Application Development (RAD) Model

Sistem yang semakin komplek dan waktu pengembangan yang dibutuhkan semakin cepat, membuat para pengembang sistem berfikir keras dan berusaha untuk mencari solusi teknik pengembangan yang cepat tanpa mengurangi kualitas sistem yang dihasilkan. Dengan kondisi ini, dikembangkanlah Rapid Aplication Development (RAD).

McLeod dan Schell (2007) berpendapat bahwa RAD merupakan metode yang memfokuskan pada kecepatan dalam pengembangan sistem untuk memenuhi kebutuhan pengguna atau pemilik sistem seperti prototyping namun mempunyai cangkupan yang lebih luas.

Nama RAD dikenalkan oleh James Martin pada tahun 1991, yang mengacu pada life cycle pengembangan sistem. RAD mengadopsi teknik waterfall dan prototyping yang menggunakan manajemen, metode dan tools yang cukup kompleks, selain itu pengembang yang menggunakan teknik ini harus merupakan pengembang yang professional, sehingga Martin memberikan istilah SWAT (skilled with advanced tools) Team untuk pengembang yang menggunakan sistem ini. Berikut ini ilustrasi RAD

Gambar: Rapid Application Development (RAD) Model

Yang membedakan antara antara waterfall dengan RAD adalah dimana pada teknik waterfall pengguna atau pemilik sistem akan ikut berpartisipasi dalam tahap cutover sedangkan pada RAD pada tahap construction. Hal ini menyebabkan tahap cutover akan lebih cepat dibandingkan pada waterfall, sedangkan urutan tahapan pada RAD sama dengan waterfall.

McLeod dan Schell (2007) mengatakan ada 4 (empat) komponen pada RAD yaitu

  1. Manajemen, yaitu orang-orang (dari sisi user) yang berada pada level manajemen yang mempunyai yang bisa beradaptasi dengan cepat untuk menggunakan metode baru.
  2. Pengembang, yaitu tim pengembang sistem yang professional dalam menggunakan metode-metode pengembangan sistem dan tools yang dibutuhkan. Tim ini di sebut oleh Martin sebagai SWAT (skilled with advanced tools) Team.
  3. Metode, yaitu metode RAD yang dikenal dengan RAD Life Cycle.
  4. Tools, yaitu Computer-Aided Software Engineering (CASE) dan 4th Generation Language yang bisa memfasilitasi untuk pembuatan prototype dan pembuatan kode program. Sedangkan CASE tools lebih kepada dokumentasi dan perancangan database.

Evolutionary Software Process Model

Model ini memungkinkan perulangan (iterasi) dari setiap tahapan pengembangan perangkat lunak. Dengan model ini kompleksitas perangkat lunak yang dihasilkan akan semakin bertambah untuk setiap iterasi. Model ini terdiri dari:

  1. Incremental model, yaitu: model yang mengkombinasikan linear sequential model dengan filosofi iteratif pada prototyping.
  2. Spiral model, yaitu: model yang menggabungkan sifat alami iterasi pada prototyping dengan aspek sistematik dan terkendali dari linear sequential model.
  3. WINWIN Spiral model, yaitu: model yang memungkinkan user dan pengembang melakukan komunikasi dalam tahap pengembangan, dimana bisa memberikan win-win solution, seperti user bisa mengemukakan sebagian besar dan/atau keseluruhan kebutuhannya sedangkan pengembang bisa mengembangkan perangkat lunak sesuai dengan kebutuhan user tersebut dalam cakupan waktu dan biaya yang sudah dispesifikasikan.
  4. Concurrent development model, yaitu: model yang biasa digunakan untuk mengembangkan perangkat lunak client server.

Bersambung…..

Filed under: Software Engineering, , , ,

One Response

  1. […] kali ini saya akan coba sharing kelanjutan dari tulisan sebelumnya, masih seputar rekayasa perangkat lunak, namun kali ini saya mencoba untuk membandingkan […]

Tinggalkan Balasan

Isikan data di bawah atau klik salah satu ikon untuk log in:

Logo WordPress.com

You are commenting using your WordPress.com account. Logout / Ubah )

Gambar Twitter

You are commenting using your Twitter account. Logout / Ubah )

Foto Facebook

You are commenting using your Facebook account. Logout / Ubah )

Foto Google+

You are commenting using your Google+ account. Logout / Ubah )

Connecting to %s

%d blogger menyukai ini: