METODE PENGEMBANGAN SISTEM/SOFTWARE

1. METODE PROTOTYPE

Prototyping merupakan salah satu metode pengembanganperangat lunak yang banyak digunakan. Dengan metode prototypingini pengembang dan pelanggan dapat saling berinteraksi selamaproses pembuatan sistem.Sering terjadi seorang pelanggan hanya mendefinisikan secaraumum apa yang dikehendakinya tanpa menyebutkan secara detaloutput apa saja yang dibutuhkan, pemrosesan dan data-data apa sajayang dibutuhkan. Sebaliknya disisi pengembang kurangmemperhatikan efesiensi algoritma, kemampuan sistem operasi daninterface yang menghubungkan manusia dan komputer.Untuk mengatasi ketidakserasian antara pelanggan danpengembang , maka harus dibutuhkan kerjasama yanga baik diantarakeduanya sehingga pengembang akan mengetahui dengan benar apayang diinginkan pelanggan dengan tidak mengesampingkan segi-segiteknis dan pelanggan akan mengetahui proses-proses dalammenyelasaikan sistem yang diinginkan. Dengan demikian akanmenghasilkan sistem sesuai dengan jadwal waktu penyelesaian yangtelah ditentukan.Kunci agar model prototype ini berhasil dengan baik adalahdengan mendefinisikan aturan-aturan main pada saat awal, yaitupelanggan dan pengembang harus setuju bahwa prototype dibangununtuk mendefinisikan kebutuhan. Prototype akan dihilangkan sebagianatau seluruhnya dan perangkat lunak aktual aktual direkayasa dengankualitas dan implementasi yang sudah ditentukan

Tahapan-Tahapan Prototyping

1. Tahapan-tahapan dalam Prototyping adalah sebagai berikut:1.Pengumpulan kebutuhan Pelanggan dan pengembang bersama 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 penyajiankepada pelanggan (misalnya dengan membuat input dan formatoutput)
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 langkah1, 2 , dan 3.
4. Mengkodekan sistem Dalam tahap ini prototyping yang sudah disepakati 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 . Jika 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 komunikasi yang baik antara pengembang dan 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 kadang tidak melihat atau menyadari bahwa perangkat lunak yang ada belum mencantumkan kualitas perangkat lunak secara keseluruhan dan juga belum memikirkan kemampuan pemeliharaan untuk jangja waktu lama.
2. pengembang biasanya ingin cepat menyelesaikan proyek. Sehingga menggunakan algoritma dan bahasa pemrograman yang sederhana untuk membuat prototyping lebih cepat selesai tanpa memikirkan lebih lanjut bahwa program tersebut hanya merupakan 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 on-line antara pelanggan dan komputer.
3. Perlunya penyelesaian yang cepat
4. Perilaku pemakai yang sulit ditebak
5. Sitem yang inovatif. Sistem tersebut membutuhkan cara penyelesaian masalah dan penggunaan perangkat keras yang 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 bekerja tanpa melihat bahwa prototipe itu dijalin bersama – sama“dengan permen karet dan baling wire”, tanpa melihat bahwa didalam untuk membuatnya bekerja, kita belum menyantumkan kualitas software secara keseluruhan atau kemampuan pemeliharaan untuk jangka waktu yang panjang. Ketika diberiinformasi 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 bisadi implementasikan 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 (kira-kira 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 diidentifikasidan 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 konvensional, RAD lebih banyak memproses kerja untuk memkai lagi 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 telah di uji. 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 umumnya, tetapi mempunyai kemampuan untuk menggunakan kembali komponen yang ada (reusable object) sehingga pengembang pengembang tidak perlu membuatdari 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 timyang baik.
• RAD menuntut pengembang dan pelanggan memiliki komitmen dalam aktivitas rapid fire yang diperlukan untuk melengkapi sebuah sistem dlam waktu yang singkat. Jika 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 rekayasa konvensional, model sekuensial linier melingkupi aktivitas-aktivitas sebagai berikut :

1. Rekayasa dan pemodelan sistem/informasi

Karena sistem merupakan bagian dari sebuah sistem yang lebihbesar, kerja dimulai dengan membangun syarat dari semua elemen
sistem dan mengalokasikan beberapa subset dari kebutuhan kesoftware tersebut. Pandangan sistem ini penting ketika softwareharus berhubungan dengan elemen-elemen yang lain sepertisoftware, manusia, dan database. Rekayasa dan anasisis sistemmenyangkut pengumpulan kebutuhan pada tingkat sistem dengansejumlah kecil analisis serta disain tingkat puncak. Rekayasainformasi mancakup juga pengumpulan kebutuhan pada tingkatbisnis 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 denganpelanggan.

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 pemunculankode. 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 dapatdiselesaikan 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 dibatasiakan memberikan hasil aktual yang sesuai dengan hasil yangdibutuhkan.

6. Pemeliharaan

Software akan mengalami perubahan setelah disampaikan kepada pelanggan (perkecualian yang mungkin adalahsoftware yang dilekatkan). Perubahan akan terjadi karena kesalahan – kesalahan ditentukan, karena software harus disesuaikan untuk mengakomodasi perubahan – perubahan didalam lingkungan eksternalnya (contohnya perubahan yang dibutuhkan sebagai akibat dari perangkat peripheral atau sistem operasi yang baru), atau karena pelanggan membutuhkan perkembangan fungsional atau unjuk kerja. Pemeliharaan software mengaplikasikan lagi setiap fase program sebelumnya dan tidakmembuat yang baru lagi.

4. 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 – sumberdaya, 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 masapemasangan.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.





Comments

Popular posts from this blog

Entity Relationship Diagram (ERD) Minimarket

RPL

Otomata & Teori Bahasa