MENGENAL MACAM MACAM MODEL RPL

1. REKAYASA PERANGKAT LUNAK (MODEL WATERFALL)

1. Sejarah model waterfall

Nama model ini sebenarnya adalah “Linear Sequential Model”. Model ini sering disebut dengan “classic life cycle” atau model waterfall. Model ini pertama kali yang diperkenalkan oleh Winston Royce 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 berurutan. Disebut dengan waterfall karena tahap demi tahap yang dilalui harus menunggu selesainya tahap sebelumnya dan berjalan berurutan.

2. Pengertian Waterfall

Waterfall atau AIR terjun adalah model yang dikembangkan untuk pengembangan perangkat lunak, membuat perangkat lunak. model berkembang secara sistematis dari satu tahap ke tahap lain dalam mode seperti air terjun.

Model ini mengusulkan sebuah pendekatan kepada pengembangan software yang sistematikdan sekuensial yang mulai dari tingkat kemajuan sistem pada seluruh analisis, desain, kode, pengujian dan pemeliharaan. Model ini melingkupi aktivitas-aktivitas sebgai berikut : rekayasa dan pemodelan sistem informasi, analisis kebutuhan, desain, koding, mengujian dan pemeliharaan.

Model pengembangan ini bersifat linear dari tahap awal pengembangan system yaitu tahap perencanaan sampai tahap akhir pengembangan system yaitu tahap pemeliharaan. Tahapan berikutnya tidak akan dilaksanakan sebelum tahapan sebelumnya selesai dilaksanakan dan tidak bisa kembali atau mengulang ke tahap sebelumnya.

3. Tahapan atau fase model waterfall

Ini adalah gambar tahapan yang paling umum tentang model waterfall

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 Gambar dan penjelasan dari tahap-tahap yang dilakukan di dalam model ini menurut Pressman:

1)   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.

2)    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.

3)   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.

4)   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.

5)   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.

6)   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.

Keuntungan dari Model Waterfall

1)      Merupakan model pengembangan paling handal dan paling lama digunakan.

2)      Cocok untuk system software berskala besar.

3)       Cocok untuk system software yang bersifat generic.

4)       Pengerjaan project system akan terjadwal dengan baik dan mudah dikontrol

Kelemahan Waterfall

  

Waktu pengembangan lama. hal ini dikarenakan input tahap berikutnya adalah output dari tahap sebelumnya. Jika satu tahap waktunya molor, maka waktu keseluruhan pengembangan juga ikut molor.

Biaya juga mahal, hal ini juga dikarenakan waktu pengembangan yang lama

Terkadang perangkat lunak yang dihasilkan tidak akan digunakan karena sudah tidak sesuai dengan requirement bisnis customer. hal ini juga dikarenakan waktu pengembangan yang lama. selain itu dikarenakan waterfall merupakan aliran yang linear, sehingga jika requirement berubah proses tidak dapat diulang lagi.

2.METODE PROTOTYPING

Menurut Raymond McLeod, prototype didefinisikan sebagai alat yang memberikan ide bagi pembuat maupun pemakai potensial tentang cara system berfungsi dalam bentuk lengkapnya, dan proses untuk menghasilkan sebuah prototype sisebut prototyping.

Prototyping adalah proses pembuatan model sederhana software yang mengijinkan pengguna memiliki gambaran dasar tentang program serta melakukan pengujian awal. Prototyping memberikan fasilitas bagi pengembang dan pemakai untuk saling berinteraksi selama proses pembuatan, sehingga pengembang dapat dengan mudah memodelkan perangkat lunak yang akan dibuat. Prototyping merupakan salah satu metode pengembangan perangat lunak yang banyak digunakan.

Model tersebut dapat berupa tiga bentuk :

1.      Prototipe kertas atau model berbasis komputer yang menjelaskan bagaimana interaksi antara pemakai dan komputer.

2.      Prototipe yang mengimplementasikan beberapa bagian fungsi dari perangkat lunak  yang sesungguhnya. Dengan cara ini pemakai akan lebih mendapatkan gambaran tentang program yang akan dihasilkan, sehingga dapat menjabarkan lebih rinci kebutuhannya.

3.      Menggunakan perangkat lunak yang sudah ada. Seringkali pembuat software memiliki beberapa program yang sebagian dari program tersebut mirip dengan program yang akan dibuat.

Terdapat tiga pendekatan utama prototyping, yaitu:

1.      THROW-AWAY

Prototype dibuat dan dites. Pengalaman yang diperoleh dari pembuatan prototype digunakan untuk membuat produk akhir (final), kemudian prototype tersebut dibuang (tak dipakai).

2.      INCREMENTAL

Produk finalnya dibuat sebagai komponen-komponen yang terpisah. Desain produk finalnya secara keseluruhan haya ada satu tetapi dibagi dalam komonen-komponen lebih kecil yang terpisah (independent).

3.      EVOLUTIONARY

Pada metode ini, prototipenya tidak dibuang tetapi digunakan untuk iterasi desain berikutnya. Dalam hal ini, sistem atau produk yang sebenarnya dipandang sebagai evolusi dari versi awal yang sangat terbatas menuju produk final atau produk akhir.

Berikut ini adalah jenis-jenis prototyping, yaitu :

1.      Feasibility prototyping

Digunakan untuk menguji kelayakan dari teknologi yang akan digunakan untuk system informasi yang akan disusun.

2.      Requirement prototyping

Digunakan untuk mengetahui kebutuhan aktivitas bisnis user.

3.      Desain prototyping

Digunakan untuk mendorong perancangan system informasi yang akan digunakan.

4.      Implementation prototyping

Merupakan lanjutan dari rancangan, prototype ini langsung disusun sebagai suatu system informasi yang akan digunakan.

Keunggulan dan Kelemahan Prototyping adalah sebagai berikut :

A.    Keunggulan prototyping :

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

4.      Lebih menghemat waktu dalam pengembangan system.

5.      Penerapan menjadi lebih mudah karena pemakai mengetahui apa yang diharapkannya

B.     Kelemahan prototyping :

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

3.rekayasa perangkat lunak Model spiral

Model spiral adalah model proses yang pendekatannya bersifat realistis pada software besar karena proses dari awal sampai proses pengiriman dan perbaikan dapat dipahami dnegan baik oleh clieent dan developer. Model ini mempunyai rangkaian kerja yang iterasi (peningkatan pada model) awal yang berbentuk prototype dan kemudian iterasi selanjutnya akan menjadi perkembangan dari model sebelumnya. Model ini dapat terus digunakan meskipun software sudah dikirimkan karena proses (siklus)dapat berputar lagi jika ada perubahan pada software sampai tidak ada permintaan perupbahan pada software oleh client.

Ada 6 pembagian proses pembuatan pada spiral model :

1. Komunikasi Pelanggan.
2. Perencanaan.
3. Analisis resiko.
4. Perekayasaan.
5. Konstruksi dan Peluncuran.
6. Evaluasi Client

Kelebihan model Spiral :

1. Setiap tahap pengerjaan dibuat prototyping sehingga kekurangan dan apa yang diharapkan oleh client dapat diperjelas dan juga dapat menjadi acuan untuk client dalam mencari kekurangan kebutuhan.
2. Lebih cocok untuk pengembangan sistem dan perangkat lunak skala besar.
3. Dapat disesuaikan agar perangkat lunak bisa dipakai selama hidup perangkat lunak komputer. 
4. Pengembang dan pemakai dapat lebih mudah memahami dan bereaksi terhadap resiko setiap tingkat evolusi karena perangkat lunak terus bekerja selama proses.
5. Menggunakan prototipe sebagai mekanisme pengurangan resiko dan pada setiap keadaan di dalam evolusi produk.
6. Tetap mengikuti langkah-langkah dalam siklus kehidupan klasik dan memasukkannya ke dalam kerangka kerja iteratif.
7. Membutuhkan pertimbangan langsung terhadp resiko teknis sehingga mengurangi resiko sebelum menjadi permaslahan yang serius.

   
Kekurangan model Spiral :

1. Banyak konsumen (Client) tidak percaya bahwa pendekatan secara evolusioner dapat dikontrol oleh kedua pihak. Model spiral mempunyai resiko yang harus dipertimbangkan ulang oleh konsumen dan developer.
2. Memerlukan tenaga ahli untuk memperkirakan resiko, dan harus mengandalkannya supaya sukses.
3. Belum terbukti apakah metode ini cukup efisien karena usianya yang relatif baru.
4. Memerlukan penaksiran resiko yang masuk akal dan akan menjadi masalah yang serius jika resiko mayor tidak ditemukan dan diatur.

4.Model RAD (Rapid Application Development)

Merupakan model proses pengembangan perangkat lunak secara linear sequential yang menekankan pada siklus pengembangan yang sangat singkat/pendek. Jika kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan menciptakan “sistem fungsional yang utuh” dalam periode waktu yang sangat pendek (kira-kira 60-90 hari). Pendekatan RAD model menekankan cakupan :

a.    Pemodelan bisnis (Bussiness Modelling)

Aliran informasi diantara fungsi-fungsi bisnis dimodelkan dengan suatu cara untuk menjawab pertanyaan-pertanyaan berikut : Informasi apa yang mengendalikan proses bisnis ? Kemana informasi itu pergi? Siapa yang memprosesnya ?

2. Pemodelan data (Data Modelling)

Aliran informasi yang didefinisikan sebagai bagian dari fase pemodelan bisnis disaring ke dalam serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut. Karakteristik/atribut dari masing-masing objek diidentifikasi dan hubungan antara objek-objek tersebut didefinisikan.

3. Pemodelan proses (Process Modelling)

Aliran informasi yang didefinisikan dalam fase pemodelan data 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. Pembuatan aplikasi (Application generation)

Selain menciftakan perangkat lunak dengan menggunakan bahasa pemrograman generasi ketiga yang konvensional, RAD lebih banyak memproses kerja untuk memakai lagi komponen program yang telah ada atau menciftakan komponen yang bias dipakai lagi. Pada semua kasus, alat-alat Bantu otomatis dipakai untuk memfasilitasi kontruksi perangkat lunak.

5. Pengujian dan pergantian (Testing and turnover)

Karena proses RAD menekankan pada pemakaian kembali, banyak komponen yang telah diuji. Hal ini mengurangi keseluruhan waktu pengujian. Tapi komponen baru harus diuji.

Kelemahan model  RAD :

a.       Untuk proyek dengan skala besar, RAD membutuhkan sumber daya manusia yang cukup untuk membentuk sejumlah tim RAD yang baik.

b.      RAD membutuhkan pengembang dan pemakai yang mempunyai komitmen dalam aktivitas rapid-fire untuk melaksanakan aktivitas melengkapi sistem dalam kerangka waktu yang singkat. Jika komitmen tersebut tidak ada, proyek RAD gagal.

Tidak semua aplikasi sesuai untuk RAD.bila system tidak dapat dimodulkan dengan teratur, pembangunan komponen penting pada RAD akan menjadi sangat problematic. RAD menjadi tidak sesuai jika risiko teknisnya tinggi.

Rekayasa perangkat lunak model RUP

Apa sebetulnya RUP itu? Berdasarkan buku Agility and Discipline Made Easy: Practices from OpenUP and RUP, RUP merupakan framework proses yang banyak diadopsi dan digunakan oleh puluhan ribu proyek mulai dari tim dengan dua anggota hingga tim dengan ratusan anggota, pada berbagai industri di seluruh dunia. RUP bercabang, salah atunya adalah EPF (Eclipse Process Framework) dengan sebuah volume tambahan konten proses yang besar, memungkinkan tim pengembangan untuk mengukur proses mereka untuk melakukan hal berikut:

• Melakukan distribusi atau pengembangan skala besar yang membutuhkan lebih banyak serangkaian aturan, seperti persyaratan traceability, model analisis, model-driven architecture (MDA), atau pengujian beban dan kinerja secara komprehensif.
• Mengembangkan sistem yang menggunakan alat IBM, memberikan panduan khusus tentang teknologi yang relevan seperti J2EE dan .NET, dan menggunakan IBM beserta turunan-turunan atau keluarganya.
• Mengembangkan sistem yang mengikuti standar industri seperti ISO 9001, SEI CMMI, atau SOX.
• Mengatur proses berorientasi projek menjadi proses enterprise, seperti program dan portofolio manajemen; rekayasa sistem; penggunaan ulang enterprise; pemodelan bisnis dan simulasi; atau SOA berskala enterprise.

Dalam buku Software Engineering for Small Project disebutkan bahwa salah satu keuntungan nyata penggunaan RUP adalah fleksibel.

Pada bukunya Gary menyebutkan pendekatan RUP adalah dengan memikirkan artefak (requirements, tests, code, dan seterusnya) yang dibutuhkan oleh projekt, lalu mempertimbangkan apa aktivitas untuk melakukan pembuatan artefak tersebut. Sebuah kunci utama yang perlu dingat adalah, bahwa tujuannya adalah untuk membangun software, bukan membuat artefak.

Berikut adalah artefak dasar yang kita percaya setiap tim membutuhkannya:

• Sebuah Visi. Hal ini membantu tim proyek memahami untuk membangun apa dan kemudian membantu mereka tahu kapan mereka selesai membangun itu.
• Sebuah Daftar Risiko. Apa resiko yang sebenarnya Anda hadapi dan bagaimana Anda akan menanggulanginya? Ketika Anda berpikir tentang risiko, pertimbangkan elemen ini proyek Anda: orang, proses, dan alat-alat.
• Masalah Pengembangan. Ini menjelaskan bagaimana Anda akan beradaptasi RUP dengan kebutuhan Anda. Salah satu bagian penting dari kasus pembangunan adalah bahwa ia menjelaskan tanggung jawab masing-masing peran yang berbeda pada proyek.
• Use Case. Ini mendefinisikan serangkaian interaksi antara sistem dan aktor (biasanya seorang pengguna) yang menghasilkan hasil yang dapat diamati dari nilai.
• Seperangkat Tes yang Baik. Jika Anda menggunakan RUP, maka Anda dapat mulai menghasilkan tes segera setelah Anda menyelesaikan use case pertama Anda.
• Sebuah Arsitektur. Ini mungkin sangat informal. Beberapa kelompok merilis versi pertama mereka tanpa arsitektur formal, maka (dengan asumsi sukses) ketika mereka sedang merencanakan versi kedua, mereka mulai dengan mendokumentasikan arsitektur sejauh ini dan bagaimana mengembangkannya.
• Sebuah Rencana Proyek. Perencanaan ini harus menguraikan iterasi dan jadwal. Desainlah iterasi agar Anda mengatasi item risiko utama selama fase Elaborasi (salah satu dari empat fase RUP). Ini akan membantu Anda mengurangi kemungkinan kejutan teknis atau pekerjaan ulang yang tak terduga di akhir proyek

Sebuah Glosarium. Glosarium harus berisi definisi untuk menjaga bahasa tim Anda konsisten, proyek yang luas. Jika tim, termasuk pelanggan Anda dan semua pemangku kepentingan, yang akrab dengan domain dan semua hal yang mungkin Anda gunakan saat bekerja pada proyek, Anda mungkin tidak perlu menulis glosarium.

 

Berbeda halnya pada buku The Rational Unified Process: An Introduction (2nd Edition),  Rational Unified Process adalah proses rekayasa perangkat lunak. RUP menyediakan pendekatan disiplin untuk menetapkan tugas dan tanggung jawab dalam pengembangan organisasi. Tujuannya adalah untuk memastikan produksi perangkat lunak berkualitas tinggi yang memenuhi kebutuhan pengguna akhir pada jadwal dan anggaran yang dapat diprediksi.

Rational Unified Process adalah sebuah proses poduk. Hal ini dikembangkan dan dikelola oleh Rational Software dan terintegrasi dengan seperangkat  alat pengembangan perangkat lunak. Perangkat ini tersedia pada CD-ROM Software Rational atau melalui internet. Rational Unified Process juga sebuah framework proses yang dapat disesuaikan dan dikembangkan sesuai dengan kebutuhan adopsi organisasi.

Phase RUP

RUP menguraikan empat fase (Inception, Elaboration, Construction dan Transition) yang mana sebuah projek melaluinya. Fase Inception adalah tentang menciptakan visi, mengembangkan kasus bisnis, dan prototipe software atau solusi parsial agar orang mengusahakannya mendapat dukungan dan pendanaan. Fase Elaboration berakhir dengan eksekusi arsitektur di mana keputusan arsitektur utama telah dibuat dan risiko telah dikurangi. Eksekusi arsitekur software menunjukkan sebuah implementasi dari kunci keputusan arsitektur. Fase Constrction adalah tentang mengisi fungsi yang diidentifikasi dalam arsitektur, dan fase Transition berfokus pada penyampaian software untuk para penggunanya.

 

Tahapan dibagi menjadi iterasi. Iterasi adalah “time-boxed” dan memiliki tujuan tertentu. Iterasi disimpan sesingkat mungkin, tapi cukup lama bagi Anda untuk menerapkan kelengkapan use case atau skenario use case yang memberikan nilai nyata bagi pengguna. Pada akhir setiap iterasi, Anda memegang penilaian di mana Anda menyesuaikan rencana untuk iterasi mendatang, berdasarkan hasil dari iterasi saat ini. Selama penilaian, tim Anda juga mencerminkan tentang manfaat proses dan penyesuaian seperlunya. RUP adalah tentang menciptakan visi dari apa yang Anda inginkan, menciptakan kerangka kerja untuk mencapai visi tersebut, dan menilai di poin yang diberikan apakah Anda mencapai sesuai dengan yang direncanakan.

SUMBER : https://mhulyana.wordpress.com/2015/05/03/menelusuk-pengertian-rup-rational-unified-process/

6.Metode Pengembangan Extreme Programming

Extreme Programming (XP) merupakan suatu pendekatan yang paling banyak digunakan untuk pengembangan perangkat lunak cepat. Alasan menggunakan metode  Extreme Programming (XP) karena sifat dari aplikasi yang di kembangkan dengan cepat melalui tahapan-tahapan yang ada meliputi : Planning/Perencanaan, Design/Perancangan, Coding/Pengkodean dan Testing/Pengujian. (Pressman, 2012:88). Adapun  tahapan pada Extreme Programming dapat di jelaskan sebagai berikut:

 1)         Planning/Perencanaan

Pada tahap perencanaan ini dimulai dari pengumpulan kebutuhan yang membantu tim teknikal untuk memahami konteks bisnis dari sebuah aplikasi. Selain itu pada tahap ini juga mendefinisikan output yang akan dihasilkan, fitur yang dimiliki oleh aplikasi dan fungsi dari aplikasi yang dikembangkan.

2)         Design/Perancangan

Metode ini menekankan desain aplikasi yang sederhana, untuk mendesain aplikasi dapat menggunakan Class-Responsibility-Collaborator (CRC) cards yang mengidentifikasi dan mengatur class pada object-oriented.

3)         Coding/Pengkodean

Konsep utama dari tahapan pengkodean pada extreme programming adalah pair programming, melibatkan lebih dari satu orang untuk menyusun kode.

4)         Coding/Pengujian

Pada tahapan ini lebih fokus pada pengujian fitur dan fungsionalitas dari aplikasi.

Sumber: http://catatandestra.blogspot.co.id/2014/11/metode-pengembangan-extreme-programming.html