REKAYASA PERANGKAT LUNAK

     1.WATERFALL

PENEGRITAN Waterfall atau sering juga disebut air terjun adalah sebuah metode dalam pengembangan sistem yang dilakukan untuk membuat pembaruan sistem yang berjalan. 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.

Metode pengembangan sistem merupakan proses mengembangkan atau mengubah suatu sistem perangkat lunak dengan menggunakan metode-metode atau model-model yang digunakan orang untuk mengembangkan sitem-sistem perangkat lunak sebelumnya dengan memiliki alur hidup perangkat lunak secara sekuensial atau terurut dimulai dari analisis, desain, pengodean, pengujian, dan tahap pendukung (support).

Dan untuk gambarannya dapat di ilustrasikan seperti gambar berikut ini :

 

Penjelasan Alur Metode Waterfall

·         Analisis

Analisis atau analisa ini merupakan tahap awal yang dilakukan oleh peneliti dalam mengembangkan sistem. Dalam analisis ini harus mendapatkan beberapa hal yang dianggap menunjang penelitian yang dilakukan, seperti : mencari permasalahan yang ada, mengumpulkan data (data fisik, non fisik), wawancara dan lain-lain. Dalam tahap awal ini penulis dituntut untuk benar-benar melakukan penelitian yang terarah seperti contohnya untuk penelitian Teknik Informatika.

Untuk menentukan pokok permasalahan peneliti harus memilih terlebih dahulu permasalahan globalnya (misal : Jaringan), kemudian membagi lagi menjadi beberapa sub kecil (misal : pengiriman paket data), dan membagi kembali hingga tertuju pada titik fokus (misal : enkripsi data). 

·         Desain

Desain yang dimaksud bukan hanya tampilan atau interfacenya saja, tetapi yang dimaksud desain dalam metode ini adalah desain sistem yang meliputi : alur kerja sistem, cara pengoprasian sistem, hasil keluaran (output) dengan menggunakan metode-metode seperti UML (Unified Modeling Language) tampilan sistem dan lain-lain yang telah disesuaikan dengan analisis kebutuhan pada tahap awal untuk menyelesaikan permasalahan tersebut

Sehingga programmer atau pihak yang terlibat dalam pembuatan kode programs akan dipermudah karena sudah terarah seperti apa sistem ini akan berjalan dan seperti apa alur yang ada didalam sistem maupun diluar sistem.

·         Pengodean

Bagian pengodean merupakan bagian para programmer untuk memasukan script kode pemrograman kedalam sebuah software programming untuk menghasilkan aplikasi yang telah di desain, software programming yang dapat digunakan harus disesuaikan dengan desain sistem yang dibuat (misal : untuk ponsel, Desktop, Website, anginer dan lain-lain). Untuk software programming dapat menggunakan Borland C++, Dev C++, Delphi, Visual Basic, NetBeans dan lain-lain.

            ·         PENGUJIAN

Tahap ini adalah tahap pengujian dan tahap pendukung yang artinya sistem yang telah dibuat dari hasil analisis masalah yang telah melalui tahap-tahap desain, pengodean barulah masuk kedalam pengujian sistem, sehingga akan dapat diketahui seperti apa hasil kinerja sistem yang baru ini dibandingkan dengan sistem yang lama, kemudian dapat diketahui pula apakan dalam sistem yang baru ini masih ada kelemahan yang kemudian akan dikembangkan oleh peneliti berikutnya. 

KEUNTUNGAN METODE WATERFALL

§  Kualitas dari sistem yang dihasilkan akan baik. Ini dikarenakan oleh pelaksanaannya secara bertahap. Sehingga tidak terfokus pada tahapan tertentu.

§  Document pengembangan system sangat terorganisir, karena setiap fase harus terselesaikan dengan lengkap sebelum melangkah ke fase berikutnya. Jadi  setiap fase atau tahapan akan mempunyai dokumen tertentu.

§  Metode ini masih lebih baik digunakan walaupun sudah tergolong kuno, daripada menggunakan pendekatan asal-asalan. Selain itu, metode ini juga masih masuk akal jika kebutuhan sudah diketahui dengan baik.

KELEMAHAN

§  Diperlukan majemen yang baik, karena proses pengembangan tidak dapat dilakukan secara berulang sebelum terjadinya suatu produk.

§  Kesalahan kecil akan menjadi masalah besar jika tidak diketahui sejak awal pengembangan yang berakibat pada tahapan selanjutnya.

§  Pelanggan sulit menyatakan kebutuhan secara eksplisit sehingga tidak dapat mengakomodasi ketidak pastian pada saat awal pengembangan.

§  Pelanggan harus sabar, karena pembuatan perangkat lunak akan dimulai ketika tahap desain sudah selesai. Sedangkan pada tahap sebelum desain bisa memakan waktu yang lama.

§  Pada kenyataannya, jarang mengikuti urutan sekuensial seperti pada teori. Iterasi sering terjadi menyebabkan masalah baru.

REFERENSI:

http://dikaseba.blogspot.co.id/2017/02/waterfall.html

    

 2.  PROTOTYPING

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.

REFERENSI

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

    3.  SPIRAL

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.

Berikut adalah gambar dari spiral model secara umum :

KEUNTUNGAN

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

KEKURANGAN

• 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

REFERENSI

https://hansiaditya.wordpress.com/2007/09/25/spiral-model/

      4.     RAD (RAPID APLICATION MODEL)

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.

REFERENSI

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

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

 REFERENSI

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

http://cccoffe.blogspot.co.id/2014/09/rdp-rational-unified-process.html