Apa yg di maksud Spiral Model? Seperti Galaksi yg berbentuk Spiral. Model Spiralini merupakan gabungan dari Model Waterfall dengan model prototyping yang melakukan iterasi namun selalu berkembang secara bertahap.
Ciri khas dari model spiral ini yaitu pada Risk Analysis (Analisis Resiko). Jadi pada intinya analsis resiko ini memungkinkan kita mencegah berbagai aspek resiko agar tidak terjadi saat pemeralakukan perancangan sisitem. Aspek Analisis Resiko yang biasa di fokuskan pada analisis yaitu sebagai berikut :
○ New Product Development Project (proyek pengembangan produk baru)
○ Concept Development Project (proyek pengembangan konsep)
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 Model Spiral
1. Sulit untuk menyakinkan pelanggan bahwa pendekatan evolusioner ini bisa dikontrol. 2. Memerlukan penaksiran resiko yang masuk akal dan akan menjadi masalah yang serius jika resiko mayor tidak ditemukan dan diatur. 3. Butuh waktu lama untuk menerapkan paradigma ini menuju kepastian yang absolute.
Apa yg di maksud Waterfall Model? Seperti kata Waterfall = Air Terjun. Kenapa air terjun? Karena bentuknya seperti air terjun yang dari tahap atas sampai tahap paling bawah (minimalisasi) dari segi kebutuhan yang sudah terpenuhi artinya kebutuhan yang tadinya maksimal menjadi minimal karena proses model waterfall ini. Model ini bias disebut juga “Linear Sequence Model” atau “Classic Life Cycle”, model ini pertama kali dikenal pada tahun 1970an. Software model ini merupakan model yg sering di gunakan pada umumnya.
Ciri khas model Waterfall ini yaitu dalam tahap rekayasa perangkat lunak nya harus berurutan dari satu tahap ke tahap selanjutnya, jadi tidak bisa melompati dari tahap satu ke 2 tahap setelah nya ataupun sebelumnya. Lalu memakan banyak biaya dan waktu bila suatu sistem yang di kembangkan selalu melakukan perubahan dalam sistemnya.
Waterfall model ini ada 2 jenis menurut Referensi Pressman & Referensi Sommerville namun pada intinya tetep sama menjelaskan tentang requerments, design dan quality.
Waterfall Model Referensi Pressman
Waterfall Model Refersnsi Sommerville
Kelebihan Model Waterfall
1. Merupakan model pengembangan paling handal dan paling lama digunakan.
2. Cocok untuk system software yg bersekala besar
3. Cocok untuk system software yg bersifat generic
4. Pengerjaan project system akan terjadwal dengan baik dan mudah di kontrol
Kelebihan Model Waterfall
1. Perubahan sulit dilakukan karena sifatnya yang kaku. 2.Karena sifat kakunya, model ini cocok ketika kebutuhan dikumpulkan secara lengkap sehingga perubahan bisa ditekan sekecil mungkin. Tapi pada kenyataannya jarang sekali konsumen/pengguna yang bisa memberikan kebutuhan secara lengkap, perubahan kebutuhan adalah sesuatu yang wajar terjadi. 3.Waterfall pada umumnya digunakan untuk rekayasa sistem yang besar dimana proyek dikerjakan di beberapa tempat berbeda, dan dibagi menjadi beberapa bagian sub-proyek. 4. Persyaratan system harus digambarkan dengan jelas. 5. Rincian proses harus benar-benar jelas dan tidak boleh berubah-ubah. 6. Sulit untuk mengadaptasi jika terjadi perubahan spesifikasi pada suatu tahapan pengembangan.
Model Prototype yaitu suatu model yang belum sepenuhnya menjadi suatu rancangan jadi yang utuh karena bertujuan untuk lebih dekat berkomunikasi dengan pemesan program. Perancangan berfokus pada "listen to customer" jadi pada proses pembuatan modelnya antara development dan customer lebih banyak berkomunikasi (feed back) dalam perancangannya. Pada intinya pengembang lebih di tekankan untuk lebih banyak berkomunikasi untuk memenuhi kebutuhan pemesan sistem (customer)
Pada tahap pertama "Listen to Customer" yang melakukan proses komunikasi dengan development yang langsung di terapkan dengan keinginan customer dengan tahap "Build/Revise Mock-Up" yaitu pembuatan pemodelan setengah jadi dan di lanjutkan ke tahap "Customer Test Drives Mock-Up" yang merupakan suatu kegiatan test program kepada customer apa sesuai yang di harapkan atau ada yang ingin di tambahkan dari system program yang di rancang bila ada kebutuhan yang kurang di lanjutkan ke tahap semula "Listen to Costumer" terus melakukan looping sampai sistem program yang di rancang sudah cukup memuaskan customer dari segi kebutuhan sistem. Kelemahannya mungkin kegiatan looping ini terus melakukan iterasi tanpa perkembangan jadi hanya mencakup skup" tertentu saja. Kelebihannya mungkin lebih banyak komunikasi antara development dengan customer.
Kelebihan Model Prototype
1. Model ini akan digunakan jika perangkat lunak yang akan dibuat telah didefinisikan secara khusus oleh pelanggan dan pengembang. 2. Pendefinisian tersebut antara lain mengidentifikasi kebutuhan output, pemrosesan, input detail, kepastian terhadap efisiensi algoritme, penyesuaian dari sebuah sistem operasi, dan bentuk-bentuk yang harus dilakukan oleh interaksi manusia dengan mesin. 3. Intinya model ini dirancang untuk mendorong konsumen maupun pengembang agar memahami kebutuhan.
Kekurangan Model Prototype
1. Tidak ada cara untuk mengetahui banyaknya iterasi yang diperlukan. 2. Membuat prototype / prototyping dapat mendorong ke arah perancangan sistem yang kurang baik. 3. Tujuan utama protoyping adalah perkembangan cepat, perancangan sistem kadang-kadang dapat rusak sebab sistem dibangun pada rangkaian “lapisan” tanpa integrasi pertimbangan global dari semua komponen lain.
Extreme Programming Model atau bisa di singkat menjadi XP Model, XP Model ini merupakan model terbaru bagi kalangan perancangan pemodelan sistem yang diciptakan oleh kent black.
Tahap dalam XP yaitu sebgai berikut :
- Listen - Test - Code - Design
Pada tahapannya pertama "listen" yang artinya langsung berkomunikasi dengan customer lalu langsung melakukan test program lalu pengkodean setelah itu design. Timbul pertanyaan mengapa design di model XP ini di letakan tahap paling akhir, mungkin menurut saya agar program yang di rancang cepat selesai dengan estimasi waktu, biaya dan tenaga yang seminimalisir dalam jumlah pengeluarannya, jadi program yang di buat selesai dengan tahap yang extreme dan tidak lupa juga tetap mempertahankan kualitas program itu sendiri.
Ciri khas dalam XP:
- Efisien - Fleksibel - Dapat di perkirakan - Bersifat ilmiah - Resiko rendah dalam development
Dalam model XP ini menekankan (fokus) pada customer yang berkomunikasi langsung dalam perancangan pemodelan, pengujian maupun design.
Kelebihan XP Model
Komunikasi
Komunikasi antara developer dan klien sering menjadi masalah, karena itu komunikasi dalam XP dibangun dengan melakukan pemrograman berpasangan "pair programming". Developer didampingi oleh pihak klien dalam melakukan coding dan unit testing sehingga klien bisa terlibat langsung dalam pemrograman sambil berkomunikasi dengan developer.
Sederhana
Menekankan pada kesederhanaan dalam melakukan pengkodingan, lebih baik melakukan hal yang sederhana dan mengembangkannya besok jika diperlukan. Komunikasi yang lebih banyak mempermudah dan rancangan yang sederhana mengurangi penjelasan, intinya langsung di kerjakan dengan sedikit penjelasan.
Feedback
Setiap feedback yang ditanggapi dengan melakukan tes, unit test atau system integration dan jangan pernah menunda proses karena biaya akan membengkak dari segi uang, tenaga dan waktu.
Berani
Banyak ide baru dan berani mencobanya, berani mengerjakan kembali dan setiap kali kesalahan ditemukan dan langsung diperbaiki.
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.
Kelemahan XP Model
1. Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima. 2. Tidak bisa membuat kode yang detail di awal "prinsip simplicity dan juga anjuran untuk melakukan apa yang diperlukan hari itu juga".
Rational Unified Process (RUP) merupakan suatu metode rekayasa perangkat lunak yang dikembangkan dengan mengumpulkan berbagai best practises yang terdapat dalam industri pengembangan perangkat lunak.
RUP menggunakan konsep object oriented, dengan aktifitas yang berfokus pada pengembangan model dengan menggunakan Unified Model Language (UML). Intinya model ini lebih ditekankan pada kumpulan latihan yang bisa dijadikan suatu sistem utuh.
Inception
- Menentukan ruang lingkup proyek. - Membuat business case.
- Memenuhi syarat bahwa program telah memenuhi syarat.
Elaboration
- Menganalisa berbagai persyaratan dan resiko. - Menetapkan base line. - Merencanakan fase berikutnya yaitu construction.
Contruction
- Melakukan sederetan iterasi. - Pada setiap iterasi akan melibatkan proses analisa desain, implementasi dan testing.
Transition
- Membuat apa yang sudah dimodelkan menjadi suatu produk yang utuh. - Beta dan performance testing. - Membuat dokumentasi tambahan seperti training, user guides dan sales kit. - Membuat rencana peluncuran produk ke komunitas pengguna.
Kelebihan RUP:
- Software yang dikembangkan dengan metode ini biasanya menghasilkan kualitas yang baik. - Document pengembangan sistem sangat terorganisir, karena setiap fase harus terselesaikan dengan lengkap sebelum melangkah ke fase berikutnya.
Kekurangan RUP:
- Membutuhkan keahlian yang baik atau yang telah berpengalaman dalam mengembangkan perangkat lunak dalam arti metode ini kurang cocok bagi pemula. - Diperlukan majaemen yang baik, karena proses pengembangan tidak dapat berulang sebelum menghasilkan suatu produk yaitu aplikasi. Jadi apabila dalam suatu proses seperti perancangan tidak selesai tepat waktu maka akan mempengaruhi keseluruhan proses pengembangan perangkat lunak.
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), RADdesign 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.
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):
Penghematan waktu dalam keseluruhan fase projek dapat dicapai.
RAD mengurangi seluruh kebutuhan yang berkaitan dengan biaya projek dan sumberdaya manusia.
RAD sangat membantu pengembangan aplikasi yang berfokus pada waktu penyelesaian projek.
Perubahan desain sistem dapat lebih berpengaruh dengan cepat dibandingkan dengan pendekatan SDLC tradisional.
Sudut pandang user disajikan dalam sistem akhir baik melalui fungsi-fungsi sistem atau antarmuka pengguna.
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:
Dengan metode RAD, penganalisis berusaha mepercepat projek dengan terburu-buru.
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.
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.
Sumber:
Mc.,Leod, R. Jr. 2002. System Development: A Project Management Approach. New York: Leigh Publishing LLC.
Whitten, J.L. & Bentley, L.D. 2004. System Analysis & Design Methods: Sixth Edition. New York: Mc.Graw-Hill.
