Kamis, 16 Oktober 2014

Proses Model-Rekayasa Perangkat Lunak

1.  The Waterfall Model
            Waterfall Model adalah sebuah metode pengembangan software yang bersifat sekuensial. Metode ini dikenalkan oleh Royce pada tahun 1970 dan pada saat itu disebut sebaga isi klus klasik dan sekarang ini lebih dikenal dengan sekuensial linier. Selain itu Model ini merupakan model yang paling banyak dipakai oleh para pengembang software. Inti dari metode waterfall adalah pengerjaan dari suatu system dilakukan secara berurutan atau secara linear. Jadi jika langkah satu belum dikerjakan maka tidak akan bisa melanjutkan kelangkah 2, 3 dan seterusnya.  Secara otomatis tahapan ke-3 akan bisa dilakukan jika tahap ke-1 dan ke-2 sudah dilakukan.
            Keterkaitan dan pengaruh antar tahap ini ada karena output sebuah tahap dalam Waterfall Model merupakan input bagi tahap berikutnya, dengan demikian  ketidak sempurnaan hasil pelaksanaan tahap sebelumnya adalah awal ketidak sempurnaan tahap berikutnya. Memperhatikan karakteristik ini, sangat penting bagi tim pengembang dan perusahaan untuk secara bersama-sama melakukan analisa kebutuhan dan desain system sesempurna mungkin sebelum masuk kedalam tahap penulisan kode program. Secara garis besar metode waterfall mempunyai langkah-langkah sebagai berikut :
·         Analisa
·         Design
·         Code dan Testing
·         Penerapan dan
·         Pemeliharaan
1. Analisa kebutuhan (Requirement Analysis)/(Requirements analysis and definition)
Langkah ini merupakan analisa terhadap kebutuhan sistem.Pengumpulan data dalam tahap ini bisa malakukan sebuah penelitian, wawancara atau study literatur.Seorang system analis akan menggali informasi sebanyak-banyaknya dari user sehingga akan tercipta sebuah system komputer yang bisa melakukan tugas-tugas yang diinginkan oleh user tersebut. Tahapan ini akan menghasilkan dokumen user requirement atau bisa dikatakan sebagai data yang berhubungan dengan keinginan user dalam pembuatan sistem. Dokumen inilah yang akan menjadi acuan system analis untuk menterjemahkan kedalam bahasa pemprogram.
2. Design sistem (System Design)
Proses desain akan menerjemahkan syarat kebutuhan kesebuah perancangan perangkat lunak yang dapat diperkirakan sebelum dibuat coding. Proses ini berfokus pada :struktur data, arsitektur perangkat lunak, representasi interface, dan detail (algoritma) prosedural. Tahapan ini akan menghasilkan dokumen yang disebut software requirment. Dokumen inilah yang akan digunakan programmer untuk melakukan aktivitas pembuatan sistemnya.
3. Coding & Testing/penulisan kode Program (Implementation)
Coding merupakan penerjemahan design dalam bahasa yang bisa dikenali oleh komputer.Dilakukan oleh programmer yang akan meterjemahkan transaksi yang diminta oleh user. Tahapan inilah yang merupakan tahapan secara nyata dalam mengerjakan suatu sistem.Dalam artian penggunaan computer akan dimaksimalkan dalam tahapan ini. Setelah pengkodean selesai maka akan dilakukan testing terhadap sistem yang telah dibuat tadi. Tujuan testing adalah menemukan kesalahan-kesalahan terhadap system tersebut dan kemudian bisa diperbaiki.
4. Penerapan / pengujian program (Integration & Testing)
Tahapan ini bisa dikatakan final dalam pembuatan sebuah sistem.Setelah melakukan analisa, design dan pengkodean maka sistem yang sudah jadiakan digunakan oleh user.
5. Pemeliharaan (Operation & Maintenance)
Perangkat lunak yang sudah disampaikan kepada pelanggan pasti akan mengalami perubahan. Perubahan tersebut bisa karena mengalami kesalahan karena perangkat lunak harus menyesuaikan dengan lingkungan (periperal atau system operasi baru) baru, atau karena pelanggan membutuhkan perkembangan fungsional.
A.    Keuntungan The Waterfall Model
ü  Kualitas dari sistem yang dihasilkan akan baik. Ini dikarenakan oleh pelaksanaannya secara bertahap. Sehingga tidak terfokus pada tahapan tertentu.
ü  Document pengembangan system sangat terorganisir, karena setiap fase harus terselesaikan dengan lengkap sebelum melangkah ke fase berikutnya. Jadi  setiap fase atau tahapan akan mempunyai dokumen tertentu.
ü  Metode ini masih lebih baik digunakan walaupun sudah tergolong kuno, daripada menggunakan pendekatan asal-asalan. Selain itu, metode ini juga masih masuk akal jika kebutuhan sudah diketahui dengan baik.
B.    Kelemahan The Waterfall Model
ü  Diperlukan majemen yang baik, karena proses pengembangan tidak dapat dilakukan secara berulang sebelum terjadinya suatu produk.
ü  Kesalahan kecil akan menjadi masalah besar jika tidak diketahui sejak awal pengembangan yang berakibat pada tahapan selanjutnya.
ü  Pelanggan sulit menyatakan kebutuhan secara eksplisit sehingga tidak dapat mengakomodasi ketidak pastian pada saat awal pengembangan.
ü  Pelanggan harus sabar, karena pembuatan perangkat lunak akan dimulai ketika tahap desain sudah selesai. Sedangkan pada tahap sebelum desain bisa memakan waktu yang lama.
ü  Pada kenyataannya, jarang mengikuti urutan sekuensial seperti pada teori. Iterasi sering terjadi menyebabkan masalah baru.

2.   The V-Model
      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:
a.      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.

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

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

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

e.      Coding
Dalam tahap ini dilakukan pemrograman terhadap setiap modul yang sudah dibentuk.

A.    Keuntungan V-Model
ü  Bahasa yang digunakan untuk merepresentasikan konsep V model menggunakan bahasa formal. Contoh : dengan menggunakan objek model ataupun frame-frame • Meminimalisasikan kesalahan pada hasil akhir karena ada test pada setiap prosesnya
ü  Penyesuaian yang cepat pada projek yang baru
ü  Memudahkan dalam pembuatan dokumen projek
ü  Biaya yang murah dalam perawatan dan modifikasinya
ü  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.

B.    Kerugian V-Model
ü  Aktifitas V-Model hanya difokuskan pada projectnya saja, bukan pada keseluruhan organisasi. V-Model adalah proses model yang hanya dikerjakan sekali selama project saja, bukan keseluruhan organisasi.
ü  Prosesnya hanya secara sementara. Ketika project selesai, jalannya proses model dihentikan. Tidak berlangsung untuk keseluruhan organisasi.
ü  Metode yang ditawarkan terbatas. Sehingga kita tidak memiliki cara pandang dari metode yang lain. Kita tidak memiliki kesempatan untuk mempertimbangkan jika ada tools lain yang lebih baik.
ü  Toolnya tidak selengkap yang dibicarakan. SDE (Software Development Environment).Tidak ada tools untuk hardware di V-Model. Tool yang dimaksud adalah “software yang mendukung pengembangan atau pemeliharaan / modifikasi dari system IT.
ü  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.

3.  Incremental Model 

      Incremental model adalah model pengembangan sistem pada software engineering berdasarkan requirement software yang dipecah menjadi beberapa fungsi atau bagian sehingga model pengembangannya secara bertahap. dilain pihak ada mengartikan model incremental sebagai  perbaikan dari model waterfall dan sebagai standar pendekatan topdown. Model ini memiliki tahapan tahapan untuk perancangan perangkat lunaknya, yaitu: 
  1. Requirement , Requirment adalah proses tahapan awal yang dilakukan pada incremental model adalah penentuan kebutuhan atau analisis kebutuhan.
  2. Specification, Specification adalah proses spesifikasi dimana menggunakan analisis kebutuhan sebagai acuannya.
  3. Architecture Design, adalah tahap selanjutnya, perancangan software yang terbuka agar dapat diterapkan sistem pembangunan per-bagian pada tahapan selanjutnya.
  4. Code setelah melakukan proses desain selanjutnya ada pengkodean.
  5. Test merupakan tahap pengujian dalam model ini. 
          Tahapan-tahapan tersebut dilakukan secara berurutan. Setiap bagian yang sudah selesai dilakukan testing, dikirim ke pemakai untuk langsung dapat digunakan. Pada incremental model, tiga tahapan awal harus diselesaikan terlebih dahulu sebelum sebelum tahap membangun tiap increment. Untuk mengantisipasi kondisi yang terjadi pada incremental model, diperkenalkan model More Risky Incremental Model. Model ini menerapkan sistem kerja yang paralel. Setelah daftar kebutuhan didapatkan dari pemakai, tim spesifikasi membuat spesifikasi untuk modul pertama. Setelah spesifikasi pertama selesai, tim desain menindak lanjuti. Tim spesifikasi sebelumnya juga langsung membuat spesifikasi untuk model kedua, dan seterusnya. Jadi, tidak harus menunggu modul pertama selesai hingga dikirim ke user.
  
1.    Kelebihan Model Incremental:
ü  Merupakan model dengan manajemen yang sederhana
ü  Pengguna tidak perlu menunggu sampai seluruh sistem dikirim untuk mengambil keuntungan dari sistem tersebut. Increment yang pertama sudah memenuhi persyaratan mereka yang paling kritis, sehingga perangkat lunak dapat segera digunakan.
ü  Resiko untuk kegagalan proyek secara keseluruhan lebih rendah. Walaupun masalah masih dapat ditemukan pada beberapa increment. Karena layanan dengan prioritas tertinggi diserahkan pertama dan increment berikutnya diintegrasikan dengannya, sangatlah penting bahwa layanan sistem yang paling penting mengalami pengujian yang ketat. Ini berarti bahwa pengguna akan memiliki kemungkinan kecil untuk memenuhi kegagalan perangkat lunak pada increment sistem yang paling bawah.
ü  Nilai penggunaan dapat ditentukan pada setiap increment sehingga fungsionalitas sistem disediakan lebih awal.
ü  Memiliki risiko lebih rendah terhadap keseluruhan pengembagan sistem,
ü  Prioritas tertinggi pada pelayanan sistem adalah yang paling diuji
2.    Kelemahan Model Incremental:
ü  kemungkinan tiap bagian tidak dapat diintegrasikan
ü  Dapat menjadi build and Fix Model, karena kemampuannya untuk selalu mendapat perubahan selama proses rekayasa berlangsung
ü  Harus Open Architecture
ü  Mungkin terjadi kesulitan untuk memetakan kebutuhan pengguna ke dalam rencana spesifikasi masing-masing hasil increment.

4.  Evolutionary Process Model: Prototype
Prototype model ini digunakan ketika user atau costumer telah mendefinisikan kebutuhan umumm namun belum bisa menyertakan fungsi dan fitur-fitur secara detail. Atau model ini dapat digunakan saat pengembang tidak yakin dengan efisiensi dari algoritma yang dibentuk.

A.    Kelebihan Prototype Model
ü  Jika menggunakan model ini maka dapat menghemat waktu pengembangan
ü  Akan terjalin komunikasi yang baik antara kostumer dan pengembang
ü  Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan pelanggan
ü  User mnegetahui apa yang diharapkan sehingga penerapan menjadi lebih mudah.
ü  Dalam pengembangan sistem user bisa berpartisipasi secara aktif.

B.    Kekurangan Prototype Model
ü  Proses analisa dan perancangan dalam prototype model terlalu singkat
ü  Biasanya kurang fleksible dalam mengahadapi perubahan
ü  Walaupun pemakai melihat berbagai perbaikan dari setiap versi prototype, tetapi pemakai mungkin tidak menyadari bahwa versi tersebut dibuat tanpa memperhatikan kualitas dan pemeliharaan jangka panjang
ü  Pengembang kadang-kadang membuat kompromi implementasi dengan menggunakan sistem operasi yang tidak relevan dan algoritma yang tidak efisien

5.  Evolutionary Process Model: Spiral
Spiral model merupakan gabungan antara prototype model dan waterfall model. Spiral model didefinisikan dalam aktivitas kerangka kerja oleh team software engineering.

A.    Kelebihan Model Spiral :
ü  Lebih cocok untuk pengembangan sistem dan perangkat lunak skala besar
ü  Pengembang dan pemakai dapat lebih mudah memahami dan bereaksi terhadap resiko setiap tingkat evolusi karena perangkat lunak terus bekerja selama proses

B.    Kekurangan Model Spiral :
ü Pada saat situasi kontrak akan sulit untuk meyakinkan costumer bahwa penggunaan pendekatan ini akan dapat dikendalikan
ü  Memerlukan tenaga ahli untuk memperkirakan resiko, dan harus mengandalkannya supaya sukses
ü  Model spiral ini merupakan model yang masih baru sehingga belum terbukri apakah model ini efisien atau tidak.

6.  The RAD model

            RAD (Rapid Application Development) adalah model proses yang juga termasuk dalam Incremental Proses Model karena pembangunan dari sistem perangkat lunak dikerjakan dengan tahapan yang terurut mulai dari dasar (awal) sampai tahap paling tinggi (proses akhir pembuatan), tetapi perbedaan nya model ini dibagi menjadi beberapa modul dan dikerjakan secara besama-sama dan sesuai dengan waktu yang ditentukan.

A.    Kelebihan RAD model :
ü  Pengerjaan sistem yang cepat (60 -90 hari)
ü  RAD dapat menggunakan kembali komponen yang ada (reusable object) sehingga  pengembang pengembang tidak perlu membuat dari awal lagi.
ü  Proses pengiriman menjadi lebih mudah karena proses pembuatan berupa potongan- potongan script

B.    Kekurangan RAD model :
ü  Tidak tepat untuk sistem yang berukuran besar.
ü  Pembuatan sistem bisa gagal jika waktu kesepakatan tidak terpenuhi (terlalu cepat atau  permintaan agar diselesaikan lebih cepat dari perjanjian).
ü  Mempunyai banyak resiko karena dikerjakan dalam modul yang berbeda dan dalam waktu  yang hampir bersamaan dan pada tempat yang belum tentu sama.


Tidak ada komentar:

Posting Komentar