Model - Model Rekayasa Perangkat Lunak

1. Rekayasa Perangkat Lunak (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. Berikut gambar model waterfall.

Gambar: Model Waterfall

Pengertian Waterfall

Waterfall adalah suatu metodologi pengembangan perangkat lunak yang mengusulkan pendekatan kepada perangkat lunak sistematik dan sekuensial yang mulai pada tingkat kemajuan sistem pada seluruh analisis, design, kode, pengujian dan pemeliharaan.

Langkah-langkah yang harus dilakukan pada metodologi Waterfall

1.   Requirement Analysis
Seluruh kebutuhan software harus bisa didapatkan dalam fase ini, termasuk didalamnya kegunaan       software yang diharapkan pengguna dan batasan software. Informasi ini biasanya dapat diperoleh melalui wawancara, survey atau diskusi. Informasi tersebut dianalisis untuk mendapatkan dokumentasi kebutuhan pengguna untuk digunakan pada tahap selanjutnya.
 

2.  System Design
Tahap ini dilakukan sebelum melakukan coding. Tahap ini bertujuan untuk memberikan gambaran apa yang seharusnya dikerjakan dan bagaimana tampilannya. Tahap ini membantu dalam menspesifikasikan kebutuhan hardware dan sistem serta mendefinisikan arsitektur sistem secara keseluruhan.
 

3.  Implementation
Dalam tahap ini dilakukan pemrograman. Pembuatan software dipecah menjadi modul-modul kecil yang nantinya akan digabungkan dalam tahap berikutnya. Selain itu dalam tahap ini juga dilakukan pemeriksaaan terhadap modul yang dibuat, apakah sudah memenuhi fungsi yang diinginkan atau belum.
 

4.  Integration & Testing
Di tahap ini dilakukan penggabungan modul-modul yang sudah dibuat dan dilakukan pengujian ini dilakukan untuk mengetahui apakah software yang dibuat telah sesuai dengan desainnya dan masih terdapat kesalahan atau tidak.
 

5.  Operation & Maintenance
Ini merupakan tahap terakhir dalam model waterfall. Software yang sudah jadi dijalankan serta dilakukan pemeliharaan. Pemeliharaan termasuk dalam memperbaiki  kesalahan yang tidak ditemukan pada langkah sebelumnya. Perbaikan implementasi unit sistem dan peningkatan jasa sistem sebagai kebutuhan baru.

Keuntungan  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 Waterfall

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

Kapan Model Waterfall digunakan?

Teori-teori lama menyimpulkan ada beberapa hal, yaitu:

1. Ketika semua persyaratan sudah dipahami dengan baik di awal pengembangan.
2. Definisi produk stabil dan tidak ada perubahan saat pengembangan untuk alasan apapun seperti perubahan eksternal, perubahan tujuan, perubahan anggaran atau perubahan teknologi. Untuk itu, teknologi yang digunakan pun harus sudah dipahami dengan baik.
3. Menghasilkan prswoduk baru, atau versi baru dari produk yang sudah ada. Sebenarnya, jika menghasilkan versi baru maka sudah masuk incremental development, yang setiap tahapnya sama dengan Waterfall kemudian diulang-ulang.
4. Porting produk yang sudah ada ke dalam platform baru.

Dengan demikian, Waterfall dianggap pendekatan yang lebih cocok digunakan untuk proyek pembuatan sistem baru. Tetapi salah satu kelemahan paling dasar adalah menyamakan pengembangan perangkat keras dengan perangkat lunak dengan meniadakan perubahan saat pengembangan. Padahal, diketahui saat perangkat lunak dijalankan, dan perubahan-perubahan akan sering terjadi.

Referensi :

 
http://tarmo.fi/blog/2005/09/dont-draw-diagrams-of-wrong-practices-or-why-people-still-believe-in-the-waterfall-model/
http://tonyjustinus.wordpress.com/2007/11/11/waterfall-process-model/

 2.Rekayasa Perangkat Lunak (Prototyping)

     

     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.

Tahapan-Tahapan Prototyping dan Kelebihannya              

Tahapan-tahapan dalam Prototyping adalah sebagai berikut:

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

2. Membangun prototyping
   Membangun prototyping dengan membuat perancangan sementara yang berfokus pada penyajian kepada pelanggan (misalnya dengan membuat input dan format output).

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

4. Mengkodekan sistem
   Dalam tahap ini prototyping yang sudah di sepakati diterjemahkan ke dalam bahasa pemrograman yang sesuai.

5. Menguji sistem
   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 ya, langkah 7 dilakukan; jika tidak, ulangi langkah 4 dan 5.

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

Model pengembangan ini (Prototyping Model) memiliki beberapa kelebihan, diantaranya :

• Adanya komunikasi yang baik antara pengembang dan pelanggan
• Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan pelanggan
• Pelanggan berperan aktif dalam pengembangan system
• Lebih menghemat waktu dalam pengembangan system
• Penerapan menjadi lebih mudah karena pemakai mengetahui apa yang diharapkannya
• membuat klien mendapat gambaran awal dari prototype

Membantu mendapatkan kebutuhan detil lebih baik

Implementasi Prototyping Model

     Metode prototyping sebagai suatu paradigma baru dalam pengembangan sistem informasi manajemen, tidak hanya sekedar suatu efolusi dari metode pengembangan sistem informasi yang sudah ada, tetapi sekaligus merupakan refolusi dalam pengembangan sistem informasi manajemen. Metode ini dikjatakan refolusi karena merubah proses pengembangan sistem informasi yang lama (SDLC).

     Menurut literatur, yang dimaksud dengan prototipe (prototype) adalah ”model pertama”, yang sering digunakan oleh perusahaan industri yang memproduksi barang secara masa. Tetapi dalam kaitannya dengan sistem informasi definisi kedua dari Webster yang menyebutkan bahwa ”prototype is an individual that exhibits the essential peatures of later type”, yang bila diaplikasikan dalam pengembangan sistem informasi manajemen dapat berarti bahwa Prototipe tersebut adalah sistem informasi yang menggambarkan hal-hal penting dari sistem informasi yang akan datang. Prototipe sistem informasi bukanlah merupakan sesuatu yang lengkap, tetapi sesuatu yang harus dimodifikasi kembali, dikembangkan, ditambahkan atau digabungkan dengan sistem informasi yang lain bila perlu.

     Dalam beberapa hal pengembangan software berbeda dengan produk-produk manufaktur, setiap tahap atau fase pengembangan sistem informasi merupakan bagian yang tidak terpisahkan dari seluruh proses yang harus dilakukan. Proses ini umumnya hanya untuk satu produk dan karakteristik dari produk tersebut tidak dapat ditentukan secara pasti seperti produk manufaktur, sehingga penggunaan ”model pertama” bagi pengembangan software tidaklah tepat. Istilah prototyping dalam hubungannya dengan pengembangan software sistem informasi manajemen lebih merupakan suatu proses bukan prototipe sebagai suatu produk.

     Sebagai contoh, pembuat mobil dapat mengembangkan sebuah purwarupa yang dapat digunakan dalam lintasan pengujuan khusus dan kemudian ditampilkan dalam showroom. Informasi yang diperoleh dari perlakuan seperti itu dapat digunakan untuk meningkatkan desain sebelum implementasi/produksi dilakukan secara massal.

Karakteristik metode prototyping
Ada empat langkah yang menjadi karakteristik metode prototyping yaitu :

1. Pemilahan Fungsi
   Mengacu pada pemilahan fungsi yang harus ditampilkan oelh prototyping. Pemilahan harus selalu dilakukan berdasarkan pada tugas-tugas yang relevan yang sesuai dengan contoh kasus yang akan dipergakan.
2. Penyusunan Sistem Informasi
   Bertujuan untuk memenuhi permintaan akan tersedianya prototype
3. Evaluasi
4. Penggunaan Selanjutnya

Referensi :

• http://www.scribd.com/doc/51770273/Model-Prototype-dalam-Rekayasa-Perangkat-Lunak
• http://id.wikipedia.org/wiki/Pengembangan_perangkat_lunak
• http://www.scribd.com/doc/58298607/Pengertian-Prototype
• http://zacha.blog.ugm.ac.id/2011/03/09/prototyping-model/
• http://www.willysaef.com/2011/10/29/memahami-fase-pengembangan-perangkat-lunak/
• http://fitraexact.blogspot.com/2013/08/tugas-i-paradigma-pengembangan.html

3. Rekayasa Perangkat Lunak (Spiral)

Pada artikel kali ini saya akan melanjutkan postingan tentang salah satu metode pengembangan perangkat lunak yaitu metode PRL SPIRAL. Model ini mengadaptasi dua model perangkat lunak yang ada yaitu model prototyping dengan pengulangannya dan model waterfall dengan pengendalian dan sistematikanya.  Model ini dikenal dengan sebutan Spiral Boehm. Pengembang dalam model ini memadupadankan beberapa model umum tersebut untuk menghasilkan produk khusus atau untuk menjawab persoalan-persoalan tertentu selama proses pengerjaan proyek.

Gambar 1. Model Spiral Boehm

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.

Model spiral dibagi menjadi sejumlah aktifitas kerangka kerja, disebut juga wilayah tugas, di antara tiga sampai enam wilayah tugas. Tahap-tahap model tersebut dapat dijelaskan secara ringkas sebagai berikut.

1. Tahap Liason: pada tahap ini membangun komunikasi yang efektif di antara pengembangan dan pelanggan.

2. Tahap Planning (perencanaan): pada tahap ini ditentukan sumber-sumber informasi, batas waktu dan informasi-informasi yang dapat menjelaskan proyek.

3. Tahap Analisis Resiko: mendefinisikan resiko, menentukan apa saja yang menjadi resiko baik teknis maupun manajemen.

4. Tahap Rekayasa (engineering): pembuatan prototipe atau pembangunan satu atau lebih representasi dari aplikasi tersebut

5. Tahap Konstruksi dan Pelepasan (release): pada tahap ini dilakukan pembangunan perangkat lunak yang dimaksud, diuji, diinstal dan diberikan sokongan-sokongan tambahan untuk keberhasilan proyek.

6. Tahap Evaluasi: Pelanggan/pemakai/pengguna biasanya memberikan masukan berdasarkan hasil yang didapat dari tahap engineering dan instalasi.

Dalam pengembangan sistem informasi berbasis web, model ini digunakan untuk menyelesaikan sistem secara global terlebih dahulu, kemudian untuk feature dari sistem akan dikembangkan kemudian. Dengan ini mempercepat dalam pengimplementasian project dan hal ini cocok digunakan dalam sistem informasi Web.

Kelebihan
 

1. Sangat mempertimbangkan resiko kemungkinan munculnya kesalahan sehingga sangat dapat diandalkan untuk pengembangan perangkat lunak skala besar.
 

2. Pendekatan model ini dilakukan melalui tahapan-tahapan yang sangat baik dengan menggabungkan model waterfall ditambah dengan pengulangan-pengulangan sehingga lebih realistis untuk mencerminkan keadaan sebenarnya.
 

3. Baik pengembang maupun pemakai dapat cepat mengetahui letak kekurangan dan kesalahan dari sistem karena proses-prosesnya dapat diamati dengan baik.

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.

Model Boehm sangat cocok diterapkan untuk pengembangan sistem dan perangkat lunak skala besar di mana pengembang dan pemakai dapat lebih mudah memahami kondisi pada setiap tahapan dan bereaksi terhadap kemungkinan terjadinya kesalahan. Selain itu, diharapkan juga waktu dan dana yang tersedia cukup memadai.

 Referensi:

http://roysarimilda.wordpress.com/2012/05/08/macam-macam-model-proses-rpl-dan-penyelesaian-kasus/

 

4. Rekayasa Perangkat Lunak (Rapid Application Development (RAD))

Rapid Application Development (RAD) adalah strategi siklus hidup yang ditujukan untuk menyediakan pengembangan yang jauh lebih cepat dan mendapatkan hasil dengan kualitas yang lebih baik dibandingkan dengan hasil yang dicapai melalui siklus tradisional (McLeod, 2002). RAD merupakan gabungan dari bermacam-macam teknik terstruktur dengan teknik prototyping dan teknik pengembangan joint application untuk mempercepat pengembangan sistem/aplikasi (Bentley, 2004). Dari definisi-definisi konsep RAD ini, dapat dilihat bahwa pengembangan aplikasi dengan menggunakan metode RAD ini dapat dilakukan dalam waktu yang relatif lebih cepat.

Pemaparan konsep yang lebih spesifik lagi dijelaskan oleh Pressman (2005) dalam bukunya, “Software Engineering: A Practition’s Approach”. Ia mengatakan bahwa RAD adalah proses model perangkat lunak inkremental yang menekankan siklus pengembangan yang singkat. Model RAD adalah sebuah adaptasi “kecepatan tinggi” dari model waterfall, di mana perkembangan pesat dicapai dengan menggunakan pendekatan konstruksi berbasis komponen. Jika tiap-tiap kebutuhan dan batasan ruang lingkup projek telah diketahui dengan baik, proses RAD memungkinkan tim pengembang untuk menciptakan sebuah “sistem yang berfungsi penuh” dalam jangka waktu yang sangat singkat. Dari penjelasan Pressman (2012) ini, satu perhatian khusus mengenai metodologi RAD dapat diketahui, yakni implementasi metode RAD akan berjalan maksimal jika pengembang aplikasi telah merumuskan kebutuhan dan ruang lingkup pengembangan aplikasi dengan baik.

Sedangkan menurut Kendall (2010), RAD adalah suatu pendekatan berorientasi objek terhadap pengembangan sistem yang mencakup suatu metode pengembangan serta perangkat-perangkat lunak. RAD bertujuan mempersingkat waktu yang biasanya diperlukan dalam siklus hidup pengembangan sistem tradisional antara perancangan dan penerapan suatu sistem informasi. Pada akhirnya, RAD sama-sama berusaha memenuhi syarat-syarat bisnis yang berubah secara cepat.

Siklus RAD

(Sumber: Kendall, 2010)

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

Kelebihan dan Kekurangan RAD

Metode pengembangan sistem RAD relatif lebih sesuai dengan rencana pengembangan aplikasi yang tidak memiliki ruang lingkup yang besar dan akan dikembangkan oleh tim yang kecil. Namun, RAD pun memiliki kelebihan dan kekurangannya sebagai sebuah metodoligi pengembangan aplikasi. Berikut ini adalah kelebihan metodologi RAD menurut Marakas (2006):

1. Penghematan waktu dalam keseluruhan fase projek dapat dicapai.
2. RAD mengurangi seluruh kebutuhan yang berkaitan dengan biaya projek dan sumberdaya manusia.
3. RAD sangat membantu pengembangan aplikasi yang berfokus pada waktu penyelesaian projek.
4. Perubahan desain sistem dapat lebih berpengaruh dengan cepat dibandingkan dengan pendekatan SDLC tradisional.
5. Sudut pandang user disajikan dalam sistem akhir baik melalui fungsi-fungsi sistem atau antarmuka pengguna.
6. RAD menciptakan rasa kepemilikan yang kuat di antara seluruh pemangku kebijakan projek.

Sedangkan, mengacu pada pendapat Kendall (2010), maka dapat diketahui bahwa kekurangan penerapan metode RAD adalah sebagai berikut:

1. Dengan metode RAD, penganalisis berusaha mepercepat projek dengan terburu-buru.
2. Kelemahan yang berkaitan dengan waktu dan perhatian terhadap detail. Aplikasi dapat diselesaikan secara lebih cepat, tetapi tidak mampu mengarahkan penekanan terhadap permasalahan-permasalahan perusahaan yang seharusnya diarahkan.
3. RAD menyulitkan programmer yang tidak berpengalaman menggunakan prangkat ini di mana programmer dan analyst dituntut untuk menguasai kemampuan-kemampuan baru sementara pada saat yang sama mereka harus bekerja mengembangkan sistem.

Referensi:

1.      Mc.,Leod, R. Jr. 2002. System Development: A Project Management Approach. New York: Leigh Publishing LLC.

2.      Whitten, J.L. & Bentley, L.D. 2004. System Analysis & Design Methods: Sixth Edition. New York: Mc.Graw-Hill.

3.      Pressman, R.S. 2012. Rekayasa Perangkat Lunak: Pendekatan Praktisi. Yogyakarta: Penerbit Andi.

4.      Marakas, G.M. 2006. System Analysis Design: an Active Approach. New York: Mc.Graw-Hill.

5.      Kendall, J.E. & Kendall, K.E. 2010. Analisis dan Perancangan Sistem. Jakarta: Indeks.

5. Rekayasa Perangkat Lunak (Rational Unified Process (RUP)

                RUP, singkatan dari Rational Unified Process, adalah suatu kerangka kerja proses pengembangan perangkat lunak iteratif yang dibuat oleh Rational Software, suatu divisi dari IBM sejak 2003. RUP bukanlah suatu proses tunggal dengan aturan yang konkrit, melainkan suatu kerangka proses yang dapat diadaptasi dan dimaksudkan untuk disesuaikan oleh organisasi pengembang dan tim proyek perangkat lunak yang akan memilih elemen proses sesuai dengan kebutuhan mereka.

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.

Fase RUP

1. Inception/insepsi

a. Menentukan Ruang lingkup proyek

b. Membuat 'Business Case'

c. Menjawab pertanyaan 'apakah yang dikerjakan dapat menciptakan 'good business sense' sehingga proyek dapat dilanjutkan

2.Elaboration/elaborasi

a. Menganalisa berbagai persyaratan dan resiko

b. Menetapkan 'Base line'

c. Merencanakan fase berikutnya yaitu construction

3. Construction/kontruksi

a. Melakukan sederetan iterasi

b. Pada setiap iterasi akan melibatkan prose berikut : analisa desain, implementasi dan testing

4. Transition/Transisi

a. Membuat apa yang sudah dimodelkan menjadi suatu produk jadi

b. Dalam fase ini dilakukan:

• Beta dan performance testing
• Membuat dokumentasi tambahan seperti: training, user guide dan sales kit
• Membuat rencana peluncuran produk ke komunitas pengguna

Peran Use Case Pada Setiap Fase

1. inception

• Menolong mengembangkan scope proyek
• Menolong menetapkan penjadwalan dan anggaran

2. Elaboration

• Menolong dalam melakukan analisa resiko
• Menolong mempersiapkan fase berikutnya yaitu konstruksi

3. Construction

• Melakukan sederetan iritasi
• Pada setiap iterasi akan melibatkan proses berikut: analisa desain, implementasi dan testing

4. Transition

• Membuat apa yang sudah dimodelkan menjadi suatu produk jadi
• Dalam fasi ini dilakukan:

a. Beta dan performance testing

b. Membuat dokumentasi tambahan seperti: training, user guide dan sales kit

c. Membuat rencana peluncuran produk ke komunitas pengguna

Penerapan Tahapan Metodologi Pengembangan Lunak dengan Menggunakan RUP (Contoh Kasus)

 Metodologi Rational Unified Process (RUP).Metode RUP merupakan metode pengembangan kegiatan yang berorientasi  pada proses. Dalam metode ini, terdapat empat tahap pengembangan perangkat lunak yaitu:

1. inception
 Pada tahap ini pengembang mendefinisikan batasan kegiatan, melakukan analisis kebutuhan user , dan melakukan perancangan awal perangkat lunak (perancangan arsitektural dan user case). Pada akhir fase ini, prototipe perangakat lunak versi Alpha harus sudah dirilis.

2. Elaboration
Pada tahap ini dilakukan perancangan perangkat lunak mulai dari menspesifikan fitur perangkat lunak hingga perilisan prototipe versi Betha dari perangkat lunak.

3.Contruction
Pengimplentasian rancangan perangkat lunak yang telah dibuat dilakukan pada tahap ini. Pada akhir tahap ini, perangkat lunak versi akhir yang sudah disetujui administrator dirilis beserta dokumentasi perangkata lunak.

4.Transition
Instalasi, deployment dan sosialisasi perangkat lunak dilakukan pada tahap ini.


Referensi :
http://id.wikipedia.org
http://www.mdp.ac.id

       6. Rekyasa Perangkat Lunak (Exteme Programming)

Extreme Programming (XP) merupakan salah satu metodologi dalam rekayasa perangkat lunak dan juga merupakan satu dari beberapa agile software development methodologies yang berfokus pada coding sebagai aktivitas utama di semua tahap pada siklus pengembangan perangkat lunak (software development lifecycle). Metodologi ini mengedepankan proses pengembangan yang lebih responsive terhadap kebutuhan customer (”agile”) dibandingkan dengan metode-metode tradisional sambil membangun suatu software dengan kualitas yang lebih baik.

Extreme Programming muncul menawarkan sebuah disiplin baru dalam pengembangan software secara agile. Nilai dasar yang terkandung di dalam Extreme Programming adalah: Komunikasi (Communication), Kesederhanaan (Simplicity), Umpan balik (Feedback) Keberanian (Courage) dan menghormati (Respect).

Kata Kunci: Extreme Programming, agile, coding, komunikasi, kesederhanaan, umpan balik, keberanian, menghormati.

Tujuan utama XP adalah menurunkan biaya dari adanya perubahan software. Dalam metodologi pengembangan sistem tradisional, kebutuhan sistem ditentukan pada tahap awal pengembangan proyek dan bersifat fixed. Hal ini berarti biaya terhadap adanya perubahan kebutuhan yang terjadi pada tahap selanjutnya akan menjadi mahal. XP diarahkan untuk menurunkan biaya dari adanya perubahan dengan memperkenalkan nilai-nilai basis dasar, prinsip dan praktis. Dengan menerapkan XP, pengembangan suatu sistem haruslah lebih fleksibel terhadap perubahan.

Menurut penggagas dari metode XP, Kent Beck mendefinisikan empat kunci utama (inti) dari XP yaitu:

·       Communication (Komunikasi)

·       Simplicity (Kesederhanaan)

·      Feedback (Masukan)

·     Courage (Keberanian)

·     Respect (Menghormati)

Keuntungan XP:

·         Menjalin komunikasi yang baik dengan client.

·         Meningkatkan komunikasi dan sifat saling menghargai antar developer.

Kerugian XP:

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

Mungkin Sekian yang dapat saya berikan mengenai yang berkaitan dengan model incremental dan extreme programming. Semoga bermanfaat bagi teman-teman semuanya. J

Referensi :

 http://esterjulianti.blogspot.co.id/2015/02/kolaborasi-incremental-dan-extreme.html