P. 1
Metode Pengembangan Sistem

Metode Pengembangan Sistem

4.0

|Views: 4,851|Likes:
Published by Rangga Permana
Tugas Mata Kuliah Rekayasa Perangkat Lunak, Isi : Metode Pengembangan Sistem meliputi: Prototype, Rad, SDLC /Waterfall, Incremental dan Spiral
Tugas Mata Kuliah Rekayasa Perangkat Lunak, Isi : Metode Pengembangan Sistem meliputi: Prototype, Rad, SDLC /Waterfall, Incremental dan Spiral

More info:

Published by: Rangga Permana on Nov 04, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less

06/19/2013

pdf

text

original

METODE PENGEMBANGAN SISTEM/SOFTWARE 1.

METODE PROTOTYPE Prototyping merupakan salah satu metode pengembangan perangat lunak yang banyak digunakan. Dengan metode prototyping ini pengembang dan pelanggan dapat saling berinteraksi selama proses pembuatan sistem. Sering terjadi seorang pelanggan hanya mendefinisikan secara umum apa yang dikehendakinya tanpa menyebutkan secara detal output apa saja yang dibutuhkan, pemrosesan dan data-data apa saja yang dibutuhkan. Sebaliknya disisi pengembang kurang memperhatikan efesiensi algoritma, kemampuan sistem operasi dan interface yang menghubungkan manusia dan komputer. Untuk mengatasi ketidakserasian antara pelanggan dan pengembang , maka harus dibutuhkan kerjasama yanga baik diantara keduanya sehingga pengembang akan mengetahui dengan benar apa yang diinginkan pelanggan dengan tidak mengesampingkan segi-segi teknis dan pelanggan sistem akan yang mengetahui diinginkan. proses-proses demikian dalam akan menyelasaikan telah ditentukan. Kunci agar model prototype ini berhasil dengan baik adalah dengan mendefinisikan aturan-aturan main pada saat awal, yaitu pelanggan dan pengembang harus setuju bahwa prototype dibangun untuk mendefinisikan kebutuhan. Prototype akan dihilangkan sebagian atau seluruhnya dan perangkat lunak aktual aktual direkayasa dengan kualitas dan implementasi yang sudah ditentukan Tahapan-Tahapan Prototyping Tahapan-tahapan dalam Prototyping adalah sebagai berikut: 1. Pengumpulan kebutuhan Pelanggan dan pengembang bersamaDengan

menghasilkan sistem sesuai dengan jadwal waktu penyelesaian yang

sama

mendefinisikan

format

seluruh

perangkat

lunak,

mengidentifikasikan semua kebutuhan, dan garis besar sistem yang

akan dibuat. 2. Membangun prototyping Membangun prototyping dengan membuat perancangan sementara yang berfokus pada penyajian kepada pelanggan (misalnya dengan membuat input dan format output) 3. Evaluasi protoptyping Evaluasi ini dilakukan oleh pelanggan apakah prototyping yang sudah dibangun sudah sesuai dengan keinginann pelanggan. Jika sudah sesuai maka langkah 4 akan diambil. Jika tidak prototyping direvisi dengan mengulangu langkah 1, 2 , dan 3. 4. Mengkodekan sistem Dalam tahap ini prototyping yang sudah di sepakati diterjemahkan ke dalam bahasa pemrograman yang sesuai 5. Menguji sistem Setelah sistem sudah menjadi suatu perangkat lunak yang siap pakai, harus dites dahulu sebelum digunakan. Pengujian ini dilakukan dengan White Box, Black Box, Basis Path, pengujian arsitektur dan lain-lain 6. Evaluasi Sistem Pelanggan mengevaluasi apakah sistem yang sudah jadi sudah sesuai dengan yang diharapkan . Juka ya, langkah 7 dilakukan; jika tidak, ulangi langkah 4 dan 5. 7. Menggunakan sistem Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk digunakan .

Keunggulan dan Kelemahan Prototyping Keunggulan prototyping adalah: 1. Adanya 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. Kelemahan prototyping adalah : 1. Pelanggan perangkat kadang yang tidak ada melihat belum atau menyadari bahwa kualitas lunak mencantumkan komunikasi yang baik antara pengembang dan

perangkat lunak secara keseluruhan dan juga belum memikirkan kemampuan pemeliharaan untuk jangja waktu lama. 2. penegmbang biasanya ingin cepat menyelesaikan proyek. tanpa Sehingga menggunakan algoritma dan bahasa pemrograman yang sederhana untuk membuat prototyping lebih cepat selesai cetak biru sistem . 3. Hubungan pelanggan dengan komputer yang disediakan mungkin tidak mencerminkan teknik perancangan yang baik Prototyping bekerja dengan baik pada penerapan-penerapan yang berciri sebagai berikut: 1. Resiko tinggi yaitu untuk masalah-masalah yang tidak terstruktur dengan baik, ada perubahan yang besar dari waktu ke waktu, dan adanya persyaratan data yang tidak menentu. 2. Interaksi pemakai penting . Sistem harus menyediakan dialog onmemikirkan lebih lanjut bahwa program tersebut hanya merupakan

line antara pelanggan dan komputer. 3. Perlunya penyelesaian yang cepat 4. Perilaku pemakai yang sulit ditebak 5. Sitem mutakhir 6. Perkiraan tahap penggunaan sistem yang pendek Prototipe bisa juga menjadi masalah karena alasan sebagai berikut:
1. Pelanggan melihat apa yang tampak sebagai versi software yang

yang

inovatif.

Sistem

tersebut

membutuhkan

cara

penyelesaian masalah dan penggunaan perangkat keras yang

bekerja tanpa melihat bahwa prototipe itu dijalin bersama – sama “dengan permen karet dan baling wire”, tanpa melihat bahwa di dalam untuk membuatnya bekerja, kita belum menyantumkan kualitas software secara keseluruhan atau kemampuan pemeliharaan untuk jangka waktu yang panjang. Ketika diberi informasi bahwa produk harus dibangun lagi agar tingkat kualitas yang tinggi bisa dijaga, pelanggan akan meneriakan kecurangan dan permintaan agar dipakai “beberapa campuran” untuk membuat prototipe menjadi sebuah produk yang bekerja yang lebih sering terjadi, sehingga manajemen pengembangan software menjadi penuh dengan belas kasihan. 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 dan dikenal; algoritma yang tidak efisien secara sederhana bisa diimplementasikan untuk mendemonstrasikan kemampuan. Setelah selang waktu tertentu, pengembang mungkin mengenali pilihan – pilihan tersebut dan melupakan semua alasan mengapa mereka

tidak cocok. Pilihan yang kurang ideal telah menjadi bagian integral dari sebuah sistem. Meskipun berbagai masalah bisa terjadi, prototipe bisa menjadi paradigm yang efektif bagi Software Engineering. Kuncinya adalah mendefinisikan aturan main pada saat awal; yaitu pelanggan dan pengembang keduanya harus setuju bahwa prototipe dibangun untuk berfungsi sebagai mekanisme pendefinisian kebutuhan. Prototipe kemudian disingkirkan (paling tidak sebagian), dan software aktual direkayasa dengan tertuju kepada kualitas dan kemampuan pemeliharaan. 2. METODE RAD ( RAPID APPLICATION DEVELOPMENT ) Rapid Aplication Development (RAD) adalah sebuah model proses perkembangan software sekuensial linier yang menekankan siklus perkembangan yang sangat pendek. Model RAD ini merupakan sebuah adaptasi “kecepatan tinggi” dari model sekuensial linier di mana perkembangan cepat dicapai dengan menggunakan pendekatan kontruksi berbasis komponen. Jika kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan menciptakan “sistem fungsional yang utuh” dalam periode waktu yang sangat pendek (kirakira 60 sampai 90 hari). Karena dipakai terutama pada aplikasi sistem konstruksi, pendekatan RAD melingkupi fase – fase sebagai berikut : 1. Bussiness modeling Aliran informasi di antara fungsi – fungsi bisnis dimodelkan dengan suatu cara untuk menjawab pertanyaan – pertanyaan berikut : informasi apa yang mengendalikan proses bisnis? Informasi apa yang di munculkan? Siapa yang memunculkanya? Ke mana informasi itu pergi? Siapa yang memprosesnya? 2. Data modeling Aliran informasi yang didefinisikan sebagai bagian dari fase bussiness modelling disaring ke dalam serangkaian objek

data

yang

dibutuhkan

untuk

menopang

bisnis

tersebut.

Karakteristik (disebut atribut) masing – masing objek diidentifikasi dan hubungan antara objek – objek tersebut didefinisikan. 3. Prosess modelling Aliran informasi yang didefinisikan di dalam fase data modeling ditransformasikan untuk mencapai aliran informasi yang perlu bagi implementasi sebuah fungsi bisnis. Gambaran pemrosesan diciptakan 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 ketiga yang lagi konvensional, RAD lebih banyak memproses kerja untuk memkai

komponen program yang ada ( pada saat memungkinkan) atau menciptakan komponen yang 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 di uji dan semua interface harus dilatih secara penuh.

Keunggulan dan Kelemahan Model RAD 1. Keunggulan Model RAD • Setiap fungsi mayor dapat dimodulkan dalam waktu tertentu kurang dari 3 bulan dan dapat dibicarakan oleh tim RAD yang terpisah dan kemudian diintegrasikan sehinnga waktunya lebih efesien. • RAD mengikuti tahapan pengembangan sistem sepeti untuk umumnya, tetapi mempunyai kemampuan

menggunakan kembali komponen yang ada (reusable object) sehingga pengembang pengembang tidak perlu membuat dari awal lagi dan waktu lebih singkat . 2. Kelemahan Model RAD : • Proyek yang besar dan berskala, RAD memerlukan sumer daya manusia yang memadai untuk menciptakan jumlah tim yang baik. • RAD menuntut pengembang dan pelanggan memiliki komitmen dalam aktivitas rapid fire yang diperlukan untuk melengkapi sebuah sistem dlam waktu yang singkat. Jiak komitmen tersebut tidak ada maka proyek RAD akan gagal. 3. METODE SDLC / WATERFALL Model ini mengusulkan sebuah pendekatan kepada

perkembangan software yang sistematik dan sekuensial yang mulai pada tingkat dan kemajuan sistem pada seluruh analisis, desain, kode, pengujian, dan pemeliharaan. Dimodelkan setelah siklus rekysa konvensional, model sekuensial linier melingkupi aktivitas – aktivitas sebagai berikut : 1. Rekayasa dan pemodelan sistem/informasi Karena sistem merupakan bagian dari sebuah sistem yang lebih besar, 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 anasisis sistem menyangkut pengumpulan kebutuhan pada tingkat sistem dengan sejumlah kecil analisis serta disain tingkat puncak. Rekayasa informasi mancakup 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. Generasi Kode 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. 6. Pemeliharaan software kesalahan dalam operasi yang – Software akan mengalami perubahan terjadi software perubahan setelah karena harus yang disampaikan kepada pelanggan (perkecualian yang mungkin adalah dilekatkan). kesalahan Perubahan akan ditentukan, karena

disesuaikan untuk mengakomodasi perubahan – perubahan di lingkungan yang eksternalnya atau (contohnya dibutuhkan sebagai akibat dari perangkat peripheral atau sistem baru), karena pelanggan membutuhkan

perkembangan fungsional atau unjuk kerja. Pemeliharaan software mengaplikasikan lagi setiap fase program sebelumnya dan tidak membuat yang baru lagi. Gambar 2.1 Model SDLC Masalah yang kadang terjadi ketika model SDLC diaplikasikan adalah :

1. Jarang sekali proyek nyata mengikuti aliran sekuensial yang dianjurkan oleh model. Meskipun model linier bisa mengakomodasi iterasi, model ini melakukannya dengan cara tidak langsung. Sebagai hasilnya, perubahan – perubahan dapat menyebabkan keraguan pada saat tim proyek berjalan. 2. Kadang – kadang sulit bagi pelanggan untuk menyatakan semua kebutuhannya secara eksplisit. Model linier sekuensial memerlukan hal ini dan mengalami kesulitan untuk mengakomodasi ketidakpastian natural yang ada pada bagian awal beberapa proyek. 3. Pelanggan harus bersifat sabar. Sebuah versi kerja dari program – program kerja itu tidak akan diperoleh sampai akhir waktu proyek dilalui. Sebuah kesalahan besar, jika tidak terdeteksi sampai program yang bekerja tersebut dikaji ulang, bisa menjadi petaka. 4. Pengembang sering melakukan penundan yang tidak perlu. Sifat alami dari siklus kehidupan klasik membawa kepada blocking state di mana banyak anggota tim proyek harus menunggu tim yang lain untuk melengkapi tugas yang saling memiliki ketergantungan. Blocking state cenderung menjadi lebih lazim pada awal dan akhir sebuah proses sekuensial linier. Keunggulan dan Kelemahan Model SDLC • Keunggulan template tentang metode analisis, desain, 1. Mudah aplikasikan 2. Memberikan • Kelemahan dianjurkan model karena model ini bisa melakukan itersi tidak langsung . Hal ini berakibat ada perubahan yang diragukan pada saat proyek berjalan. pengkodean, pengujian, dan pemeliharaan 1. Jarang sekali proyek riil mengikuti aliran sekuensial yang

2. Pelanggan sulit untuk menyatakan kebutuhan secara eksplisit sehingga sulit untuk megakomodasi ketidakpastian pada saat awal proyek. 3. Sebuah kesalahan jika tidak diketahui dari awal akan menjadi masalah besar karena harus mengulang dari awal.

5. METODE INCREMENTAL Model incremental (Incremental waterfall model) merupakan perbaikan dari model waterfall dan sebagai standar pendekatan topdown. Ide dasar dari model ini adalah membangun software secara meningkat (increment) berdasarkan kemampuan fungsional. Model incremental ini diaplikasikan pada sistem pakar dengan penambahan rules yang mengakibatkan bertambahnya kemampuan fungsional sistem. Keuntungan dari model ini adalah bahwa penambahan kemampuan fungsional akan lebih mudah diuji, diverifikasi, dan divalidasi dan dapat menurunkan biaya yang dikeluarkan untuk memperbaiki sistem. Model incremental merupakan model continous rapid prototype dengan durasi yang diperpanjang hingga akhir proses pengembangan. Pada model prototipe biasa, prototipe hanya dibuat pada tahap awal untuk mendapatkan kebutuhan user.

6. METODE SPIRAL Model spiral (spiral model) adalah model proses software yang evolusioner yang merangkai sifat iteratif dari prototipe dengan cara kontrol dan aspek sistematis dari model sekuensial linier. Model ini berpotensi untuk pengembangan versi pertambahan software secara cepat. Di dalam model spiral, software dikembangkan di dalam suatu deretan pertambahan. Selama awal iterasi, rilis inkremental bisa merupakan sebuah model atau prototipe kertas. Selama iterasi

berikutnya, sedikit demi sedikit dihasilkan versi sistem rekayasa yang lebih lengkap. Model spiral dibagi menjadi sejumlah aktifitas kerangka kerja, disebut juga wilayah tugas, di antara tiga sampai enam wilayah tugas, yaitu : komunikasi pelanggan yang dibutuhkan untuk membangun komunikasi yang efektif di antara pengembangan dan pelanggan, perencanaan yang dibutuhkan untuk mendefinisikan sumber – sumber daya, ketepatan waktu, dan proyek informasi lain yang berhubungan, analisis risiko yang dibutuhkan untuk menperhitungkan resiko (manajemen maupun teknis), perekayasaan yang dibutuhkan untuk membangun satu atau lebih representasi dari aplikasi tersebut, konstruksi dan peluncuran yang dibutuhkan untuk mengkonstruksi dan menguji serta memasang (instal) dan memberikan pelayanan kepada user (contohnya pelatihan dan dokumentasi) dan bagian evaluasi user yang dibutuhkan untuk memperoleh umpan balik dari user dengan didasarkan pada evaluasi representasi software, yang dibuat selama masa perekayasaan, dan diimplementasikan selama masa pemasangan. Dalam pengembangan sistem informasi berbasis web, model ini digunakan untuk menyelesaikan sistem secara global terlebih dahulu, kemudian untuk feature dari sistem akan dikembangkan kemudian. Dengan ini mempercepat dalam pengimplementasian project. dan hal ini cocok digunakan dalam sistem informasi Web. Kekurangan model spiral adalah sulitnya untuk meyakinkan konsumen (khusunya dalam situasi kontrak) bahwa pendekatan evolusioner bisa dikontrol. Model spiral memerlukan keahlian penaksiran risiko yang msuk akal , dan sangat bertumpu pada keakhlian ini untuk mencapai keberhasilan. Jika resiko mayor tidak ditemukan dan diatur, pasti akan terjadi masalah. Akhirnya model itu

sendiri masih baru dan belum dipergunakan secara luas seperti paradigma sekuensial dan prototipe.

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->