RPL

TUGAS

REKAYASA PERANGKAT LUNAK

DI SUSUN OLEH :

CHRISTIAN R. ROEROE

12 312 790

(KELAS D)

SEMESTER III

FAKULTAS TEKNIK

PENDIDIKAN TEKNOLOGI INFORMASI DAN KOMUNIKASI

UNIVERSITAS NEGERI MANADO

2013

KATA PENGANTAR

Segala puji dan syukur penulis panjatkan kepada Tuhan yang maha esa, yang telah memberikan rahmatnya kepada penulis sehingga penulis dapat menyelesaikan tugas ini, namun penulis menyadari tugas ini belum dapat dikatakan sempurna karena mungkin masih banyak kesalahan-kesalahan.

Tugas ini saya susun untuk memenuhi Mata Kuliah RPL, dalam tugas ini penulis membahas mengenai “waterfall, Prototype, RAD, Agile, Iterativ, dan Spiral”, dengan tugas ini penulis mengharapkan agar dapat membantu sistem pembelajaran. Penulis ucapkan terima kasih kepada semua pihak yang telah membantu penulis dalam menyelesaikan makalah ini.

1.  Kepada Dosen Mata Kuliah RPL  Cindy Maunanchehe,  yang telah membimbing dan mengarahkan penulis dalam menyelesaikan tugas ini.
2. Kepada orang tua kami yang telah memberikan motivasi dan dukungan kepada saya baik secara moral maupun material.
3. Kepada teman-teman yang telah memberi dorongan dan membantu dalam menyelesaikan tugas ini.

Akhir kata penulis sampaikan terimakasih atas segala perhatiannya.

                                                                                    Tondano,     mei  2013

                                                                                                Penyusun

DAFTAR ISI

Kata pengantar                                                                                        i

Daftar isi                                                                                                    ii

Bab 1

RAD                                                                                                           1-5

Bab 2

SPIRAL                                                                                                     6-8

Bab 3

AGILE                                                                                                        9-12

Bab 4

WATERFALL                                                                                          13-16

Bab 5

ITERATIV                                                                                                 16-18

Bab 6

PROTOTYPE                                                                                          19-21

Soal                                                                                                           22

REFERENSI

RAD ( Rapid Application Development )

RAD ( Rapid Application Development ) Model ini didasarkan pada prototipe dan pengembangan berulang tanpa perencanaan yang spesifik yang terlibat. Proses menulis perangkat lunak itu sendiri melibatkan perencanaan yang dibutuhkan untuk mengembangkan produk.

Pengembangan aplikasi yang cepat berfokus pada pengumpulan kebutuhan pelanggan melalui lokakarya atau kelompok fokus, pengujian awal prototipe oleh pelanggan dengan menggunakan konsep berulang-ulang, penggunaan kembali prototipe yang sudah ada ( komponen ), integrasi berkesinambungan dan pengiriman cepat.

Pengembangan aplikasi cepat (RAD) adalah metodologi pengembangan perangkat lunak yang menggunakan perencanaan minimal dalam mendukung prototyping cepat . Sebuah prototipe adalah model kerja yang secara fungsional setara dengan komponen produk .

Dalam model RAD modul fungsional dikembangkan secara paralel sebagai prototipe dan terintegrasi untuk membuat produk yang lengkap untuk pengiriman produk lebih cepat.

Karena tidak ada preplanning rinci, itu membuat lebih mudah untuk menggabungkan perubahan dalam proses pembangunan. Proyek RAD ikuti berulang dan Model tambahan dan memiliki tim kecil yang terdiri dari pengembang, ahli domain, perwakilan pelanggan dan sumber daya TI lainnya bekerja secara progresif pada komponen atau prototipe mereka .

Aspek yang paling penting untuk model ini untuk menjadi sukses adalah untuk memastikan bahwa prototipe yang dikembangkan dapat digunakan kembali .

RAD Model Desain

RAD Model mendistribusikan analisis, desain, membangun, dan tahapan tes menjadi serangkaian pendek , berulang siklus pengembangan .

Berikut ini adalah fase-fase RAD Model :

1.    Pemodelan Bisnis : Model bisnis untuk produk yang sedang dikembangkan ini dirancang dalam hal arus informasi dan distribusi informasi antara berbagai saluran bisnis . Sebuah analisis bisnis yang lengkap dilakukan untuk menemukan informasi penting untuk bisnis, bagaimana hal itu dapat diperoleh, bagaimana dan kapan informasi diproses dan apa faktor pendorong arus informasi sukses .

2.    Pemodelan Data: Informasi yang dikumpulkan dalam tahap Pemodelan Bisnis ditinjau dan dianalisis untuk membentuk set objek data penting untuk bisnis. Atribut semua set data yang diidentifikasi dan didefinisikan . Hubungan antara objek data yang ditetapkan dan didefinisikan secara rinci dalam relevansi dengan model bisnis .

3.    Proses Modeling : Objek data set didefinisikan dalam data fase Modeling dikonversi untuk membentuk arus informasi bisnis yang diperlukan untuk mencapai tujuan bisnis yang spesifik sesuai model bisnis . Proses model untuk perubahan atau perangkat tambahan untuk set data objek didefinisikan dalam fase ini. Proses deskripsi untuk menambahkan, menghapus , mengambil atau memodifikasi objek data yang diberikan .

4.    Generasi Aplikasi: Sistem yang sebenarnya dibangun dan coding dilakukan dengan menggunakan alat otomatisasi untuk mengubah proses dan data model menjadi prototipe yang sebenarnya .

5.    Pengujian dan Omzet: waktu pengujian secara keseluruhan berkurang dalam model RAD sebagai prototipe diuji secara independen selama setiap iterasi. Namun aliran data dan antarmuka antara semua komponen harus benar-benar diuji dengan cakupan tes lengkap . Karena sebagian besar komponen pemrograman telah diuji, mengurangi risiko masalah besar.

Gambar berikut menggambarkan RAD Model :

RAD Model Vs SDLC Tradisional

SDLC tradisional mengikuti model proses yang kaku dengan penekanan yang tinggi pada analisis kebutuhan dan mengumpulkan sebelum dimulai coding. Ini menempatkan tekanan pada pelanggan untuk menandatangani persyaratan sebelum proyek dimulai dan pelanggan tidak mendapatkan nuansa produk karena tidak ada yang bekerja membangun tersedia untuk waktu yang lama.

Pelanggan mungkin perlu beberapa perubahan setelah dia benar-benar mendapat untuk melihat perangkat lunak, namun proses perubahan yang cukup kaku dan mungkin tidak layak untuk memasukkan perubahan besar dalam produk dalam SDLC tradisional.

Model RAD berfokus pada iteratif dan incremental pengiriman model kerja kepada pelanggan. Hal ini mengakibatkan pengiriman cepat kepada pelanggan dan keterlibatan pelanggan selama siklus pengembangan yang lengkap produk mengurangi risiko non kesesuaian dengan kebutuhan pengguna yang sebenarnya .

RAD Model Aplikasi

Model RAD dapat berhasil diterapkan pada proyek-proyek di mana modularisasi jelas mungkin. Jika proyek tidak dapat dipecah menjadi modul, RAD mungkin gagal.

Berikut ini adalah skenario yang khas di mana RAD dapat digunakan :

·         RAD harus digunakan hanya ketika sistem dapat termodulasi akan dikirimkan secara bertahap .

·         Ini harus digunakan jika ketersediaan tinggi desainer untuk pemodelan

·         Ini harus digunakan hanya jika anggaran memungkinkan penggunaan kode alat pembangkit otomatis

·         RAD Model SDLC harus dipilih hanya jika ahli domain yang tersedia dengan pengetahuan bisnis yang relevan

·         Harus digunakan di mana persyaratan berubah selama proyek dan prototipe bekerja yang akan disajikan kepada pelanggan dalam iterasi kecil 2-3 bulan .

RAD Model Pro dan Kontra

Model RAD memungkinkan pengiriman cepat karena mengurangi waktu pengembangan secara keseluruhan karena usabilitas dari komponen dan pembangunan paralel .

RAD bekerja dengan baik hanya jika insinyur terampil tinggi yang tersedia dan pelanggan juga berkomitmen untuk mencapai prototipe ditargetkan dalam kerangka waktu tertentu. Jika ada komitmen kurang pada kedua sisi model mungkin gagal.

KEUNTUNGAN RAD

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

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

KERUGIAN RAD

·         Dengan melakukan pembelian belum tentu bisa menghemat biaya dibanding-kan 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 diban-dingkan 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.

Setelah daftar keluar pro dan kontra dari RAD Model :

Pro Kontra

·      Mengubah persyaratan dapat diakomodasi

·      Kemajuan dapat diukur

·      Waktu iterasi bisa pendek dengan penggunaan alat-alat RAD kuat

·      Produktivitas dengan sedikit orang dalam waktu singkat

·      Mengurangi waktu pengembangan

·      Meningkatkan usabilitas komponen

·      Tinjauan awal cepat terjadi

·      Mendorong umpan balik pelanggan

·      Integrasi dari sangat awal memecahkan banyak masalah integrasi

·      Ketergantungan pada teknis anggota tim yang kuat untuk mengidentifikasi kebutuhan bisnis

·      Hanya sistem yang dapat termodulasi dapat dibangun dengan menggunakan RAD

·      Membutuhkan pengembang / desainer yang sangat terampil

·      Ketergantungan yang tinggi pada kemampuan modeling

·      Tidak dapat diterapkan untuk proyek-proyek yang lebih murah sebagai biaya pemodelan dan pembuatan kode otomatis sangat tinggi

·      Kompleksitas manajemen lebih Cocok untuk sistem yang berbasis komponen dan terukur

·      Membutuhkan keterlibatan pengguna di seluruh siklus hidup

·      Cocok untuk proyek yang membutuhkan waktu pengembangan yang lebih pendek.

SPIRAL

Model spiral menggabungkan gagasan pengembangan berulang dengan sistematis, aspek dikendalikan dari model air terjun .

Model spiral adalah kombinasi dari iteratif model proses pembangunan dan sekuensial linier model pembangunan yaitu model air terjun dengan penekanan yang sangat tinggi pada analisis risiko .

Hal ini memungkinkan untuk rilis tambahan dari produk, atau perbaikan inkremental melalui setiap iterasi sekitar spiral.

Spiral Model desain

Model spiral memiliki empat fase. Sebuah proyek perangkat lunak berulang kali melewati fase-fase dalam iterasi yang disebut Spiral .

1.    Identifikasi : Fase ini dimulai dengan mengumpulkan kebutuhan bisnis dalam spiral dasar. Dalam spiral berikutnya sebagai produk dewasa, identifikasi persyaratan sistem, persyaratan subsistem dan persyaratan satuan semua dilakukan dalam fase ini.

Ini juga termasuk memahami persyaratan sistem dengan komunikasi terus menerus antara pelanggan dan sistem analis. Pada akhir spiral produk ini digunakan di pasar diidentifikasi.

2.    Desain : Desain fase dimulai dengan desain konseptual dalam spiral baseline dan melibatkan desain arsitektur, desain logis dari modul, desain produk fisik dan desain akhir dalam spiral berikutnya.

3.    Membangun atau Membangun : Membangun fase mengacu pada produksi produk perangkat lunak yang sebenarnya di setiap spiral. Dalam spiral awal ketika produk hanya memikirkan dan desain sedang dikembangkan suatu POC ( Proof of Concept ) dikembangkan di tahap ini untuk mendapatkan umpan balik pelanggan.

Kemudian pada spiral berikutnya dengan kejelasan yang lebih tinggi pada persyaratan dan rincian desain model kerja perangkat lunak yang disebut membangun diproduksi dengan nomor versi. Ini membangun dikirim ke pelanggan untuk umpan balik.

4.    Evaluasi dan Analisis Risiko : Analisis Risiko meliputi mengidentifikasi, memperkirakan, dan pemantauan kelayakan teknis dan risiko manajemen, seperti jadwal slip dan kelebihan biaya. Setelah pengujian membangun, pada akhir iterasi pertama, pelanggan mengevaluasi perangkat lunak dan memberikan umpan balik.

Berikut ini adalah representasi diagram dari model spiral daftar kegiatan di setiap tahap :

SDLC Spiral Model

Berdasarkan evaluasi pelanggan, proses pengembangan perangkat lunak masuk ke iterasi berikutnya dan kemudian mengikuti pendekatan linier untuk menerapkan umpan balik yang disarankan oleh pelanggan. Proses iterasi sepanjang spiral terus sepanjang hidup perangkat lunak.
Spiral Model Aplikasi

Model Spiral sangat banyak digunakan dalam industri perangkat lunak seperti yang selaras dengan proses perkembangan alami dari setiap produk yaitu belajar dengan kematangan dan juga melibatkan risiko minimal bagi para pelanggan serta perusahaan pengembangan.

Berikut ini adalah penggunaan khas model Spiral:

·         Ketika biaya ada kendala anggaran dan risiko evaluasi penting.

·         Untuk media untuk proyek-proyek berisiko tinggi

·         Komitmen proyek jangka panjang karena potensi perubahan prioritas ekonomi sebagai persyaratan berubah dengan waktu.

·         Pelanggan tidak yakin kebutuhan mereka yang biasanya terjadi

·         Persyaratan yang kompleks dan perlu evaluasi untuk mendapatkan kejelasan

·         Lini produk baru yang harus dirilis secara bertahap untuk mendapatkan umpan balik pelanggan cukup.

·         Perubahan signifikan yang diharapkan dalam produk selama siklus pengembangan .

Model Spiral Pro dan Kontra

Keuntungan

Keuntungan dari model siklus spiral yang memungkinkan untuk unsur-unsur produk yang akan ditambahkan dalam ketika mereka menjadi tersedia atau dikenal. Hal ini menjamin bahwa tidak ada konflik dengan persyaratan sebelumnya dan desain.

Metode ini konsisten dengan pendekatan yang memiliki beberapa perangkat lunak dan rilis membangun dan memungkinkan untuk membuat transisi yang tertib untuk kegiatan pemeliharaan. Aspek positif lain adalah bahwa model spiral memaksa keterlibatan pengguna awal dalam upaya pengembangan sistem.

Di sisi lain, dibutuhkan manajemen yang sangat ketat untuk menyelesaikan produk tersebut dan ada risiko menjalankan spiral dalam lingkaran terbatas. Jadi disiplin perubahan dan sejauh mengambil permintaan perubahan sangat penting untuk mengembangkan dan menyebarkan produk berhasil.

Berikut mencantumkan keluar pro dan kontra dari Spiral Model SDLC :

Pro Kontra

·         Mengubah persyaratan dapat diakomodasi

·         Memungkinkan untuk penggunaan ekstensif prototipe

·         Persyaratan dapat ditangkap lebih akurat

·         Pengguna melihat sistem awal

·         Pembangunan dapat dibagi menjadi bagian-bagian yang lebih kecil dan bagian lebih berisiko dapat dikembangkan sebelumnya yang membantu manajemen risiko yang lebih baik

·         Manajemen lebih kompleks

·         Akhir proyek mungkin tidak diketahui lebih awal

·         Tidak cocok untuk proyek-proyek berisiko kecil atau rendah dan bisa mahal untuk proyek-proyek kecil

·         Proses adalah kompleks

·         Spiral dapat pergi tanpa batas

·         Besar jumlah tahap-tahap peralihan membutuhkan dokumentasi yang berlebihan

AGILE

Agile Model SDLC adalah kombinasi dari berulang dan model proses inkremental dengan fokus pada proses adaptasi dan kepuasan pelanggan dengan pengiriman cepat produk kerja perangkat lunak.

Metode Agile istirahat produk membangun tambahan kecil. Ini membangun disediakan dalam iterasi. Setiap iterasi biasanya berlangsung dari sekitar satu sampai tiga minggu. Setiap iterasi melibatkan tim lintas fungsional yang bekerja secara simultan pada berbagai bidang seperti perencanaan, analisis kebutuhan, desain, coding, pengujian unit, dan pengujian penerimaan.

Pada akhir iterasi produk kerja ditampilkan kepada pelanggan dan stakeholder penting.

Model Agile percaya bahwa setiap proyek harus ditangani secara berbeda dan metode yang ada perlu disesuaikan terbaik sesuai persyaratan proyek. Di tangkas tugas dibagi ke kotak waktu (time frame kecil) untuk memberikan fitur khusus untuk rilis.

Pendekatan berulang diambil dan bekerja membangun software disampaikan setelah setiap iterasi. Setiap membangun adalah tambahan dari segi fitur, final membangun memegang seluruh fitur yang dibutuhkan oleh pelanggan.

Berikut adalah ilustrasi grafis dari model Agile:

SDLC Agile Model

Agile proses berpikir mulai awal dalam pengembangan perangkat lunak dan mulai menjadi populer dengan waktu karena fleksibilitas dan kemampuan beradaptasi.

Metode tangkas paling populer termasuk Rational Unified Process (1994), Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Fitur Driven Development, dan Dinamis Metode Pengembangan Sistem (DSDM) (1995). Ini sekarang disebut sebagai metodologi tangkas, setelah Agile Manifesto diterbitkan pada tahun 2001.

Berikut ini adalah prinsip-prinsip Manifesto Agile

·      Individu dan interaksi - dalam pembangunan tangkas, self-organisasi dan motivasi yang penting, seperti interaksi seperti co-lokasi dan pasangan pemrograman.

·      Kerja perangkat lunak - Demo kerja perangkat lunak dianggap sebagai cara terbaik untuk komunikasi dengan pelanggan untuk memahami kebutuhan mereka, bukan hanya tergantung pada dokumentasi.

·      Kolaborasi pelanggan - Sebagai persyaratan tidak dapat dikumpulkan sepenuhnya pada awal proyek karena berbagai faktor, interaksi pelanggan terus menerus sangat penting untuk mendapatkan persyaratan produk yang tepat.

·      Menanggapi berubah - pembangunan tangkas difokuskan pada respon cepat terhadap perubahan dan pembangunan berkelanjutan.

Agile Vs Models SDLC Tradisional

Agile didasarkan pada metode pengembangan perangkat lunak adaptif, dimana sebagai model SDLC tradisional seperti model air terjun didasarkan pada pendekatan prediktif.

Tim prediksi dalam model SDLC tradisional biasanya bekerja dengan perencanaan yang rinci dan memiliki perkiraan lengkap dari tugas yang tepat dan fitur yang akan disampaikan dalam beberapa bulan ke depan atau selama siklus hidup produk. Metode prediksi sepenuhnya bergantung pada analisis kebutuhan dan perencanaan yang dilakukan pada awal siklus. Setiap perubahan dimasukkan melalui manajemen perubahan kontrol yang ketat dan prioritas.

Agile menggunakan pendekatan adaptif di mana tidak ada perencanaan yang rinci dan ada kejelasan tentang tugas-tugas masa depan hanya dalam hal fitur apa yang perlu dikembangkan. Ada fitur pembangunan berbasis dan tim menyesuaikan dengan persyaratan produk berubah dinamis. Produk ini sangat sering diuji, melalui iterasi rilis, meminimalkan risiko dari setiap kegagalan utama di masa depan.

Interaksi pelanggan adalah tulang punggung metodologi Agile, dan komunikasi terbuka dengan dokumentasi minimum adalah fitur khas Agile lingkungan pengembangan. Tim tangkas bekerjasama erat satu sama lain dan yang paling sering terletak di lokasi geografis yang sama.

Agile Model Pro dan Kontra

Metode Agile sedang diterima secara luas dalam dunia perangkat lunak baru-baru ini, bagaimanapun, metode ini tidak selalu cocok untuk semua produk.

Berikut adalah beberapa pro dan kontra dari model tangkas.

Setelah daftar tabel keluar pro dan kontra dari Agile Model:

Pro Kontra

·         pendekatan yang sangat realistis untuk pengembangan perangkat lunak

·         Meningkatkan kerja sama tim dan cross training.

·         Fungsi dapat berkembang pesat dan menunjukkan.

·         Kebutuhan sumber daya yang minimal.

·         Cocok untuk kebutuhan tetap atau berubah

·         Memberikan solusi yang bekerja lebih awal parsial.

·         Model yang baik untuk lingkungan yang berubah terus.

·         Aturan minimal, dokumentasi mudah digunakan.

·         Memungkinkan pengembangan dan pengiriman dalam konteks keseluruhan direncanakan bersamaan.

·         Sedikit atau tidak ada perencanaan yang diperlukan

·         Mudah untuk mengelola

·         Memberikan fleksibilitas untuk pengembang

·         Tidak cocok untuk menangani dependensi kompleks.

·         Risiko Lebih keberlanjutan, rawatan dan diperpanjang.

·         Rencana keseluruhan, pemimpin tangkas dan lincah PM praktek adalah suatu keharusan tanpa yang itu tidak akan berhasil.

·         Manajemen pengiriman yang ketat menentukan ruang lingkup, fungsi yang akan disampaikan, dan penyesuaian untuk memenuhi tenggat waktu.

·         Sangat bergantung pada interaksi pelanggan, sehingga jika pelanggan tidak jelas, tim dapat didorong ke arah yang salah.

·         Ada ketergantungan individu yang sangat tinggi, karena ada dokumentasi minimum dihasilkan.

·         Transfer teknologi untuk anggota tim baru dapat cukup menantang karena kurangnya dokumentasi

WATERFALL

Waterfall Model adalah Proses pertama Model yang akan diperkenalkan. Hal ini juga disebut sebagai model siklus hidup linier – sekuensial. Hal ini sangat sederhana untuk dimengerti dan digunakan. Dalam model air terjun, setiap fase harus diselesaikan sebelum tahap berikutnya dapat dimulai dan tidak ada tumpang tindih dalam fase.

Model air terjun adalah pendekatan SDLC awal yang digunakan untuk pengembangan perangkat lunak.

Air terjun Model menggambarkan proses pengembangan perangkat lunak dalam aliran sekuensial linier, dan karena itu juga disebut sebagai model siklus hidup linier – sekuensial. Ini berarti bahwa setiap fase dalam proses pembangunan dimulai hanya jika tahap sebelumnya selesai. Dalam fase model air terjun tidak tumpang tindih.

Waterfall Model desain

Pendekatan Waterfall Model pertama SDLC untuk digunakan secara luas dalam Rekayasa Perangkat Lunak untuk memastikan keberhasilan proyek. Dalam "The Waterfall" pendekatan, seluruh proses pengembangan perangkat lunak dibagi menjadi fase terpisah. Dalam model Waterfall, biasanya, hasil dari satu fase bertindak sebagai masukan untuk fase berikutnya secara berurutan.

Berikut ini adalah representasi diagram dari fase yang berbeda dari model air terjun.

SDLC Waterfall Model

Tahapan berurutan dalam model Waterfall adalah:

1.    Persyaratan Pengumpulan dan analisis : Semua persyaratan yang mungkin dari sistem yang akan dikembangkan ditangkap dalam fase ini dan didokumentasikan dalam spesifikasi kebutuhan doc.

2.    Sistem Desain : Spesifikasi kebutuhan dari tahap pertama dipelajari dalam fase dan sistem ini desain disiapkan. Desain Sistem membantu dalam menentukan perangkat keras dan persyaratan sistem dan juga membantu dalam mendefinisikan arsitektur sistem secara keseluruhan.

3.    Pelaksanaan : Dengan masukan dari desain sistem, sistem ini pertama kali dikembangkan dalam program kecil yang disebut unit, yang terintegrasi dalam fase berikutnya. Setiap unit dikembangkan dan diuji untuk fungsionalitas yang disebut sebagai Unit Testing.

4.    Integrasi dan Pengujian : Semua unit yang dikembangkan dalam tahap implementasi yang terintegrasi ke dalam sistem setelah pengujian masing-masing unit. Pasca integrasi seluruh sistem diuji untuk setiap kesalahan dan kegagalan.

5.    Penyebaran sistem : Setelah pengujian fungsional dan non fungsional dilakukan, produk ini digunakan dalam lingkungan pelanggan atau dilepas ke pasar.

6.    Pemeliharaan: Ada beberapa masalah yang muncul dalam lingkungan klien. Untuk memperbaiki isu-isu patch dilepaskan. Juga untuk meningkatkan produk beberapa versi yang lebih baik dilepaskan. Pemeliharaan dilakukan untuk memberikan perubahan dalam lingkungan pelanggan.

Semua tahap ini mengalir satu sama lain di mana kemajuan dipandang sebagai terus mengalir ke bawah (seperti air terjun) melalui tahap. Tahap berikutnya hanya akan dimulai setelah set didefinisikan tujuan yang dicapai untuk tahap sebelumnya dan itu ditandatangani, sehingga nama "Waterfall Model". Dalam model ini fase tidak tumpang tindih.

Waterfall Model Aplikasi

Setiap perangkat lunak yang dikembangkan berbeda dan membutuhkan pendekatan SDLC cocok untuk diikuti berdasarkan faktor-faktor internal dan eksternal.

Beberapa situasi di mana penggunaan model Waterfall yang paling tepat adalah:

·         Persyaratan sangat didokumentasikan dengan baik, jelas dan tetap.

·         Definisi produk stabil

·         Teknologi dipahami dan tidak dinamis

·         Tidak ada persyaratan ambigu

·         Sumber daya yang cukup dengan keahlian yang diperlukan tersedia untuk mendukung produk

·         Proyek ini pendek.

Waterfall Model Pro & Kontra

Keuntungan

Keuntungan dari pembangunan air terjun adalah bahwa hal itu memungkinkan untuk departmentalization dan kontrol. Sebuah jadwal dapat diatur dengan tenggat waktu untuk setiap tahap pengembangan dan produk dapat dilanjutkan melalui model tahap proses pembangunan satu per satu.

Pengembangan bergerak dari konsep, melalui desain, implementasi, pengujian, instalasi, troubleshooting, dan berakhir di operasi dan pemeliharaan. Setiap fase dari hasil pengembangan dalam rangka ketat.

Kerugian

Kerugian dari pembangunan air terjun adalah bahwa hal itu tidak memungkinkan untuk banyak refleksi atau revisi. Setelah aplikasi ini dalam tahap uji coba, sangat sulit untuk kembali dan mengubah sesuatu yang tidak terdokumentasi dengan baik atau berpikir atas dalam tahap konsep.

Berikut mencantumkan keluar pro dan kontra dari model Waterfall :

Pro Kontra

·         Sederhana dan mudah dipahami dan digunakan

·         Mudah untuk mengelola karena kekakuan model. setiap fase memiliki kiriman spesifik dan proses review

·         Tahapan diproses dan diselesaikan satu per satu

·         Bekerja dengan baik untuk proyek-proyek kecil di mana persyaratan dipahami dengan sangat baik

·         Jelas tahap

·         Dipahami tonggak

·         Mudah untuk mengatur tugas

·         Proses dan hasil didokumentasikan dengan baik

·         Tidak ada perangkat lunak yang bekerja diproduksi sampai akhir selama siklus hidup

·         Jumlah tinggi risiko dan ketidakpastian

·         Bukan model yang baik untuk proyek-proyek yang kompleks dan berorientasi objek

·         Model miskin untuk proyek-proyek yang panjang dan berkelanjutan

·         Tidak cocok untuk proyek-proyek di mana persyaratan berada pada risiko sedang hingga tinggi berubah. Jadi risiko dan ketidakpastian yang tinggi dengan model proses ini

·         Sulit untuk mengukur kemajuan dalam tahapan

·         Tidak dapat mengakomodasi perubahan kebutuhan

·         Tidak ada perangkat lunak yang bekerja diproduksi sampai akhir dalam siklus hidup

·         Mengatur ruang lingkup selama siklus hidup dapat mengakhiri proyek

·         Integrasi ini dilakukan sebagai "big-bang”. Di akhir, yang tidak memungkinkan mengidentifikasi setiap hambatan teknologi atau bisnis atau tantangan awal.

 

ITERATIF

Dalam Iteratif Model, proses berulang-ulang dimulai dengan implementasi yang sederhana dari satu set kecil dari persyaratan perangkat lunak dan iteratif meningkatkan versi berkembang sampai sistem yang lengkap dilaksanakan dan siap untuk digunakan.

Iteratif model siklus hidup tidak berusaha untuk memulai dengan spesifikasi lengkap persyaratan. Sebaliknya, pengembangan dimulai dengan menentukan dan menerapkan hanya bagian dari perangkat lunak, yang kemudian ditinjau dalam rangka untuk mengidentifikasi persyaratan lebih lanjut. Proses ini kemudian diulang,  memproduksi versi baru dari perangkat lunak pada akhir setiap iterasi dari model.

Desain iteratif Model

Perancangan proses dimulai dengan implementasi yang sederhana dari subset dari kebutuhan perangkat lunak dan iteratif meningkatkan versi berkembang sampai sistem lengkap diimplementasikan. Pada setiap iterasi, modifikasi desain yang dibuat dan kemampuan fungsional baru ditambahkan. Ide dasar di balik metode ini adalah untuk mengembangkan sistem melalui siklus berulang (iteratif) dan dalam porsi yang lebih kecil pada waktu (incremental).

Berikut adalah representasi bergambar Iteratif dan Model Incremental :
SDLC Iteratif Model

Iteratif dan pengembangan incremental adalah kombinasi dari kedua desain iteratif atau metode dan incremental membangun model untuk pengembangan berulang. Selama pengembangan perangkat lunak, lebih dari satu iterasi dari siklus pengembangan perangkat lunak mungkin berlangsung pada waktu yang sama. "dan" Proses ini dapat digambarkan sebagai "akuisisi evolusi" atau "tambahan membangun" pendekatan .

Dalam model inkremental seluruh persyaratan dibagi menjadi berbagai membangun. Dalam setiap iterasi, modul pembangunan berjalan melalui persyaratan, desain, implementasi dan tahap pengujian. Setiap rilis berikutnya dari modul menambahkan fungsi untuk rilis sebelumnya. Proses berlanjut sampai sistem lengkap siap sesuai kebutuhan.

Kunci keberhasilan penggunaan iteratif pengembangan perangkat lunak siklus hidup adalah validasi ketat persyaratan, dan verifikasi & pengujian setiap versi perangkat lunak terhadap persyaratan dalam setiap siklus model. Sebagai perangkat lunak berkembang melalui siklus berturut-turut, tes harus diulang dan diperluas untuk memverifikasi setiap versi perangkat lunak.

Iteratif Model Aplikasi

Seperti model SDLC lainnya, Pengembangan bertahap dan berulang memiliki beberapa aplikasi khusus di industri perangkat lunak .

Model ini paling sering digunakan dalam skenario berikut :

·         Persyaratan sistem lengkap didefinisikan dengan jelas dan dipahami

·         Persyaratan utama harus didefinisikan , namun , beberapa fungsi atau perangkat diminta dapat berkembang dengan waktu

·         Ada waktu untuk kendala pasar

·         Sebuah teknologi baru yang sedang digunakan dan sedang dipelajari oleh tim pengembangan saat bekerja pada proyek

·          Sumber daya dengan keahlian yang dibutuhkan tidak tersedia dan direncanakan akan digunakan untuk kontrak iterasi tertentu

·          Ada beberapa fitur berisiko tinggi dan tujuan yang mungkin berubah di masa depan.

Perancangan Model Pro dan Kontra

Keuntungan

Keuntungan dari model ini adalah bahwa ada sebuah model kerja sistem pada tahap yang sangat awal pengembangan yang membuatnya lebih mudah untuk menemukan kekurangan fungsional atau desain. Menemukan masalah pada tahap awal pengembangan memungkinkan untuk mengambil tindakan korektif dalam anggaran terbatas.

Kerugian

Kerugian dengan model SDLC adalah bahwa hal itu hanya berlaku untuk proyek-proyek pengembangan perangkat lunak besar dan besar. Hal ini karena sulit untuk memecahkan sistem perangkat lunak kecil menjadi lebih bertahap / modul diservis kecil.

Berikut mencantumkan keluar pro dan kontra dari Iteratif dan incremental SDLC Model:

Pro Kontra

·         Beberapa fungsi kerja dapat dikembangkan dengan cepat dan awal dalam siklus hidup

·         Hasil diperoleh dini dan berkala

·         Pembangunan paralel dapat direncanakan

·         Kemajuan dapat diukur

·         Lebih murah untuk mengubah lingkup / persyaratan

·         Pengujian dan debugging selama iterasi lebih kecil mudah

·         Risiko diidentifikasi dan diselesaikan selama iterasi, dan setiap iterasi merupakan tonggak mudah dikelola

·         Mudah untuk mengelola risiko - bagian berisiko tinggi dilakukan terlebih dahulu

·         Dengan setiap produk operasional peningkatan disampaikan

·         Masalah, tantangan dan resiko diidentifikasi dari setiap kenaikan dapat dimanfaatkan / diterapkan pada kenaikan berikutnya

·         Analisis risiko yang lebih baik

·         Mendukung kebutuhan berubah

·         Waktu operasi awal kurang

·         Lebih cocok untuk proyek-proyek besar dan mission-critical

·         Selama siklus hidup perangkat lunak diproduksi awal yang memfasilitasi evaluasi pelanggan dan umpan balik  Lebih banyak sumber daya mungkin diperlukan

·         Meskipun biaya perubahan yang lebih rendah tetapi tidak sangat cocok untuk mengubah persyaratan Lebih banyak perhatian manajemen diperlukan

·         Arsitektur atau desain masalah sistem mungkin timbul karena tidak semua persyaratan dikumpulkan pada awal seluruh siklus hidup

·         Mendefinisikan bertahap mungkin memerlukan definisi dari sistem yang lengkap

·         Tidak cocok untuk proyek-proyek kecil

·         Kompleksitas manajemen lebih

·         Akhir proyek mungkin tidak diketahui yang merupakan risiko

·         Sumber daya yang sangat terampil yang diperlukan untuk analisis risiko

·         Kemajuan Project.s sangat tergantung up.

 

Prototype

Prototyping Model: Seringkali, pelanggan mendefinisikan satu set tujuan umum untuk perangkat lunak tetapi tidak mengidentifikasi input yang rinci, pengolahan, atau persyaratan output. Dalam kasus lain, pengembang mungkin tidak yakin efisiensi algoritma, adaptasi dari sistem operasi, atau bentuk interaksi manusia / mesin harus mengambil. Dalam hal ini, dan situasi lain, paradigma prototipe mungkin menawarkan pendekatan yang terbaik.

1.    communication: Pertama, pengembang dan pelanggan bertemu dan menentukan tujuan keseluruhan, persyaratan, dan area garis besar dimana definisi lebih lanjut adalah wajib.

2.    Quick Plan: Berdasarkan persyaratan dan lain-lain bagian komunikasi pesawat cepat dibuat untuk desain perangkat lunak.

3.    Modeling Quick Design: Berdasarkan pesawat cepat, terjadi 'A Desain Cepat'. Desain cepat berfokus pada representasi dari aspek-aspek perangkat lunak yang akan terlihat kepada pelanggan / pengguna, seperti pendekatan input dan format output.

4.    Constructions of Prototype: Desain cepat mengarah ke pembangunan prototipe.

5.    Deployment, Delivery, and Feedback: Prototipe ini dievaluasi oleh pelanggan / pengguna dan digunakan untuk memperbaiki persyaratan untuk perangkat lunak yang akan dikembangkan. Semua langkah ini diulang untuk menyempurnakan prototipe untuk memenuhi kebutuhan user. Pada saat yang sama memungkinkan pengembang untuk lebih memahami apa yang perlu dilakukan.

Masalah Dengan Prototipe Model:

·         Dalam terburu-buru untuk mendapatkan perangkat lunak bekerja kualitas perangkat lunak secara keseluruhan atau pemeliharaan jangka panjang tidak akan mendapatkan pertimbangan. Jadi perangkat lunak, dengan cara itu, mendapatkan kebutuhan modifikasi yang berlebihan untuk memastikan kualitas.

·         pengembang dapat memilih sistem operasi yang tidak pantas, algoritma, bahasa dalam terburu-buru untuk membuat prototipe bekerja

·         Prototyping adalah paradigma yang efektif untuk rekayasa perangkat lunak. Ini diperlukan untuk membangun prototipe untuk menetapkan persyaratan dan kemudian untuk insinyur perangkat lunak dengan mata ke arah kualitas.

Keuntungan Kerugian Prototyping Model Proses SDLC SDM wiki wikipedia

Keuntungan Prototyping Model

1.    Ketika prototipe ditunjukkan kepada pengguna, ia mendapat kejelasan yang tepat dan 'merasa' fungsi perangkat lunak dan ia dapat menyarankan perubahan dan modifikasi.

2.    Jenis pendekatan pengembangan perangkat lunak yang digunakan untuk orang-orang non-IT-melek. Mereka biasanya tidak pandai menentukan kebutuhan mereka, juga tidak bisa mengatakan dengan baik tentang apa yang mereka harapkan dari perangkat lunak.

3.    Bila klien tidak yakin tentang kemampuan pengembang, ia meminta prototipe kecil yang akan dibangun. Berdasarkan model ini, ia menilai kemampuan pengembang.

4.    Kadang-kadang membantu untuk menunjukkan konsep kepada calon investor untuk mendapatkan dana untuk proyek.

5.    Ini mengurangi risiko kegagalan, karena potensi risiko dapat diidentifikasi lebih awal dan langkah-langkah mitigasi dapat diambil.

6.    Iterasi antara tim pengembangan dan klien menyediakan lingkungan yang sangat baik dan konduktif selama proyek.

7.    Waktu yang dibutuhkan untuk menyelesaikan proyek setelah mendapatkan akhir mengurangi SRS, karena pengembang memiliki gagasan yang lebih baik tentang bagaimana ia harus mendekati proyek.

Kerugian Prototyping Model:

1.    Prototyping biasanya dilakukan pada biaya pengembang. Jadi harus dilakukan dengan menggunakan sumber daya minimal. Hal ini dapat dilakukan dengan menggunakan Rapid Application Development (RAD) alat. Harap dicatat kadang-kadang biaya start-up membangun tim pengembangan, berfokus pada pembuatan prototipe, tinggi.

2.    Setelah kita mendapatkan kebutuhan yang tepat dari klien setelah menunjukkan model prototipe, mungkin ada gunanya. Itulah sebabnya, kadang-kadang kita lihat prototipe sebagai "Throw-away" prototipe.

3.    Ini adalah proses yang lambat.

4.    Terlalu banyak keterlibatan klien, tidak selalu disukai oleh pengembang.

5.    Terlalu banyak perubahan dapat mengganggu ritme tim pengembangan.

Soal

1.    Apa resiko yang dihadapi jika pengembangan aplikasi (RPL) tidak mengikuti tahapan-tahapan SDLC?

2.    Mengapa ktika menerapkan metode Prototype, pada tahap awal harus benar-benar diperjelas batasan-batasan / ruang lingkup / spesifikasi perangkat lunak secara umum?

3.    Mengapa metode RAD bias memberikan hasil yang lebih cepat dibandingkan metode Waterfall?

Jawaban

1.    Karena jika pengembang aplikasi tidak mengikuti tahapan-tahapan SDLC maka tingkat kegagalan untuk membuat suatu system akan sangat terbuka lebar, karena kita tidak mengikuti tahapan-tahapan dari SDLC yaitu planning, analysis, design, implementasi, dsb. Karena SDLC tersebut memudahkan bagi kita untuk mengetahui apa yang menjadi keperluan user (pengguna).

2.    bahwa alih-alih membekukan persyaratan sebelum desain atau coding dapat dilanjutkan, prototipe sekali pakai dibangun untuk memahami persyaratan. Prototipe ini dikembangkan berdasarkan kebutuhan saat ini dikenal. Pengembangan prototipe jelas mengalami desain, coding dan pengujian. Tetapi masing-masing fase ini tidak dilakukan sangat formal maupun menyeluruh. Dengan menggunakan prototipe ini, klien bisa mendapatkan "sebenarnya merasa" dari sistem, karena interaksi dengan prototipe dapat mengaktifkan klien untuk lebih memahami persyaratan sistem yang diinginkan.

3.    Dalam model air terjun (waterfall) , setiap fase harus diselesaikan sebelum tahap berikutnya dapat dimulai dan tidak ada tumpang tindih dalam fase.

Air terjun Model (waterfall) menggambarkan proses pengembangan perangkat lunak dalam aliran sekuensial linier, dan karena itu juga disebut sebagai model siklus hidup linier–sekuensial. Ini berarti bahwa setiap fase dalam proses pembangunan dimulai hanya jika tahap sebelumnya selesai. Dalam fase model air terjun tidak tumpang tindih.

Sedangkan RAD model ini merupakan adaptasi dari model sekuensial linier dimana perkembangan yang cepat dicapai dengan menggunakan pendekatan kontruksi berbasis komponen. Sehingga jika kebutuhan system dipahami dengan baik, proses RAD memungkinkan developer menciptakan system fungsional yang utuh dalam periode waktu yang sangat pendek (± 60 sampai 90 hari). Karena dipakai terutama pada aplikasi system kontruksi.

Jadi kesimpulannya adalah metode RAD lebih cepat dibandingkan dengan metode Waterfall

REFERENSI

Ø  http://www.tutorialspoint.com/sdlc/sdlc_rad_model.htm

Ø  http://www.tutorialspoint.com/sdlc/sdlc_spiral_model.htm

Ø  http://www.tutorialspoint.com/sdlc/sdlc_agile_model.htm

Ø  http://www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm

Ø  http://www.tutorialspoint.com/sdlc/sdlc_iterative_model.htm

Ø  http://tanmayonrun.blogspot.com/2013/01/describe-prototyping-model.html