TUGAS MANDIRI RPL


Model Waterfall

Sejarah Model Waterfall

            Model Waterfall ini awalnya ditemukan oleh Winston W. Royce pada tahun 1970 . Dia menulis sebuah artikel ilmiah yang berisi pandangan pribadinya pada pengembangan perangkat lunak . Pada paruh pertama dari artikel, ia membahas sebuah proses yang dia sebut ” megah ” . Dia bahkan menggambar sosok model , dan lain yang menunjukkan mengapa hal itu tidak bekerja ( karena persyaratan selalu berubah ) . Model ini adalah air terjun . Dia menggunakannya sebagai contoh dari proses yang sama sekali tidak bekerja. Di paruh kedua artikel ia menggambarkan proses berulang-ulang bahwa ia dianggap jauh lebih baik .

Nama model ini sebenarnya adalah “Linear Sequential Model”. Model ini sering disebut dengan “classic life cycle” atau model waterfall. Model ini 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.


Pengertian Waterfall

            Waterfall atau sering juga disebut air terjun adalah sebuah metode dalam pengembangan sistem yang dilakukan untuk membuat pembaruan sistem yang berjalan.


            Menurut Buku Rosa 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 :
            DesainPengodeanPengujianAnalisisSistem/Rekayasa Informasi

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. Contoh desain sistem salah satunya adalah seperti Artikel saya yang berikut ini : Pengertian dan Contoh Class Diagram dengan Edraw max

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 dan tahap pendukung(Support)
            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. 
Kelebihan Metode Waterfall
            Kelebihan menggunakan metode air terjun (waterfall) adalah metode ini memungkinkan untuk departementalisasi dan kontrol. proses pengembangan model fase one by one, sehingga meminimalis kesalahan yang mungkin akan terjadi. Pengembangan bergerak dari konsep, yaitu melalui desain, implementasi, pengujian, instalasi, penyelesaian masalah, dan berakhir di operasi dan pemeliharaan.

Kekurangan Metode Waterfall
            Kekurangan menggunakan metode waterfall adalah metode ini tidak memungkinkan untuk banyak revisi jika terjadi kesalahan dalam prosesnya. Karena setelah aplikasi ini dalam tahap pengujian, sulit untuk kembali lagi dan mengubah sesuatu yang tidak terdokumentasi dengan baik dalam tahap konsep sebelumnya.

Referensi
http://tarmo.fi/blog/2005/09/dont-draw-diagrams-of-wrong-practices-or-why-people-still-believe-in-the-waterfall-model/
http://dikaseba.blogspot.co.id/2017/02/waterfall.html/

http://www.pengetahuandanteknologi.com/2016/09/metode-waterfall-definisi-tahapan.html



Model Rapid Application Development (RAD)

Pengertian
            Rapid application development  (RAD) atau rapid prototyping adalah model proses pembangunan perangkat lunak yang tergolong dalam teknik incremental (bertingkat). RAD menekankan pada siklus pembangunan pendek, singkat, dan cepat. Waktu yang singkat adalah batasan yang penting untuk model ini. Rapid application development menggunakan metode iteratif (berulang) dalam mengembangkan sistem dimana working model (model bekerja) sistem dikonstruksikan di awal tahap pengembangan dengan tujuan menetapkan kebutuhan (requirement) user dan selanjutnya disingkirkan. Working model digunakan kadang-kadang saja sebagai basis desain dan implementasi sistem final.


Sejarah
            Rapid Application Development ( RAD ) adalah istilah awalnya digunakan untuk menggambarkan proses pengembangan perangkat lunak pertama kali dikembangkan dan berhasil digunakan selama pertengahan 1970-an oleh Sistem Pusat Pengembangan New York Telephone Co di bawah arahan Dan Gielan. Setelah serangkaian implementasi sangat berhasil dari proses ini, Gielan kuliah secara ekstensif di berbagai forum pada metodologi , praktek, dan manfaat dari proses ini.

            RAD melibatkan pengembangan dan pembangunan prototipe iteratif . Pada tahun 1990, dalam buku RAD, Rapid Application Development, James Martin didokumentasikan penafsirannya tentang metodologi. Baru-baru ini, istilah dan singkatan yang telah datang untuk digunakan dalam lebih luas, pengertian umum yang mencakup berbagai metode yang bertujuan untuk mempercepat pengembangan aplikasi, seperti penggunaan kerangka perangkat lunak dari berbagai jenis, seperti kerangka kerja aplikasi web.

            Pengembangan aplikasi yang cepat merupakan respon terhadap proses yang dikembangkan pada 1970-an dan 1980-an, seperti Structured Sistem Metode Analisis dan Desain dan model Waterfall lainnya. Satu masalah dengan metodologi sebelumnya adalah bahwa aplikasi begitu lama untuk membangun bahwa persyaratan telah berubah sebelum sistem itu selesai, sehingga sistem tidak memadai atau bahkan tidak dapat digunakan. Masalah lain adalah asumsi bahwa persyaratan metodis tahap analisis saja akan mengidentifikasi semua persyaratan penting. Membuktikan fakta bahwa ini adalah jarang terjadi, bahkan untuk proyek-proyek dengan profesional yang sangat berpengalaman di semua tingkatan.

            Dimulai dengan ide-ide dari Brian Gallagher, Alex Balchin, Barry Boehm dan Scott Shultz, James Martin mengembangkan pendekatan pengembangan aplikasi yang cepat selama tahun 1980 di IBM dan akhirnya diresmikan itu dengan menerbitkan sebuah buku pada tahun 1991, Rapid Application Development.

Fase dan Tahapan Pengembangan Aplikasi
            Menurut Kendall (2010), terdapat tiga fase dalam RAD yang melibatkan penganalisis dan pengguna dalam tahap penilaian, perancangan, dan penerapan. Adapun ketiga fase tersebut adalah requirements planning (perencanaan syarat-syarat), RAD design workshop (workshop desain RAD), dan implementation (implementasi). Sesuai dengan metodologi RAD menurut Kendall (2010), berikut ini adalah tahap-tahap pengembangan aplikasi dari tiap-tiap fase pengembangan aplikasi :

1)      Requirements Planning (Perencanaan Syarat-Syarat)
Dalam fase ini, pengguna dan penganalisis bertemu untuk mengidentifikasikan tujuan-tujuan aplikasi atau sistem serta untuk megidentifikasikan syarat-syarat informasi yang ditimbulkan dari tujuan-tujuan tersebut. Orientasi dalam fase ini adalah menyelesaikan masalah-masalah perusahaan. Meskipun teknologi informasi dan sistem bisa mengarahkan sebagian dari sistem yang diajukan, fokusnya akan selalu tetap pada upaya pencapaian tujuan-tujuan perusahaan (Kendall, 2010).
2)      RAD Design Workshop (Workshop Desain RAD)
Fase ini adalah fase untuk merancang dan memperbaiki yang bisa digambarkan sebagai workshop. Penganalisis dan dan pemrogram dapat bekerja membangun dan menunjukkan representasi visual desain dan pola kerja kepada pengguna. Workshop desain ini dapat dilakukan selama beberapa hari tergantung dari ukuran aplikasi yang akan dikembangkan. Selama workshop desain RAD, pengguna merespon prototipe yang ada dan penganalisis memperbaiki modul-modul yang dirancang berdasarkan respon pengguna. Apabila sorang pengembangnya merupakan pengembang atau pengguna yang berpengalaman, Kendall menilai bahwa usaha kreatif ini dapat mendorong pengembangan sampai pada tingkat terakselerasi (Kendall, 2010).
3)      Implementation (Implementasi)
Pada fase implementasi ini, penganalisis bekerja dengan para pengguna secara intens selama workshop dan merancang aspek-aspek bisnis dan nonteknis perusahaan. Segera setelah aspek-aspek ini disetujui dan sistem-sistem dibangun dan disaring, sistem-sistem baru atau bagian dari sistem diujicoba dan kemudian diperkenalkan kepada organisasi (Kendall, 2010).

TAHAPAN-TAHAPAN DALAM RAD

RAD di gunukan pada aplikasi system konstruksi, maka menekankan fase-fase. Ada Tiga Fase dalam RAD yaitu :

1.      REQUIREMENT PLANING, dalam tahap ini di ketahui apa saja yang menjadi kebutuhan system yaitu dengan mengidentifikasikan kebutuhan informasi dan masalah yang di hadapi untuk menentukan tujuan, batasan –batasan system, kendala dan juga alternative pemecahan masalah analisis di gunakan untuk mengetahui perilaku system dan juga untuk mengetahui aktifitas apa saja yang ada dalam system tersebut.
2.      DESIGN WORKSHOP, yaitu mengidentifikasi solusi alternative dan memilih solusi yang terbaik. Kemudian membuat design proses bisnis dan design pemrograman untuk data-data yang telah di dapatkan dan di modelkan dalam arsitektur system informasi.
3.      IMPLENTATION, setelah design workshop di lakukan, selanjutnya system di implikasikan (coding) ke dalam bentuk yang di mengerti oleh mesin yang di wujudkan dalam bentuk program atauunit program.

KEUNTUNGAN RAD
Beberapa keuntungan dalam menggunakan metode RAD adalah sebagai berikut:
– Membeli sistem yang baru memungkinkan untuk lebih menghemat biaya ketimbang mengembangkan sendiri.
– Proses pengiriman menjadi lebih mudah, hal ini dikarenakan proses pembuatan lebih banyak menggunakan potongan-potongan script.
– Mudah untuk diamati karena menggunakan model prototype, sehingga user lebih mengerti akan sistem yang dikembangkan.
– Lebih fleksibel karena pengembang dapat melakukan proses desain ulang pada saat yang bersamaan.
– Bisa mengurangi penulisan kode yang kompleks karena menggunakan wizard.
– Keterlibatan user semakin meningkat karena merupakan bagian dari tim secara keseluruhan.
– Mampu meminimalkan kesalahan-kesalahan dengan menggunakan alat-alat bantuan (CASE tools).
– Mempercepat waktu pengembangan sistem secara keseluruhan karena cenderung mengabaikan kualitas.
– Tampilan yang lebih standar dan nyaman dengan bantuan software-software pendukung.

KERUGIAN RAD
Beberapa kerugian dalam menggunakan metode RAD adalah sebagai berikut :
– Dengan melakukan pembelian belum tentu bisa menghemat biaya dibandingkan dengan mengembangkan sendiri.
– Membutuhkan biaya tersendiri untuk membeli peralatan-peralatan penunjang seperti misalnya software dan hardware.
– Kesulitan melakukan pengukuran mengenai kemajuan proses.
– Kurang efisien karena apabila melakukan pengkodean dengan menggunakan tangan bisa lebih efisien.
– Ketelitian menjadi berkurang karena tidak menggunakan metode yang formal dalam melakukan pengkodean.
– Lebih banyak terjadi kesalahan apabila hanya mengutamakan kecepatan dibandingkan dengan biaya dan kualitas.
– Fasilitas-fasilitas banyak yang dikurangi karena terbatasnya waktu yang tersedia.
– Sistem sulit diaplikasikan di tempat yang lain.
– Fasilitas yang tidak perlu terkadang harus disertakan, karena menggunakan komponen yang sudah jadi, sehingga hal ini membuat biaya semakin meningkat.


Referensi


https://piyaneo.wordpress.com/2014/05/10/rapid-application-development-rad/
http://ilhamajji.blogspot.co.id/2014/11/tentang-rad-rapid-application.html
http://rizalloa.ilearning.me/?p=133



Model Spiral

Sejarah Model 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.

Pengertian Model 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.

Tahapan-Tahapan Model Spiral


            Model spiral dibagi menjadi enam wilayah tugas yaitu:

1. Komunikasi pelanggan  
            Yaitu tugas-tugas untuk membangun komunikasi antara pelanggan dan kebutuhankebutuhan yang diinginkan oleh pelanggan


2. Perencanaan
            Yaitu tugas-tugas untuk mendefinisikan sumber daya, ketepatan waktu, dan proyek
    informasi lain yg berhubungan.


3. Analisis Resiko
            Yaitu tugas-tugas yang dibutuhkan untuk menaksir resikomanajemen dan teknis.


4. Perekayasaan
            Yaitu tugas yang dibutuhkan untuk membangun satu atau lebih representasi dari
    apikasi tersebut.


5. Konstruksi dan peluncuran
            Yaitu tugas-tugas yang dibutuhkan untuk mengkonstruksi, menguji, memasang , dan
    memberi pelayanan kepada pemakai.


6. Evaluasi Pelanggan
            Yaitu tugas-tugas untuk mendapatkan umpan balik dari pelanggan.


Kelebihan dan Kelemahan Model Spiral

Kelebihan model Spiral :

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


Kekurangan
1.Waktu yang dibutuhkan untuk mengembangkan perangkat lunak cukup panjang demikian juga biaya yang besar.
2. Sangat tergantung kepada tenaga ahli yang dapat memperkirakan resiko.
3. Terdapat pula kesulitan untuk mengontrol proses. Sampai saat ini, karena masih relatif baru, belum ada bukti apakah metode ini cukup handal untuk diterapkan.
4. Meyakinkan konsumen (khusunya dalam situasi kontrak) bahwa pendekatan evolusioner bisa dikontrol.

Referensi


http://imanaanggreani.blogspot.co.id/2014/06/metode-pengembangan-perangkat-lunak.html
http://saifulmubin.blogspot.co.id/2011/02/model-spiral.html


Model Prototipe

     Sebuah prototipe adalah bagian dari produk yang mengekspresikan logika maupun fisik antarmuka eksternal yang ditampilkan. Konsumen potensial menggunakan prototipe dan menyediakan masukan untuk tim pengembang sebelum pengembangan skal besar dimulai. Melihat dan mempercayai menjadi hal yang diharapkan untuk dicapai dalam prototipe. Dengan menggunakan pendekatan ini, konsumen dan tim pengembang dapat mengklarifikasi kebutuhan dan interpretasi mereka.
     Prototyping perangkat lunak (software prototyping) atau siklus hidup menggunakan protoyping (life cycle using prototyping) adalah salah satu metode siklus hidup sistem yang didasarkan pada konsep model bekerja (working model). Tujuannya adalah mengembangkan model menjadi sistem final. Artinya sistem akan dikembangkan lebih cepat dari pada metode tradisional dan biayanya menjadi lebih rendah. Ada banyak cara untuk memprotoyping, begitu pula dengan penggunaannya. Ciri khas dari metodologi ini adalah pengembang sistem (system developer), klien, dan pengguna dapat melihat dan melakukan eksperimen dengan bagian dari sistem komputer dari sejak awal proses pengembangan.
     Dengan prototype yang terbuka, model sebuah sistem (atau bagiannya) dikembangkan secara cepat dan dipoles dalam diskusi yang berkali-kali dengan klien. Model tersebut menunjukkan kepada klien apa yang akan dilakukan oleh sistem, namun tidak didukung oleh rancangan desain struktur yang mendetil. Pada saat perancang dan klien melakukan percobaan dengan berbagai ide pada suatu model dan setuju dengan desain final, rancangan yang sesungguhnya dibuat tepat seperti model dengan kualitas yang lebih bagus.
     Protoyping membantu dalam menemukan kebutuhan di tahap awal pengembangan,terutama jika klien tidak yakin dimana masalah berasal. Selain itu protoyping juga berguna sebagai alat untuk mendesain dan memperbaiki user interface – bagaimana sistem akan terlihat oleh orang-orang yang menggunakannya.
     Salah satu hal terpenting mengenai metodologi ini, cepat atau lambat akan disingkirkan dan hanya digunakan untuk tujuan dokumentasi. Kelemahannya adalah metode ini tidak memiliki analisa dan rancangan yang mendalam yang merupakan hal penting bagi sistem yang sudah kokoh, terpercaya dan bisa dikelola. Jika seorang pengembang memutuskan untuk membangun jenis prototipe ini, penting untuk memutuskan kapan dan bagaimana ia akan disingkirkan dan selanjutnya menjamin bahwa hal tersebut telah diselesaikan tepat pada waktunya.


Tujuan Prototyping
            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


Kelebihan Metode Prototyping
            Kelebihan metode prototyping yang paling utama adalah merupakan salah satu jenis metode pengembangan sistem yang sifatnya sangat cepat dan dapat menghemat waktu. Berbeda dengan pengembangan sistem menggunakan metode waterfall yang membutuhkan banyak biaya dan memakan waktu. Maka bagi user yang membutuhkan sebuah sistem dalam jangka waktu yang sangat singkat, bisa mengandalkan metode pengembangan sistem prototyping ini
            Selain itu, metode prototyping juga memilki beberapa kelebihan lainnya, seperti :
1.      Dapat menjalin komunikasi yang baik antar user dan pengembang sistem
2.      Setiap perbaikan yang dilakukan pada prototype merupakan hasil masukan dari user yang akan menggunakan sistem tersebut, sehingga lebih reliabel
3.      User akan memberikan masukan terhadap sistem sesuai dengan kemauannya
4.      Menghemat waktu dalam mengembangkan sebuah sistem
5.      Menghemat biaya, terutama pada bagian analisa, karena hanya mencatat poin – point penting saja
6.      Cocok digunakan pada sebuah sistem kecil, yang digunakan pada ruang lingkup tertentu, seperti sistem di dalam sebuah kantor
7.      Penerapan dari sistem yang menjadi lebih mudah untuk dilakukan.

Kelemahan dari Metode Prototyping
            Beberapa kelemahan dan juga kekurangan dari metode prototyping antara lain:
  1.Untuk menghemat waktu, biasanya pengembang hanya menggunakan bahasa pemrograman sederhana, yang mungkin rentan dari segi keamanannya
  2.   Tidak cocok untuk diimplementasikan pada sebuah sistem yang sangat besar dan global, seperti sistem operasi komputer.
   3.       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.
 4.    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 .
 5.    Hubungan pelanggan dengan komputer yang disediakan mungkin tidak mencerminkan teknik perancangan yang baik dan benar.

Referensi

http://rizalloa.ilearning.me/?p=132

http://hardlogicom.blog.widyatama.ac.id/2015/02/15/proses-rekayasa-perangkat-lunak-menggunakan-model-prototype/
http://dosenit.com/kuliah-it/teknologi-informasi/kelebihan-dan-kekurangan-metode-prototyping


MODEL RUP (Rational Unified Process)
           
            Menurut Philippe Kruchten dalam bukunya yang berjudul ” The Rational Unified Process: An Introduction (2nd Edition)”  The Rational Unified Process is a software engineering process. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end users within a predictable schedule and budget.”
             “RUP adalah proses rekayasa perangkat lunak. Ini 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 dalam jadwal diprediksi dan budget.”
            Sedangkan menurut  Aswin dalam websitenya http://blog.unsri.ac.id/aswin/  “ Rational Unified Process adalah salah satu proses perekayasaan perangkat lunak yang mencakup keseluruhan siklus hidup pengembangan perangkat lunak dengan mengumpulkan berbagai latihan terbaik yang terdapat dalam pengembagan perangkat lunak.”
            Kemudian menurut Margaret Rouse dalam blognya http://searchsoftwarequality.techtarget.com/definition/Rational-Unified-Process “ Rational Unified Process (RUP) is an object-oriented and Web-enabled program development methodology. According to Rational (developers of Rational Rose and the Unified Modeling Language), RUP is like an online mentor that provides guidelines, templates, and examples for all aspects and stages of program development. RUP and similar products — such as Object-Oriented Software Process (OOSP), and the OPEN Process — are comprehensive software engineering tools that combine the procedural aspects of development (such as defined stages, techniques, and practices) with other components of development (such as documents, models, manuals, code, and so on) within a unifying framework.”
             “RUP adalah seperti sebuah mentor online yang menyediakan pedoman, templates, dan contoh untuk semua aspek dan tahap pengembangan program. Rup dan produk sejenis – seperti proses object-oriented perangkat lunak ( oosp ), — adalah perekayasaan piranti lunak secara komprehensif dengan tools yang menggabungkan aspek prosedural pembangunan ( seperti yang didefinisikan tahap, teknik – teknik, dan praktek ) dengan komponen pembangun lainnya ( seperti dokumen, model, manual, kode, dan seterusnya ) dalam sebuah kerangka pemersatu.”
Dari ketiga orang diatas, memang terlihat pengertian yang berbeda beda, tetapi initinya tetaplah sama. Kalau menurut saya, setelah membaca dan memahami pengertian yang di tulis oleh ketiga orang tersebut.
            Menurut saya Rational Unified Process (RUP) adalah salah satu proses yang ada di Software Enginering atau Rekayasa Perangkat Lunak, yang didalamnya terdapat sebuah proses dimana Software itu dibuat dengan mengunakan metode atau cara yang terstruktur didalam sebuah tim atau organisasi, dengan tujuan menghasilkan produk software yang bermutu tinggi, tetntunya dalam schedule dan badget yang telah disepakati.
            Di dalam penjelasan dari ketiga sumber diatas, hampir semuanya sepakat, bahwa di dalam RUP terdapat 6 Praktek Pengembangan perangkat lunak modern terbaik, yaitu :
1.      Develop software iteratively.
2.      Manage requirements.
3.      Use component-based architectures.
4.      Visually model software.
5.      Continuously verify software quality.
6.      Control changes to software.
Selain enam Praktek tersebut, ada tiga feature yang penting pada Rational Unified Process yang tidak boleh diabaikan, antara lain :
1.      Peran dari use case dalam mengontrol aspek dalam pengembangan.
2.      Penggunaannya sebagai kerangka proses yang dapat dikhususkan dan diperluaskan oleh suatu organisasi yang mengadopsinya.
3.      Kebutuhan akan tools pengembangan perangkat lunak dalam mendukung proses.
            Kemudian ada tahap tahap yang harus dilakuan di RUP, berikut adalah tahapannya,
1. Insepsi
§  Merupakan tahap awal dari proses Rational Unified Process
§  Menentukan ruang lingkup objek
§  Membuat “business case”
§  Menjawab pertanyaan “apakah yang dikerjakan dapat menciptakaan ‘good business sense’ sehingga proyek dapat dijalankan”
2. Elaborasi
§  Merupakan tahapan kedua dalam perancangan perangkat lunak.
§  Menganalisa risiko dan berbagai persyaratan.
§  Menetapkan batasan-batasan pada perancangan perangkat lunak.
3. Konstruksi
§  Tahap ketiga dalam pengimplementasian perancangan perangkat lunak.
§  Melakukan sederatan iterasi.
§  Pada setiap iterasi juga melibatkan proses-proses seperti analisa, desain, implementasi, coding.
4. Transisi
§  Tahapan terakhir untuk instalasi, deployment, dan sosialisasi perangkat lunak.
§  Melaksanakan apa yang sudah dimodelkan menjadi suatu produk jadi.
§  Dalam tahap ini dilakukan fase seperti:
§  Performance testing
§  Membuat dokumentasi tambahan.
§  Membuat peluncuran produk ke komunitas pengguna.

            RUP menggunakan konsep object oriented, dengan aktifitas yang berfokus pada pengembangan model dengan menggunakan Unified Model Language(UML). Melalui gambar dibawah dapat dilihat bahwa RUP memiliki, yaitu: 

ƒ  Dimensi pertamadi gambarkan secara horizontal. Dimensi ini mewakili aspek-aspek dinamis dari pengembangan perangkat lunak. Aspek ini dijabarkan dalam tahapan pengembangan atau fase. Setiap fase akan memiliki suatu major milestoneyang menandakan akhir dari awal dari phase selanjutnya. Setiap phase dapat berdiri dari satu beberapa iterasi. Dimensi ini terdiri atas Inception,  Elaboration,  Construction, dan Transition. 

ƒ  Dimensi kedua digambarkan secara vertikal. Dimensi ini mewakili aspek-aspek statis dari proses pengembangan perangkat lunak yang dikelompokkan ke dalam beberapa disiplin. Proses pengembangan perangkat lunak yang dijelaskan kedalam beberapa disiplin terdiri dari empat elemen penting, yakni who is doing, what, howdan when. 
            Dimensi ini terdiri atas: 
Business Modeling, Requirement, Analysis and Design, Implementation, Test, 
Deployment, Configuration  dan Change Manegement, Project Management, Environtment.




            Pada penggunaan kedua standard tersebut diatas yang berorientasi obyek (Object Oriented) memiliki menfaat yakni:

1. improve productivity
standard ini dapat memanfaatkan kembali komponen-komponen yang telah tersedia/dibuat sehingga dapat meningkatkan produktifitas.

2. Deliver hight quality system
 kualltas sistem dapat informasi dapat ditingkatkan sebagai sistem yang telah dibuat pada komponen-komponen yang telah teruji (well -tested dan well -proven) sehingga dapat mempercepat delivery sistem informasi yang telah dibuat dengan kualitas yang tinggi.

3. Lower maintenance cost
Standard ini dapat membantu untuk meyakinkan dampak perubahan yang teralokasi dan masalah dapat dengan mudah terdeteksi sehingga hasilnya biaya pemeliharaan dapat dioptimalkan atau lebih rendah dengan pengembangan informasi tanpa standar yang jelas.

4. Facilitate reuse
Standard ini memiliki kamampuan yang mengembangkan komponen-komponen yang dapat digunakan kembali untuk pengembangan aplikasi yang lainnya.

5. Manage complexity
Standard ini mudah untuk mengatur dan monitor semua proses dari semua tahapan yang ada sehingga suatu pengembangan sistem informasi yang amat kompleks dapat dilakukan dengan aman sesuai dengan harapan semua manager proyek IT/IS yakni deliver good quality software within cost and schedule time and the users accepted.

Referensi
https://wahyueutomo.wordpress.com/2013/04/02/rational-unified-process/


https://riyansetiawan27.blogspot.co.id/2014/04/metode-rup-rational-unified-process.html


MODEL Extreme Programming

Extreme Programming (berikutnya akan disingkat sebagai XP) adalah sebuah pendekatan atau model pengembangan perangkat lunak yang mencoba menyederhanakan berbagai tahapan dalam proses pengembangan tersebut sehingga menjadi lebih adaptif dan fleksibel. XP bukan hanya berfokus pada coding tetapi meliputi seluruh area pengembangan perangkat lunak. XP mengambil pendekatan ‘ekstrim’ dalam iterative development.

Sejarah XP

Proyek pengembangan perangkat lunak yang dianggap sebagai yang pertama kali menerapkan extreme programming  adalah C3 (Chrysler Comprehensive Compensation) Project dari Chrysler. Proyek ini adalah proyek penggajian 10.000 karyawan Chrysler, terdiri dari kira-kira 2000 classdan 30.000 method. Proyek yang dimulai pertengahan dekade 90-an ini terancam gagal karena rumitnya sistem yang dibangun dan kegagalan pada saat testing. Chrysler kemudian menyewa Kent Beck, seorang pakar software engineering yang di kemudian hari dikenal sebagai pencetus awal dari XP, untuk menyelamatkan proyek tersebut. Beck bersama rekannya Ron Jeffries dengan kewenangan yang diberikan oleh Chrysler melakukan berbagai perubahan di C3 Project untuk membuatnya lebih efisien, adaptif, dan fleksibel. Hal yang paling penting bagi mereka adalah harus mampu memenuhi permintaan utama dari Chrysler, untuk melakukan launchingperangkat lunak tersebut dalam waktu tidak lebih dari dua tahun sejak saat Beck dikontrak.
Beck dan Jeffries pada akhirnya berhasil menyelesaikan target Chrysler dengan menerapkan berbagai metode dalam proses pengembangan perangkat lunak tersebut. Kumpulan metode inilah yang kemudian dikenal sebagai model atau pendekatan XP dalam pengembangan perangkat lunak. Begitu sederhananya metode-metode tersebut sehingga bagi orang yang belum menerapkan, XP terlihat sebagai kumpulan ide lama yang terlalu sederhana dan tidak akan memberikan efek apapun pada sebuah proyek pengembangan perangkat lunak.
Kent Beck sendiri mengakui dan menegaskan bahwa XP tidak selalu cocok untuk setiap proyek pengembangan perangkat lunak. Kelebihan XP adalah sesuai untuk digunakan pada proyek yang memiliki dynamic requirements. Proyek semacam ini memerlukan adaptasi cepat dalam mengatasi perubahan-perubahan yang terjadi selama proses pengembangan perangkat lunak. XP juga cocok untuk proyek dengan jumlah anggota tim tidak terlalu banyak (sekitar 10-20 orang) dan berada pada lokasi yang sama.

Nilai-nilai Dasar XP

            Berikut adalah nilai-nilai mendasar yang menjadi roh dari XP pada setiap tahapan proses pengembangan perangkat lunak:
1.      Communication
XP mengfokuskan pada hubungan komunikasi yang baik antar anggota tim. Para anggota tim harus membangun saling pengertian, mereka juga wajib saling berbagi pengetahuan dan keterampilan dalam mengembangkan perangkat lunak. Ego dari para programer yang biasaanya cukup tinggi harus ditekan dan mereka harus membuka diri untuk bekerjasama dengan programer lain dalam menuliskan kode program.
2.      Courage
Para anggota tim dan penanggungjawab pengembangan perangkat lunak harus selalu memiliki keyakinan dan integritas dalam melakukan tugasnya. Integritas ini harus selalu dijaga bahkan dalam kondisi adanya tekanan dari situasi sekitar (misalnya oleh klien atau pemilik perusahaan). Untuk dapat melakukan sesuatu dengan penuh integritas terlebih dahulu para anggota tim harus terlebih dahulu memiliki rasa saling percaya. Rasa saling percaya inilah yang coba dibangun dan ditanamkan oleh XP pada berbagai aspeknya.
3.      Simplicity
Lakukan semua dengan sederhana. Hal tersebut adalah salah satu nilai dasar dari XP. Gunakan method yang pendek dan simpel, jangan terlalu rumit dalam membuat desain, hilangkan fitur yang tidak ada gunanya, dan berbagai proses penyederhanaan lain akan selalu menjadi nilai utama dari setiap aspek XP.
4.      Feedback
Berikan selalu feedback kepada sesama anggota tim maupun pihak-pihak lain yang terlibat dalam pengembangan perangkat lunak. Utarakan selalu pikiran anda dan diskusikan kesalahan-kesalahan yang muncul selama proses pengembangan. Dengarkan selalu pendapat rekan yang lain, dengan adanya feedback inilah seringkali kita menyadari bagian mana yang salah atau bisa ditingkatkan lagi dari perangkat lunak yang dikembangkan.
5.      Quality Work
Semua nilai di atas berujung pada sebuah kondisi di mana kita melakukan pekerjaan dengan berkualitas. Dengan proses yang berkualitas maka implikasinya akan muncul pula perangkat lunak yang berkualitas sebagai hasil akhirnya.

Aspek Dasar XP

Aspek dasar XP terdiri dari berbagai teknik atau metode yang diterapkan Beck dan Jeffries pada C3 Project. Teknik-teknik tersebut dapat diamati pada gambar berikut ini:


1.      The Planning Game
Pendekatan XP dalam perencanaan sangat mirip dengan metode yang diterapkan pada RAD (Rapid Application Development). Proses pendek dan cepat, mengutamakan aspek teknik, memisahkan unsur bisnis dengan unsur teknis dan pertemuan intensif antara klien dengan developer. Pada XP proses ini menggunakan terminologi “game” karena Beck menyarankan untuk menggunakan teknik score card dalam menentukan requirements. Semakin sulit aspek teknis yang dibutuhkan semakin tinggi pula skor pada kartu rencana tersebut.
2.      Small Releases
Setiap release dilakukan dalam lingkup sekecil mungkin pada XP. Setiap developermenyelesaikan sebuah unit atau bagian dari perangkat lunak maka hasil tersebut harus segera dipresentasikan dan didiskusikan dengan klien. Jika memungkinkan untuk menerapkan unit tersebut pada perusahaan, hal itu juga dapat dilakukan sekaligus sebagai tes awal dari penerapan keseluruhan sistem. Kendati demikian hal ini tidak selalu perlu dilakukan karena harus dihitung terlebih dahulu sumberdaya yang dibutuhkan. Apakah lebih menguntungkan langsung melakukan tes terhadap unit tersebut atau melakukan tes setelah unit tersebut terintegrasi secara sempurna pada sistem.
3.      Metaphor
Metaphor pada dasarnya sama dengan arsitektur perangkat lunak. Keduanya menggambarkan visi yang luas terhadap tujuan dari pengembangan perangkat lunak. Beck sendiri seperti para penandatangan Agile Manifesto lainnya bercita-cita menyederhanakan proses pengembangan perangkat lunak yang saat ini sudah dianggap terlalu rumit. Arsitektur yang saat ini banyak berisi diagram dan kode semacam UML dianggap terlalu rumit untuk dimengerti, terutama oleh klien. Metaphor, walaupun mirip dengan arsitektur lebih bersifat naratif dan deskriptif. Dengan demikian diharapkan komunikasi antara klien dengan developer akan berlangsung lebih baik dan lancar dengan penggunaan metaphor.
4.      Simple Design
Sebagai salah seorang penandatangan Agile Manifesto, Beck adalah seorang yang tidak menyukai desain yang rumit dalam sebuah pengembangan perangkat lunak. Tidak heran jika dia memasukkan Simple Design sebagai salah satu unsur XP. Pada XP desain dibuat dalam lingkup kecil dan sederhana. Tidak perlu melakukan antisipasi terhadap berbagai perubahan di kemudian hari. Dengan desain yang simpel apabila terjadi perubahan maka membuat desain baru untuk mengatasi perubahan tersebut dapat dengan mudah dilakukan dan resiko kegagalan desain dapat diperkecil.
5.      Refactoring
Refactoring adalah salah satu aspek paling khas dari XP. Refactoring seperti didefinisikan oleh Martin Fowler adalah ”Melakukan perubahan pada kode program dari perangkat lunak dengan tujuan meningkatkan kualitas dari struktur program tersebut tanpa mengubah cara program tersebut bekerja”. Refactoring sendiri sangat sesuai untuk menjadi bagian XP karena Refactoringmengusung konsep penyederhanaan dari proses desain maupun struktur baris kode program. Dengan Refactoring tim pengembang dapat melakukan berbagai usaha untuk meningkatkan kualitas program tanpa kembali mengulang-ulang proses desain. Fowler adalah salah satu kolega dekat dari Kent Beck karena itu tidak mengherankan bahwa cara berpikir mereka terhadap proses pengembangan perangkat lunak sangat mirip satu dengan lainnya.
6.      Testing
XP menganut paradigma berbeda dalam hal tes dengan model pengembangan perangkat lunak lainnya. Jika pada pengembangan perangkat lunak lainnya tes baru dikembangkan setelah perangkat lunak selesai menjalani proses coding maka pada XP tim pengembang harus membuat terlebih dahulu tes yang hendak dijalani oleh perangkat lunak. Berbagai model tes yang mengantisipasi penerapan perangkat lunak pada sistem dikembangkan terlebih dahulu. Saat proses coding selesai dilakukan maka perangkat lunak diuji dengan model tes yang telah dibuat tersebut. Pengetesan akan jauh lebih baik apabila dilakukan pada setiap unit perangkat lunak dalam lingkup sekecil mungkin daripada menunggu sampai seluruh perangkat lunak selesai dibuat. Dengan memahami tahap ini kita dapat melihat bahwa siklus pada XP adalah requirement analysis à test à code à design. Sekilas terlihat hal ini tidak mungkin dilakukan tetapi pada kenyataannya memang gambaran inilah yang paling dapat menjelaskan tentang XP.
7.      Pair Programming
Pair programming adalah melakukan proses menulis program dengan berpasangan. Dua orang programer saling bekerjasama di komputer yang sama untuk menyelesaikan sebuah unit. Dengan melakukan ini maka keduanya selalu dapat berdiskusi dan saling melakukan koreksi apabila ada kesalahan dalam penulisan program. Aspek ini mungkin akan sulit dijalankan oleh para programer yang memiliki ego tinggi dan sering tidak nyaman untuk berbagi komputer bersama rekannnya.
8.      Collective Ownership
Tidak ada satupun baris kode program yang hanya dipahami oleh satu orang programer. XP menuntut para programer untuk berbagi pengetahuan untuk tiap baris program bahkan beserta hak untuk mengubahnya. Dengan pemahaman yang sama terhadap keseluruhan program, ketergantungan pada programer tertentu ataupun berbagai hambatan akibat perbedaan gaya menulis program dapat diperkecil. Pada level yang lebih tinggi bahkan dimungkinkan para programer dapat bertukar unit yang dibangunnya.
9.      Coding Standards
Pair programming dan collective ownership hanya akan dapat berjalan dengan baik apabila para programer memiliki pemahaman yang sama terhadap penulisan kode program. Dengan adanya coding standards yang telah disepakati terlebih dahulu maka pemahaman terhadap program akan menjadi mudah untuk semua programer dalam tim. Hal ini dapat diterapkan sebagai contoh pada penamaan variabel dan penggunaan tipe data yang sama untuk tiap elemen semua record atau array pada program.
10.   Continous Integration
Melakukan build setiap hari kerja menjadi sebuah model yang disukai oleh berbagai tim pengembang perangkat lunak. Hal ini terutama didorong oleh keberhasilan penerapan sistem ini oleh Microsoft dan telah sering dipublikasikan. Dengan melakukan build sesering mungkin berbagai kesalahan pada program dapat dideteksi dan diperbaiki secepat mungkin. Apabila banyak tim pengembang perangkat lunak meyakini bahwa build sekali sehari adalah minimum maka pada XP hal tersebut adalah maksimum. Pada XP tim disarankan untuk melakukan buildsesering mungkin misalnya setiap 4 jam atau bahkan lebih cepat lagi.
11.   40-hours Week
Beck berpendapat bekerja 8 jam sehari dan 5 hari seminggu adalah maksimal untuk tiap programer. Lebih dari itu programer akan cenderung membuat berbagai error pada baris-baris kode programnya karena kelelahan.
12.   On-Site Customer
Sebuah pendekatan klasik, di mana XP menganjurkan bahwa ada anggota dari klien yang terlibat pada proses pengembangan perangkat lunak. Yang lebih penting lagi ia harus ada di tempat pemrogaman dan turut serta dalam proses build dan test yang dilakukan. Apabila ada kesalahan dalam pengembangan diharapkan klien dapat segera memberikan masukan untuk koreksinya.

Kelebihan dan Kekurangan XP

Kelebihan :
  • Meningkatkan kepuasan kepada klien
  • Pembangunan system dibuat lebih cepat
  • Menjalin komunikasi yang baik dengan client.
  • Meningkatkan komunikasi dan sifat saling menghargai antar developer.
Kekurangan :
  • User story kemungkinan besar tidak lengkap sehingga Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima.
  • Tidak bisa membuat kode yang detail di awal (prinsip simplicity dan juga anjuran untuk melakukan apa yang diperlukan hari itu juga).
  • XP tidak memiliki dokumentasi formal yang dibuat selama pengembangan. Satu-satunya dokumentasi adalah dokumentasi awal yang dilakukan oleh user.
Referensi
http://ganiamanda.blog.widyatama.ac.id/2016/02/13/extreme-programming-xp-model/

Komentar

Posting Komentar