1. Rekayasa perangkat lunak  (Waterfall Model)

Model siklus hidup (life cycle model) adalah model utama dan dasar dari banyak model. Salah satu model yang cukup dikenal dalam dunia rekayasa perangkat lunak adalah The Waterfall Model. Disebut waterfall (berarti air terjun) karena memang diagram tahapan prosesnya mirip dengan air terjun yang bertingkat. Model ini adalah model klasik yang bersifat sistematis, berurutan dalam membangun software.

Berikut ini ada dua gambaran dari waterfall model. Sekalipun keduanya menggunakan nama-nama fase yang berbeda, namun sama dalam intinya.

Fase-fase dalam Waterfall Model menurut referensi Pressman:

Fase-fase dalam Waterfall Model menurut referensi Sommerville :

Tahapan-tahapan dalam The Waterfall Model secara ringkas adalah sebagai berikut:

• ·         Tahap investigasi dilakukan untuk menentukan apakah terjadi suatu masalah atau adakah peluang suatu sistem informasi dikembangkan. Pada tahapan ini studi kelayakan perlu dilakukan untuk menentukan apakah sistem informasi yang akan dikembangkan merupakan solusi yang layak.
• ·         Tahap analisis bertujuan untuk mencari kebutuhan pengguna dan organisasi serta menganalisa kondisi yang ada (sebelum diterapkan sistem informasi yang baru).
• ·         Tahap disain bertujuan menentukan spesifikasi detil dari komponen-komponen sistem informasi (manusia, hardware, software, network dan data) dan produk-produk informasi yang sesuai dengan hasil tahap analisis.
• ·         Tahap implementasi merupakan tahapan untuk mendapatkan atau mengembangkan hardware dan software (pengkodean program), melakukan pengujian, pelatihan dan perpindahan ke sistem baru.
• ·         Tahapan perawatan (maintenance) dilakukan ketika sistem informasi sudah dioperasikan. Pada tahapan ini dilakukan monitoring proses, evaluasi dan perubahan (perbaikan) bila diperlukan.

Kelebihan dan kekurangan :

• Perubahan sulit dilakukan karena sifatnya yang kaku.
• Karena sifat kakunya, model ini cocok ketika kebutuhan dikumpulkan secara lengkap sehingga perubahan bisa ditekan sekecil mungkin. Tapi pada kenyataannya jarang sekali konsumen/pengguna yang bisa memberikan kebutuhan secara lengkap, perubahan kebutuhan adalah sesuatu yang wajar terjadi.
• Waterfall pada umumnya digunakan untuk rekayasa sistem yang besar dimana proyek dikerjakan di beberapa tempat berbeda, dan dibagi menjadi beberapa bagian sub-proyek.

SUMBER : https://ahmedhambal.wordpress.com/2012/03/30/waterfall-model/

2. Rekayasa Perangkat Lunak (Model Prototype)

Dalam pembuatan software, dikenal beberapa metode untuk membuat software yang dibutuhkan untuk memenuhi kebutuhan user yang memerlukan software tersebut.

Sebelum memasuki lebih mendalam mengenai pembuatan software menggunakan metode prototype, kita harus terlebih dahulu mengetahui apa yang dimaksud dengan prototype itu sendiri. Prototype adalah model atau simulasi dari semua aspek produk sesungguhnya yang akan dikembangkan yang dimana model tersebut harus representative dari produk akhirnya. Setelah mengetahui arti prototype mungkin masih menganjal dibenak kita bagaimana sih software itu terbentuk menggunakan metode prototype? Apakah model prototype lebih bagus digunakan daripada model lain? Apakah resiko-resiko dari penggunaan model tersebut? Dan mungkin masih banyak pertanyaan lain yang akan muncul. Oleh sebab itu, pada postingan kali ini saya sendiri akan menjelaskan lebih lanjut mengenai pembuatan software dengan menggunakan metode prototype tersebut.

Model Prototype
Menurut saya sendiri prototyping model adalah suatu proses pembuatan software yang yang bersifat berulang dan dengan perencanaan yang cepat yang dimana terdapat umpan balik yang memungkinkan terjadinya perulangan dan perbaikan software sampai dengan software tersebut memenuhi kebutuhan dari si pengguna. Sedangkan dari beberapa referensi yang saya temukan, prototyping model adalah salah satu model sederhana pembuatan software yang dimana mengijinkan pengguna memiliki suatu gambaran awal/dasar tentang program serta melakukan oengujian awal yang didasarkan pada konsep model kerja(working model).

Tujuan Prototype
Prototyping model sendiri mempunyai tujuan yaitu mengembangkan model awal software menjadi sebuah sistem yang final.

A. Proses

Proses-proses dalam model prototyping menurut saya yaitu:

• Komunikasi terlebih dahulu yang dilakukan antara pelanggan dengan tim pemgembang perangkat lunak mengenai spesifikasi kebutuhan yang diinginkan
• Akan dilakukan perencanaan dan pemodelan secara cepat berupa rancangan cepat(quick design) dan kemudian akan memulai konstruksi pembuatan prototype
• Prototipe kemudian akan diserahkan kepada para stakeholder untuk dilakukan evaluasi lebih lanjut sebelum diserahkan kepada para pembuat software
• Pembuatan software sesuai dengan prototype yang telah dievaluasi yang kemudian akan diserahkan kepada pelanggan
• Jika belum memenuhi kebutuhan dari pelanggan maka akan kembali ke proses awal sampai dengan kebutuhan dari pelanggan telah terpenuhi

Sedangkan proses-proses dalam model prototyping secara umum adalah sebagai berikut:

1. Pengumpulan kebutuhan
developer dan klien akan bertemu terlebih dahulu dan kemudian menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya

2. Perancangan
Perancangan dilakukan dengan cepat dan rancangan tersebut mewakili semua aspek software yang diketahui, dan rancangan ini menjadi dasar pembuatan prototype

3. Evaluasi Prototype
Klien akan mengevaluasi prototype yang dibuat dan digunakan untuk memperjelas kebutuhan software.

B. Tahapan

Selain itu, untuk memodelkan sebuah perangkat lunak dibutuhkan beberapa tahapan di dalam proses pengembangannya. Tahapan inilah yang akan menentukan keberhasilan dari sebuah softwareitu .Pengembang perangkat lunak harus memperhatikan tahapan dalam metode prototyping agar software finalnya dapat diterima oleh penggunanya. Dan tahapan-tahapan dalam prototyping tersebut adalah sebagai berikut :

1. Pengumpulan kebutuhan
Pelanggan dan pengembang bersama-sama mendefinisikan format dan kebutuhan kesseluruhan perangkat lunak, mengidentifikasikan semua kebutuhan, dan garis besar sistem yang akan dibuat.

2. Membangun prototyping
Membangun prototyping dengan membuat perancangan sementara yang berpusat pada penyajian kepada pelanggan (misalnya dengan membuat input dan contoh outputnya).

3. Evaluasi protoptyping
Evaluasi ini dilakukan oleh pelanggan apakah prototyping yang sudah dibangun sudah sesuai dengan keinginan pelanggan. Jika sudah sesuai maka langkah keempat akan diambil. Jika tidak, maka prototyping diperbaiki dengan mengulang langkah 1, 2 , dan 3.

4. Mengkodekan system
Dalam tahap ini prototyping yang sudah disepakati diterjemahkan ke dalam bahasa pemrograman yang sesuai.

5. Menguji system
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 sudah, maka langkah ketujuh dilakukan, jika belum maka mengulangi langkah 4 dan 5.

7. Menggunakan system
Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk digunakan

C. Keunggulan dan kelemahan metode prototype

Keunggulan prototyping :

• Komunikasi akan terjalin baik antara pengembang dan pelanggan.
• Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan setiap pelanggannya.
• Pelanggan berperan aktif dalam proses pengembangan sistem.
• Lebih menghemat waktu dalam pengembangan sistem.
• Penerapan menjadi lebih mudah karena pemakai mengetahui apa yang diharapkannya

Kelemahan prototyping :

• 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.
• 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 sebuah kerangka kerja(blueprint) dari sistem .
• Hubungan pelanggan dengan komputer yang disediakan mungkin tidak mencerminkan teknik perancangan yang baik dan benar.

Dalam setiap metode mempunyai kelebihan maupun kekurangan, namun kekurangan tersebut dapat diminimalisir yaitu dengan mengetahui kunci dari model prototype tersebut. 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.

SUMBER : http://hardlogicom.blog.widyatama.ac.id/2015/02/15/proses-rekayasa-perangkat-lunak-menggunakan-model-prototype/

3. Model Spiral 

Model ini cukup baru ditemukan,yaitu tahun 1988 oleh Barry Boehm. Spiral adalah salah satu bentuk evolusi yang menggunakan metode iterasi natural yang dimiliki oleh model prototyping dan digabungkan dengan aspek sistematis yang dikembangkan model waterfall.

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 :

1. Customer communication.Aktivitas yang dibutuhkan untuk membangun komunikasi yang efektif antara developer dengan user / customer terutama mengenai kebutuhan dari customer.
2. Planning.Aktivitas perencanaan ini dibutuhkan untuk menentukan sumberdaya, perkiraan waktu pengerjaan, dan informasi lainnya yang dibutuhkan untuk pengembangan software.
3. 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.
4. Engineering.Aktivitas yang dibutuhkan untuk membangun 1 atau lebih representasi dari aplikasi secara teknikal.
5. 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.
6. 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.

Adapun beberapa Kelebihan dan Kelemahan Model Spiral yang ada:

Kelebihan model Spiral :

• Dapat disesuaikan agar perangkat lunak bisa dipakai selama hidup  perangkat lunak komputer.
• Lebih cocok untuk pengembangan sistem dan perangkat lunak skala besar
• Pengembang dan pemakai dapat lebih mudah memahami dan bereaksi terhadap resiko setiap   tingkat evolusi karena perangkat lunak terus bekerja selama proses

Kelemahan model Spiral:

• Sulit untuk menyakinkan pelanggan bahwa pendekatan evolusioner ini bisa dikontrol.
• Memerlukan penaksiran resiko yang masuk akal dan akan menjadi masalah yang serius jika resiko mayor tidak ditemukan dan diatur.
• Butuh waktu lama untuk menerapkan paradigma ini menuju kepastian yang absolute

SUMBER : http://blogs.unpas.ac.id/faisallirfan/model-proses-pengembangan-rpl/

4. Rekayasa perangkat lunak (Model 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).

 Kelebihan Penggunaan Model RAD

• Dimungkinkan dalam proses pembuatan membutuhkan waktu yang sangat singkat (60-90 hari).
• Menghemat biaya, karena penekannya adalah penggunaan komponen-komponen yang sudah ada.
• RAD menggunakan kembali komponen-komponen yang sudah ada, maka beberapa komponen program sudah diuji sehingga kita dapat melakukan penghematan waktu dalam uji coba

Kekurangan Penggunaan Model RAD

• Seperti semua proses model yang lain, pendekatan RAD memiliki kekurangan-kekurangan sebagi berikut.
• Bagi proyek yang besar tetapi berskala, RAD memerlukan sumber daya manusia yang memadai untuk menciptakan jumlah tim RAD yang baik.
•  RAD menuntut pengembangan dan pelanggan yang memiliki komitmen di dalam aktifitas rapid-fire yang diperlukan untuk melengkapi sebuah sistem, di dalam kerangka waktu yang sangat diperpendek. Jika komitmen tersebut tidak ada, proyek RAD akan gagal. RAD menekankan perkembangan komponen program yang bisa dipakai kembali. Reusable menjadi batu pertama teknologi objek dan ditemui di dalam proses rakitan komponen
• Tidak semua aplikasi sesuai untuk RAD. Bila sistem tidak dapat dimodulkan dengan teratur, pembangunan komponen penting pada RAD akan menjadi sangat problematis.
• RAD menjadi tidak sesuai jika risiko teknisnya tingggi. Hal ini terjadi bila sebuah aplikasi baru memforsir teknologi baru atau bila perangkat lunak baru membutuhkan tingkat interoperabilitas yang tinggi dengan program komputer yang ada.

SUMBER : http://blogs.unpas.ac.id/faisallirfan/model-proses-pengembangan-rpl/

5. Rekayasa perangkat lunak RUP (Rational Unified Process)

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.

RUP Online

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. Rekayasa perangkat lunak (Extreme Programming (XP) Model)

Model proses ini diciptakan dan dikembangkan oleh Kent Beck. Model ini adalah model proses yang terbaru dalam dunia rekayasa perangkat lunak dan mencoba menjawab kesulitan dalam pengembangan software yang rumit dan sulit dalam implementasi. Menurut Kent Beck XP adalah : “A lightweight, efficient, low-risk, flexible,predictable, scientific and fun way to develop software”. Suatu model yang menekankan pada:

► keterlibatan user secara langsung

► pengujian

► pay-as-you-go design

Adapun empat nilai penting dari XP :

1. Communication/Komunikasi : komunikasi antara developer dan klien sering menjadi masalah. Karena itu komunikasi dalam XP dibangun dengan melakukan pemrograman berpasangan (pair programming). Developer didampingi oleh pihak klien dalam melakukan coding dan unit testing sehingga klien bisa terlibat langsung dalam pemrograman sambil berkomunikasi dengan developer. Selain itu perkiraan beban tugas jugadiperhitungkan.
2. Simplicity/ sederhana: Menekankan pada kesederhanaan dalam pengkodean: “What is the simplest thing that could possibly work?” Lebih baik melakukan hal yang sederhana dan mengembangkannya besok jika diperlukan. Komunikasi yang lebih banyak mempermudah, dan rancangan yang sederhana mengurangi penjelasan.
3. Feedback / Masukan/Tanggapan: Setiap feedback ditanggapi dengan melakukan tes, unit test atau system integration dan jangan menunda karena biaya akan membengkak (uang, tenaga, waktu).
4. Courage / Berani: Banyak ide baru dan berani mencobanya, berani mengerjakan kembali dan setiap kali kesalahan ditemukan, langsung diperbaiki.

SUMBER : http://komandankempong.blogspot.co.id/2011/09/model-proses-rekayasa-perangkat-lunak.html