Berhubung tugasnya udah dapet jadi sekalian aja dishare =D "Ingat, hormati karya orang lain"
Sumber asli disini. So, ini dia..
Model Pengembangan Perangkat Lunak
Model proses untuk rekayasa perangkat lunak dipilih berdasarkan sifat aplikasi dan proyeknya, metode dan alat-alat bantu yang akan dipakai, dan kontrol serta penyampaian yang dibutuhkan. Perkembangan perangkat lunak bisa dianggap sebagai lingkaran pemecahan masalah di mana terdapat empat keadaan berbeda, yaitu status quo, definisi masalah, perkembangan teknis memecahkan masalah , dan integrasi dari seluruh pemecahan masalah. Ada pun beberapa model pengembangan perangkat lunak yang biasa digunakan adalah sebagai berikut:1. Model Sekuensial Linear (Waterfall)
Nama model ini sebenarnya adalah “Linear Sequential Model”. Model ini sering disebut dengan “classic life cycle” atau model waterfall. Model ini adalah model yang muncul pertama kali yaitu sekitar tahun 1970 sehingga sering dianggap kuno, tetapi merupakan model yang paling banyak dipakai didalam Software Engineering (SE). Model ini melakukan pendekatan secara sistematis dan urut mulai dari level kebutuhan sistem lalu menuju ke tahap analisis, desain, coding, testing / verification, dan maintenance. Disebut dengan waterfall karena tahap demi tahap yang dilalui harus menunggu selesainya tahap sebelumnya dan berjalan berurutan. Sebagai contoh tahap desain harus menunggu selesainya tahap sebelumnya yaitu tahap requirement. Secara umum tahapan pada model waterfall dapat dilihat pada gambar berikut :
ambar di atas adalah tahapan umum dari model proses
ini. Akan tetapi Roger S. Pressman memecah model ini menjadi 6 tahapan
meskipun secara garis besar sama dengan tahapan-tahapan model waterfall
pada umumnya. Berikut adalah penjelasan dari tahap-tahap yang dilakukan
di dalam model ini menurut Pressman:
-
System / Information Engineering and Modeling. Permodelan ini diawali dengan mencari kebutuhan dari keseluruhan sistem yang akan diaplikasikan ke dalam bentuk software. Hal ini sangat penting, mengingat software harus dapat berinteraksi dengan elemen-elemen yang lain seperti hardware, database, dsb. Tahap ini sering disebut dengan Project Definition.
-
Software Requirements Analysis. Proses pencarian kebutuhan diintensifkan dan difokuskan pada software. Untuk mengetahui sifat dari program yang akan dibuat, maka para software engineer harus mengerti tentang domain informasi dari software, misalnya fungsi yang dibutuhkan, user interface, dsb. Dari 2 aktivitas tersebut (pencarian kebutuhan sistem dan software) harus didokumentasikan dan ditunjukkan kepada pelanggan.
-
Design. Proses ini digunakan untuk mengubah kebutuhan-kebutuhan diatas menjadi representasi ke dalam bentuk “blueprint” software sebelum coding dimulai. Desain harus dapat mengimplementasikan kebutuhan yang telah disebutkan pada tahap sebelumnya. Seperti 2 aktivitas sebelumnya, maka proses ini juga harus didokumentasikan sebagai konfigurasi dari software.
-
Coding. Untuk dapat dimengerti oleh mesin, dalam hal ini adalah komputer, maka desain tadi harus diubah bentuknya menjadi bentuk yang dapat dimengerti oleh mesin, yaitu ke dalam bahasa pemrograman melalui proses coding. Tahap ini merupakan implementasi dari tahap design yang secara teknis nantinya dikerjakan oleh programmer.
-
Testing / Verification. Sesuatu yang dibuat haruslah diujicobakan. Demikian juga dengan software. Semua fungsi-fungsi software harus diujicobakan, agar software bebas dari error, dan hasilnya harus benar-benar sesuai dengan kebutuhan yang sudah didefinisikan sebelumnya.
-
Maintenance. Pemeliharaan suatu software diperlukan, termasuk di dalamnya adalah pengembangan, karena software yang dibuat tidak selamanya hanya seperti itu. Ketika dijalankan mungkin saja masih ada errors kecil yang tidak ditemukan sebelumnya, atau ada penambahan fitur-fitur yang belum ada pada software tersebut. Pengembangan diperlukan ketika adanya perubahan dari eksternal perusahaan seperti ketika ada pergantian sistem operasi, atau perangkat lainnya.
Proses model yang lain, yang cukup populer adalah
Spiral Model. Model ini juga cukup baru ditemukan, yaitu pada sekitar
tahun 1988 oleh Barry Boehm pada artikel A Spiral Model of Software Development and Enhancement.
Spiral model adalah salah satu bentuk evolusi yang menggunakan metode
iterasi natural yang dimiliki oleh model prototyping dan digabungkan
dengan aspek sistimatis yang dikembangkan dengan model waterfall. Tahap
desain umumnya digunakan pada model Waterfall, sedangkan tahap
prototyping adalah suatu model dimana software dibuat prototype (incomplete model), “blue-print”-nya, atau contohnya dan ditunjukkan ke user / customer untuk mendapatkan feedback-nya.
Jika prototype-nya sudah sesuai dengan keinginan user / customer, maka
proses SE dilanjutkan dengan membuat produk sesungguhnya dengan menambah
dan memperbaiki kekurangan dari prototype tadi.
Model ini juga mengkombinasikan top-down design
dengan bottom-up design, dimana top-down design menetapkan sistem global
terlebih dahulu, baru diteruskan dengan detail sistemnya, sedangkan
bottom-up design berlaku sebaliknya. Top-down design biasanya
diaplikasikan pada model waterfall dengan sequential-nya, sedangkan
bottom-up design biasanya diaplikasikan pada model prototyping dengan
feedback yang diperoleh. Dari 2 kombinasi tersebut, yaitu kombinasi
antara desain dan prototyping, serta top-down dan bottom-up, yang juga
diaplikasikan pada model waterfall dan prototype, maka spiral model ini
dapat dikatakan sebagai model proses hasil kombinasi dari kedua model
tersebut. Oleh karena itu, model ini biasanya dipakai untuk pembuatan
software dengan skala besar dan kompleks.
Spiral model dibagi menjadi beberapa framework
aktivitas, yang disebut dengan task regions. Kebanyakan aktivitas2
tersebut dibagi antara 3 sampai 6 aktivitas. Berikut adalah
aktivitas-aktivitas yang dilakukan dalam spiral model:
-
Customer communication. Aktivitas yang dibutuhkan untuk membangun komunikasi yang efektif antara developer dengan user / customer terutama mengenai kebutuhan dari customer.
-
Planning. Aktivitas perencanaan ini dibutuhkan untuk menentukan sumberdaya, perkiraan waktu pengerjaan, dan informasi lainnya yang dibutuhkan untuk pengembangan software.
-
Analysis risk. Aktivitas analisis resiko ini dijalankan untuk menganalisis baik resiko secara teknikal maupun secara manajerial. Tahap inilah yang mungkin tidak ada pada model proses yang juga menggunakan metode iterasi, tetapi hanya dilakukan pada spiral model.
-
Engineering. Aktivitas yang dibutuhkan untuk membangun 1 atau lebih representasi dari aplikasi secara teknikal.
-
Construction & Release. Aktivitas yang dibutuhkan untuk develop software, testing, instalasi dan penyediaan user / costumer support seperti training penggunaan software serta dokumentasi seperti buku manual penggunaan software.
-
Customer evaluation. Aktivitas yang dibutuhkan untuk mendapatkan feedback dari user / customer berdasarkan evaluasi mereka selama representasi software pada tahap engineering maupun pada implementasi selama instalasi software pada tahap construction and release.
Satu lingkaran dari bentuk spiral pada spiral model
dibagi menjadi beberapa daerah yang disebut dengan region. Region
tersebut dibagi sesuai dengan jumlah aktivitas yang dilakukan dalam
spiral model. Tentunya lingkup tugas untuk project yang kecil dan besar
berbeda. Untuk project yang besar, setiap region berisi sejumlah
tugas-tugas yang tentunya lebih banyak dan kompleks daripada untuk
project yang kecil. SE berjalan dari inti spiral berjalan mengitari
sirkuit per sirkuit. Sebagai contoh untuk sirkuit pertama dilakukan
untuk pembangunan dari spesifikasi dari software dengan mencari
kebutuhan dari customer. Untuk sirkuit pertama harus menjalani semua
aktivitas yang didefinisikan. Setelah 1 sirkuit terlewati lanjut ke
tugas selanjutnya misalnya membangun prototype. Tugas ini juga harus
mengitari 1 sirkuit dan begitu terus selanjutnya sampai project selesai.
Tidak seperti model-model konvesional dimana setelah
SE selesai, maka model tersebut juga dianggap selesai. Akan tetapi hal
ini tidak berlaku untuk spiral model, dimana model ini dapat digunakan
kembali sepanjang umur dari software tersebut. Pada umumnya, spiral
model digunakan untuk beberapa project seperti Concept Development
Project (proyek pengembangan konsep), New Product Development Project
(proyek pengembangan produk baru), Product Enhancement Project (proyek
peningkatan produk), dan Product Maintenance Project (proyek
pemeliharaan proyek). Keempat project tersebut berjalan berurutan
mengitari sirkuit dari spiral. Sebagai contoh setelah suatu konsep
dikembangkan dengan melalui aktivitas2 dari spiral model, maka
dilanjutkan dengan proyek selanjutnya yaitu pengembangan produk baru,
peningkatan produk, sampai pemeliharaan proyek. Semuanya melalui
sirkuit2 dari spiral model.
3. Model Prototipe
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. Evolutionary Prototype
- 2. Requirements Prototype
Gambar: Evolutionary Prototyping Model.
- 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.
- Membuat prototype, pengembang membuat prototype dari sistem yang telah dijelaskan oleh pengguna atau pemilik sistem.
- Menyesuaikan prototype dengan keinginan user, pengembang menanyakan kepada pengguna atau pemilik sistem tentang prototype yang sudah dibuat, apakah sesuai atau tidak dengan kebutuhan sistem.
- 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
- 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.
- Membuat prototype, pengembang membuat prototype dari sistem yang telah dijelaskan oleh pengguna atau pemilik sistem.
- Menyesuaikan prototype dengan keinginan user, pengembang menanyakan kepada pengguna atau pemilik sistem tentang prototype yang sudah dibuat, apakah sesuai atau tidak dengan kebutuhan sistem.
- Membuat sistem baru, pengembang menggunakan prototype yang sudah dibuat untuk membuat sistem baru.
- Melakukan testing sistem, pengguna atau pemilik sistem melakukan uji coba terhadap sistem yang dikembangkan
- Menyesuaikan dengan keinginan user, sistem disesuaikan dengan keinginan user dan kebutuhan sistem, jika sudah sesuai sistem siap digunakan.
- Menggunakan sistem.
- Menghemat waktu pengembangan.
- Menghemat biaya pengembangan.
- Pengguna atau pemilik sistem ikut terlibat dalam pengembangan, sehingga kemungkinan-kemungkinan terjadinya kesalahpahaman dalam sistem bisa diminimalisir.
- Implementasi akan menjadi mudah, karena pengguna atau pemilik sistem sudah mempunyai gambaran tentang sistem.
- Kualitas sistem yang dihasilkan baik.
- Memungkinan tim pengembang sistem memprediksi dan memperkirakan pengembangan-pengembangan sistem selanjutnya.
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.
4. Model Rapid Application Development (RAD)
Rapid Aplication Model (RAD) adalah sebuah 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 “sistem fungsional yang utuh” dalam periode waktu yang sangat pendek (kira-kira 60 sampai 90 hari).
Fase-fase RAD
Karena dipakai terutama pada aplikasi sistem konstruksi, pendekatan RAD melingkupi fase-fase sebagai berikut :
· 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 dimunculkan? Siap yang
memunculkannya? Ke mana informasi itu pergi? Siapa yang memprosesnya?
· Data Modeling
Aliran informasi yang didefinisikan sebagai bagian dari fase bussiness modeling
disaring ke dalam serangkaian objek data yang dibutuhkan untuk menopang
bisnis tersebut. Karakteristik masing-masing objek didefinisikan dan
hubungan antara objek-objek tersebut didefinisikan.
· Prosess Modeling
Objek
data yang telah 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.
· Aplication Generation
RAD
mengasumsikan pemakaian teknik generasi keempat. Selain menciptakan
perangkat lunak dengan menggunakan bahasa pemrograman general yang
konvensional, RAD lebih banyak memproses kerja untuk mamakai lagi
komponen program yang ada atau menciptakan komponoen yang bisa dipakai
lagi. 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.Secara jelas batasan waktu yang dibebankan pada sebuah proyek RAD memerlukan “ruang lingkup yang bisa 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 di atas), maka aplikasi itu merupakan kandidat bagi RAD. Masing-masing fungsi mayor bisa dibicarakan oleh suatu tim RAD yang terpisah dan kemudian diintegraikan untuk membentuk suatu kesatuan.
0 comments:
Post a Comment