Jumat, 28 April 2017

Model Sekuensial Linier



1.     Model Sekuensial Linier

Sekuensial linier, yang sering disebut juga classic life cycle atau waterfall model, menyampaikan suatu pendekatan yang berurutan untuk pengembangan perangkat lunak. Pengembangan dimulai dari perencanaan sistem (rekayasa sistem), analisa kebutuhan, desain, penulisan program, pengujian dan perawatan sistem. Sekuensial modeladalah paradigma tertua dalam rekayasa perangkat lunak. Namun, pada dua dekade terakhir dengan banyaknya kritik terhadap model proses initelah memunculkan keraguan dari para pengguna model ini mengenai kehandalan model proses ini
Ø Menggambarkan sekuensial linier untuk rekayasa perangkat lunak yang sering disebut juga dengan “siklus kehidupan klasik”atau”model air terjun”
Gambar Fase Lingkaran pemecahan masalah[RAC95]
Sekuensial linier mengusulkan sebuah pendekatan kepada perkembangan perangkat lunak yang sistematik dan sekuensial yang mulai pada tingkat kemajuan sistem pada seluruh analis,desain,kode,pengujian,model sekuensial linier.
2.     Model Prototipe
Ø Prototyping paradigma dimulai dengan pengumpulan kebutuhan.
Ø Secara ideal prototipe berfungsi sebagai sebuah mekanisme untuk mengidentifikasi kebutuhan perangkat lunak.
Ø Bila prototipe sedang bekerja atau dibangun,pengembang harus mempergunakan fragmen-fragmen  yang ada atau mengaplikasikan alat-alat bantu
Ø Contohnya:report generator,window manager,dll yang memungkinkan program yang bekerja untuk dimunculkan cecara cepat.
Ø Prototipe bisa berfungsi sebagai “sistem pertama”
Ø Prototipe bisa juga menjadi masalah karena alasan-alasan sebagai berikut:
1.     Pelanggan melihat apa yang tampak sebagai versi perangkat lunak yang bekerja tanpa melihat bahwa prototipe itu dijalankan bersama-sama tanpa melihat bahwa didalam permintaan untuk membjuatnya bekerja.
2.     Pengembang sering membuat kompromi-kompromi implementasi untuk membuat prototipe bekerja dengan cepat.Sistem operasi atau bahasa pemrograman yang tidak sesuai bisa dipakai secara sederhana karena mungkin diperoleh da dikenal .
Ø Prototyping dipakai bila ditemui kondisi
      Definisi user bersifat umum
      user tidak tahu pasti apa yang diinginkan
      definisi user bersifat tidak rinci
      user tidak tahu pasti apa & bagaimana bentuk
     masukan
     proses
     keluaran
      pengembang merasa tidak tahu pasti tentang
     pilihan algoritma yang akan  dipakai
     bagaimana lingkungan sistem yang akan dikembangkan
     bentuk, sifat & karakteristik antar-muka pemakai
      Terdapat ketidak pastian  dipihak user  yaitu tentang apa diinginkan
      Terdapat ketidak pastian  dipihak pengembang yaitu tentangapa yang harus dilakukan
http://www.whatsupnew.com/wp-content/uploads/prototyping-model-1.png
Contoh Gambar Model Proses Prototyping


3.     Model Rad
Rapid Aplication Development (RAD) adalah sebuah model proses perkembangan perangkat lunak sekuensial linier yang menekankan siklus perkembangan yang sangat pendek. Model RAD ini merupakan sebuah adaptasi “kecepatan tinggi” dari model sekuensial linier dimana perkembangan cepat dicapai dengan menggunakan pendekatan konstruksi berbasis komponen. Jika kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan menciptakan “system fungsional yang utuh” dalam periode waktu yang sangat pendek (kira-kira dalam waktu 60 – 90 hari).

Pendekatan RAD melingkupi fase – fase  sebagai berikut :
Ø Bussines modeling.
Aliran informasi diantara fungsi – fungsi bisnis dimodelkan dengan suatu cara untuk menjawab pertanyaan berikut : Informasi apa yang mengendalikan proses bisnis? Informasi apa yang dimunculkan? Siapa yang memunculkan? Kemana informasi itu pergi? Siapa yang memprosesnya?
Ø Data modeling.
Aliran informasi yang didefinisikan sebagai bagian dari fase Bussines modeling disaring kedalam serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut. Karakteristik (disebut atribut) masing – masing objek diidentifikasi dan hubungan antara objek – objek tersebut didefinisakan .
Ø Process modeling.
Aliran informasi yang didefinisikan didalam fase data modeling ditrnsformasikan untuk mencapai aliran informasi yang perlu bagi implementasi sebuah fungsi bisnis. Gambaran pemrosesan diciptakan untuk menambah, memodifikasi, menghapus, atau mendapatkan kembali sebuah objek data.
Ø Aplication generation.
RAD mengasumsikan pemakaian teknik generasi ke-empat (dalam pembahasan selanjutnya). Selain menghasilkan perangkat lunak dengan menggunakan bahasa pemrograman generasi ke-tiga yang konvensional, RAD lebih banyak memproses kerja untuk memakai lagi komponen program yang ada (pada saat memunkinkan) atau menciptakan komponen yang biasa dipakai lagi (bila perlu). Pada semua kasus, alat – alat Bantu otomatis dipakai untuk memfasilitasi konstruksi perangkat lunak.

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

Berikut kekurangan yang dimiliki RAD:
Ø  Bagi proyek yang besar tapi berskala, RAD memerlukan SDM yang memadai, untuk menciptakan jumlah tim RAD yang baik.
Ø  RAD menuntut pengembangan dan pelanggan memiliki komitmen di dalam aktifitas rapid-fire yang diperlukan untuk melengkapi sebuah system, didalam kerangka waktu yang sangat diperpendek. Jika komitmen tersebut tidak ada dari tiap konstituen, proyek RAD akan gagal.
Ø  Tidak semua aplikasi sesuai untuk RAD. Bila system tidak dapat dimodulasikan dengan teratur, pembangunan penting pada RAD akan sangat terganggu.


Gambar Model RAD

Dari gambar diatas, secara jelas batasan waktu yang dibebankan pada sebuah proyek RAD memerlukan “ruang lingkup yang bias diskala”. Jika sebuah aplikasi bisnis dapat dimodulkan dengan cara tertentu sehingga memungkinkan setiap fungsi mayor untuk dilengkapi dalam waktu kurang dari 3 bulan (dengan menggunakan pendekatan yang digambarkan diatas),maka aplikasi itu merupakan kandidat bagi RAD. Masing – masing fungsi mayor bias dibicarakan oleh suatu tim RAD yang terpisah, dan kemudian diintegrasikan untuk membentuk suatu keadaan.

4.     Model Inkremental (Pertambahan)

Model Inkremential menggabungkan elemen-elemen model sekuensial linier (diaplikasikan secara berulang) dengan filosofi iteratif. Seperti diperlihatkan dibawah, model pertambahan memakai urutan linier yang membingungkan, seiring dengan laju waktu kalender. Setiap urutan linier menghasilkan pertambahan, perangkat lunak “yang biasa disampaikan”. Pada saat model pertambahan dipergunakan, pertambahan pertama sering merupakan produk inti (care product), yaitu sebuah model pertambahan yang biasa dipergunakan, tetapi beberapa muka tambahan (beberapa diketahui dan beberapa tidak) tetap tidak disampaikan. Rencana pertambahan selanjutnya menekan modifikasi produk inti untuk secara lebih baik memenuhi kebutuhan para pelanggan dan penyampaian fitur serta fungsionalitas tambahan. Proses ini diulangi mengikuti penyampaian setiap pertambahan sampai menghasilkan produk yang lengkap.

Perkembangan pertambahan,khususnya berguna pada saat staffing tidak dapat dilakukan dengan menggunakan implementasi lengkap oleh batas waktu bisnis yang sudah disepakati oleh batas waktu tersebut. Jika produk ini diterima maka staff tambahan dapat ditambahkan untuk mengimplementasikan pertambahan selanjutnya. Sebagai tambahan, system mayor yang sedang dalam masa perkembangan serta waktu penyampaian belum pasti, mungkin membutuhkan keberadaan perangkat keras yang baru. Dapat juga membuat rencana tertentu untuk menghindari pemakaian perangkat lunak ini, sehingga memungkinkan fungsionalitas partai disampaikan kepada pemakai tanpa harus banyak tertunda.
Model Inkramental





















5.     Model Spiral

Model spiral yang pada awalnya diusulkan oleh Boehm, adalah model proses perangkat lunak yang evolusioner yang merngkai sifat iterative dari prototype dengan cara control dan aspek sistematisdari model sekuensial linier. Dalam model spiral, perangkat lunak dikembangkan dalam suatu penambahan.
Model spiral dibagi menjadi sejumlah aktifitas kerangka kerja, disebut juga wilayah luas, diantara tiga sampai enam wilayah luas :
Ø Komunikasi pelanggan : tugas – tugas yang dibutuhkan untuk membangun komunikas yang efektif diantara pengembangan dan pelanggan.
Ø Perencanaan : tugas – tugas yang dibutuhkan untuk mendefinisikan sumber daya, ketepatan waktu, dll.
Ø Analisis resiko : tugas yang dibutuhkan untuk menaksir resiko2, baik manajemen maupun teknis.
Ø Perekayasaan : tugas yang dibutuhkan untuk membangun satu atau lebih representasi dari aplikasi tersebut.
Ø Konstruksi dan peluncuran : tugas yang dibutuhkan untuk mengkonstruksi, menguji, memasang (install), dan memberi pelayanan kepada pemakai.
Ø Evaluasi pelanggan : tugas yang dibutuhkan untuk memperoleh umpan balik dari pelanggan.

Model spiral menjadi sebuah pendekatan yang realistis bagiperkembangan system dan perangkat lunak skala besar.karena perangkat lunak terus bekerja selama proses bergerak, pengembangan dan pemakai memahami dam bereaksi lebih baik terhadap resiko terhadap setiap evolusi. Tetapi model spiral bukanlah sebuah obat yang mujarab ,karena mode spiral membutuhkan keahlian penaksiran resiko yang masuk akal dan sangat bertumpu untuk mencapai keberhasilan.

Contoh Gambar Spiral
https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiHrEgSTU8qiI4P5JNemzIrnFbsl0je8bUOPl7Cs9BMk-AE4swntF5wTOJ3EogHWqTmrZNjh1RvaA1UFKvLks33iukjSSkUibNXRiTC4n5Fwffuq90o5mv9mBXniRqXUQYkh6KG3Ewkdsk/s320/spiral.png

6.     Model Rakitan Komponen

Model rakitan komponen menggabungkan karakteristik model spiral. Model ini bersifat evolusioner sehingga membutuhkan pendekatan iterative untuk menciptakan perangkat lunak. Tetapi model rakitan komponen merangkai aplikasi dari komponen perangkat lunak sebelum dipaketkan (biasa disebut “kelas”). Kelas2 yang diciptakan dalam proyek perangkat lunak disimpan didalam pustaka kelas atau tempat penyimpanan.
Model rakitan komponen membawa kepada pengguna kembali perangkat lunak, dan kegunaan kembali tersebut memberi sejumlah keuntungan yang bias diukur pada rekayasa perangkat lunak.

7.     Model Perkembangan Konkuren
Model perkembangan konkuren juga disebut rekayasa konkuren. Model proses yang konkuren dapat disajikan secara skematis sebagai sederetan aktivitas teknik mayor, tugas – tugas, dan keadaan yang lain. Contohnya aktivitas rekayasa yang dibatasi untuk model spiral dipenuhi dwengan melakukanprototyping, dan atau pemodelan analisis, spesifikasikebutuhan,dan rancangan
Elemen model proses konkuren



8.     Model Formal

Metode formal mencakup sekumpulan aktivitas yang membawa kepada spesifikasi matematis perangkat lunak computer. Metode ini mmemungkinkan perekayasa untuk mengkhususkan, mengembangkan, dan memverifikasi system berbasis computer dengan menggunakan system matematis yang tepat. Variasi dalam pendekatan ini disebut juga clean-room rekayasa perangkat lunak..
Meskipun belum menjadi pendekatan utama, metode ini sudah dapat menjanjikan perangkat lunak yang bebas dari cacat / kesalahan, tetapi perhatian tentang kemampuan aplikasinya sudah mulai disuarakan :
1.     Pengembangan model format banyak memakan waktu dan mahal.
2.     Perlu  latihan yang ekstensif.
3.     Sulit untuk menggunakan model2 sebagai sebuah mekanisme komunikasi bagi pemakai yang secara teknik belum canggih.

Meskipun demikian , sepertinya metode ini akan banyak penganutnya diantara pengembangan perangkat lunak yang harus membangun perangkat lunak yang kritis untuk keselamatan (misal perangkat medis, dan penerbangan pesawat), serta diantara pengembangan yang harus menderita karena factor ekonomis yang harus dialami oleh perangkat lunak.

9.     Teknik Generasi Keempat

Bentuk ini mencakup serangkaian Bantu perangkat lunak yang luas yang secara umum memiliki satu hal; masing – masing memungkinkan perekayasa perangkat lunak untuk mengkhususkan beberapa karakteristik perangkat lunak pada suatu tingkat yang tinggi. Alat – alat Bantu tersebut yang kemudian secara otomatis memunculkan kode sumber yang berdasarkan pada spesifikasi perekayasa.

Seperti semua paradigma rekayasa perangkat lunak yang lain, model ini juga memiliki keuntungan dan kerugian. Orang sepaham mempermasalahkan penghematan waktu, serta produktivitas yang dikembangkan secara baik oleh perekayasa perangkat lunak. Kelompok yang berlawanan mempermasalahkan alat Bantu yang tidak lebih mudah digunakan dari bahasa pemrograman, serta kemampuan pemeliharaan perangkat lunak yang dikembangkan masih mengandung pertanyaan.

Ada beberapa sisi baik dari kedua sisi permasalahan diatas :
1.     kegunaan metode ini telah disebarkan selama dekade terakhir dan sekarang merupakan pendekatan yang masih berjalan terus bagi area aplikasi yang berbeda.
2.     data yang dikumpulkan perusahaan – yang menggunakan metode ini menunjukkan bahwa waktu yang dibutuhkan untuk menghasilkan perangkat lunak sangat berkurang untuk aplikasi kecil dan menengah, serta jumlah desain analisis bagi aplikasi kecil juga berkurang.
3.     tetapi kegunaannya untuk pengembangan perangkat lunak yang besar membutuhkan analisis, desain dan pengujian yang sangat banyak(aktivitas RPL) untuk memperoleh penghematam waktu.

Kesimpulannya, teknik ini telah menjadi bagian yang penting dari perkembangan perangkat lunak. Bila dirangkai dengan pendekatan rakitan komponen, paradigma metode ini dapat menjadi pendekatan yang dominant untuk pengembangan perangkat lunak.



Tidak ada komentar:

Posting Komentar