Waterfall Pengembangan Metodologi desain asli terstruktur (yang masih digunakan hari) adalah pembangunan air terjun.

Dengan terjun pembangunan berbasis metodologi, para analis dan pengguna melanjutkan secara berurutan dari satu tahap ke tahap berikutnya (lihat Gambar 12). Kuncinya kiriman untuk setiap tahap biasanya sangat panjang (sering ratusan halaman panjang) dan disajikan kepada sponsor proyek untuk persetujuan sebagai proyek bergerak dari fase ke fase. Setelah sponsor menyetujui pekerjaan yang dilakukan selama fase, fase berakhir dan berikutnya dimulai. Metodologi ini disebut sebagai pembangunan air terjun karena bergerak maju dari fase ke fase dalam cara yang sama seperti air terjun. Meskipun dimungkinkan untuk pergi mundur dalam SDLC (misalnya, dari desain kembali ke analisis), adalah sangat sulit (bayangkan diri Anda sebagai salmon mencoba berenang "hulu" terhadap air terjun, seperti yang ditunjukkan pada Gambar 1-2). Desain terstruktur juga memperkenalkan penggunaan pemodelan formal atau teknik diagram untuk menggambarkan proses bisnis dasar dan data yang mendukung mereka. Tradisional desain terstruktur menggunakan satu set diagram untuk mewakili proses dan satu set terpisah diagram untuk merepresentasikan data. Karena dua set diagram yang digunakan, analis sistem harus memutuskan mana diatur untuk mengembangkan pertama dan digunakan sebagai inti dari sistem-proses-model diagram atau data-model diagram. Ada banyak perdebatan di mana harus didahulukan, proses atau data, karena keduanya penting bagi sistem.Akibatnya, beberapa yang berbeda terstruktur metodologi desain telah berevolusi yang mengikuti langkah-langkah dasar dari model air terjun, tetapi menggunakan berbeda pemodelan pendekatan pada waktu yang berbeda. Mereka yang mencoba untuk menekankan processModel diagram sebagai inti dari sistem adalah proses-berpusat, sementara mereka yang menekankan Data-model diagram sebagai inti dari konsep sistem adalah data-berpusat. Dua keuntungan utama dari pendekatan air terjun desain terstruktur adalah bahwa hal itu mengidentifikasi persyaratan sistem jauh sebelum program dimulai dan meminimalkan perubahan pada persyaratan sebagai hasil proyek. Dua kelemahan utama adalah bahwa desain harus benar-benar ditentukan sebelum program dimulai dan bahwa waktu yang lama berlalu antara penyelesaian proposal sistem dalam tahap analisis dan pengiriman sistem (Bulan biasanya banyak atau tahun). Kiriman panjang sering merupakan komunikasi yang buruk Mekanisme, hasilnya adalah bahwa persyaratan penting dapat diabaikan dalam tebal dokumentasi. Pengguna jarang dipersiapkan untuk diperkenalkan ke sistem baru, yang terjadi lama setelah ide awal untuk sistem diperkenalkan. Jika tim proyek merindukan persyaratan penting, mahal pasca-pelaksanaan program mungkin diperlukan (Bayangkan diri Anda mencoba untuk merancang sebuah mobil di atas kertas, bagaimana mungkin akan Anda akan ingat interior lampu itu datang pada saat pintu terbuka, atau untuk menentukan jumlah yang tepat dari katup pada mesin?). Sebuah sistem juga mungkin memerlukan pengerjaan ulang yang signifikan karena lingkungan bisnis memiliki berubah dari waktu bahwa fase analisis terjadi.Ketika perubahan memang terjadi, itu berarti akan kembali ke fase awal dan mengikuti perubahan melalui masing-masing selanjutnya fase pada gilirannya. Pembangunan Paralel Upaya metodologi pengembangan paralel untuk mengatasi masalah penundaan yang lama antara tahap analisis dan pengiriman sistem. Malah melakukan desain dan implementasi secara berurutan, ia melakukan desain umum untuk seluruh sistem dan kemudian membagi proyek menjadi serangkaian sub-proyek yang berbeda yang dapat dirancang dan dilaksanakan secara paralel. Setelah semua subproyek yang lengkap, ada akhir integrasi dari potongan-potongan yang terpisah, dan sistem disampaikan (lihat Gambar 1-3).

Keuntungan utama dari metodologi ini adalah bahwa hal itu dapat mengurangi waktu jadwal untuk memberikan sistem, dengan demikian, ada sedikit kesempatan untuk perubahan dalam lingkungan bisnis menyebabkan ulang. Namun, pendekatan ini masih menderita masalah yang disebabkan oleh dokumen kertas. i juga menambah masalah baru: Terkadang subproyek tidak benar-benar independen; desain keputusan yang dibuat dalam satu subproyek dapat mempengaruhi yang lain, dan akhir proyek dapat memerlukan upaya integrasi signifikan. Masalah halus mungkin dengan RAD berbasis metodologi: user manajemen ekspektasi. Karena dengan penggunaan alat-alat dan teknik yang dapat meningkatkan kecepatan dan kualitas pengembangan sistem, pengguna harapan apa yang mungkin dapat berubah secara dramatis. Sebagai pengguna yang lebih baik memahami teknologi informasi, persyaratan sistem cenderung untuk memperluas. Ini adalah kurang dari masalah ketika menggunakan metodologi yang menghabiskan banyak waktu secara menyeluruh mendokumentasikan ; Ada metodologi proses-berpusat, data-berpusat dan berorientasi obyek yang mengikuti pendekatan dasar dari tiga kategori RAD dijelaskan di bawah ini. Bertahap Pembangunan Sebuah metodologi pengembangan berbasis bertahap istirahat sistem secara keseluruhan menjadi serangkaian versi yang dikembangkan secara berurutan.Tahap analisis mengidentifikasi keseluruhan konsep sistem, dan tim proyek, pengguna, dan sistem sponsor kemudian mengkategorikan persyaratan menjadi serangkaian versi. Persyaratan yang paling penting dan mendasar yang dibundel ke dalam versi pertama dari sistem. Tahap analisis kemudian mengarah ke desain dan pelaksanaan, tetapi hanya dengan set persyaratan yang diidentifikasi untuk versi 1 (lihat Gambar 1-4). Setelah versi 1 diimplementasikan, pekerjaan dimulai pada versi 2. Analisis tambahan dilakukan berdasarkan persyaratan yang sebelumnya diidentifikasi dan dikombinasikan dengan ide-ide baru dan isu-isu yang muncul dari pengalaman pengguna dengan versi 1. Versi 2 kemudian dirancang dan diimplementasikan, dan bekerja segera dimulai pada versi berikutnya. Proses ini berlanjut sampai sistem selesai atau tidak lagi digunakan. Bertahap pembangunan berbasis metodologi memiliki keuntungan cepat mendapatkan berguna sistem ke tangan pengguna.Sementara sistem tidak melakukan semua fungsi para pengguna perlu pada awalnya, hal itu mulai memberikan nilai bisnis lebih cepat daripada jika sistem itu disampaikan setelah selesai, seperti halnya dengan air terjun atau metodologi paralel. Demikian juga, karena pengguna mulai bekerja dengan sistem cepat, mereka lebih cenderung untuk mengidentifikasi persyaratan tambahan yang penting cepat dibandingkan dengan situasi desain terstruktur. Kelemahan utama pembangunan bertahap adalah bahwa pengguna mulai bekerja dengan sistem yang sengaja tidak lengkap. Hal ini penting untuk mengidentifikasi fitur yang paling penting dan berguna dan memasukkan mereka dalam versi pertama, sambil mengelola ekspektasi pengguna 'sepanjang jalan. Prototyping Metodologi prototyping berbasis melakukan analisis, desain, dan Pelaksanaan fase bersamaan, dan ketiga fase dilakukan berulang kali dalam siklus sampai sistem selesai.Dengan metodologi, dasar-dasar analisis dan desain dilakukan, dan bekerja segera dimulai pada prototipe sistem, "cepat-anddirty" Program yang menyediakan jumlah minimal fitur. Prototipe pertama biasanya bagian pertama dari sistem bahwa pengguna akan digunakan. Hal ini ditunjukkan dengan pengguna dan

sponsor proyek yang memberikan komentar, yang digunakan untuk menganalisis kembali, redesain, dan reimplement prototipe kedua yang menyediakan beberapa fitur. Proses ini berlanjut dalam siklus sampai analis, pengguna, dan sponsor sepakat bahwa prototipe menyediakan cukup fungsi untuk diinstal dan digunakan dalam organisasi. Setelah (prototipe sekarang disebut sistem) diinstal, perbaikan terjadi sampai diterima sebagai sistem baru (Lihat Gambar 1-5). Keuntungan utama dari metodologi prototyping berbasis adalah bahwa hal itu sangat cepat memberikan sistem bagi pengguna untuk berinteraksi dengan, bahkan jika itu tidak siap untuk organisasi luas gunakan pada awalnya. Prototyping meyakinkan pengguna bahwa tim proyek bekerja pada sistem (Tidak ada penundaan yang lama di mana pengguna melihat sedikit kemajuan), dan prototyping membantu lebih cepat memperbaiki persyaratan yang nyata. Daripada mencoba untuk memahami sistem spesifikasi di atas kertas, pengguna dapat berinteraksi dengan prototipe untuk lebih memahami apa yang dapat dan tidak dapat lakukan. Masalah utama dengan prototyping adalah bahwa cepat yang rilis sistem menantang upaya untuk melakukan hati, analisis metodis. Seringkali prototipe mengalami signifikan seperti perubahan yang banyak keputusan desain awal menjadi orang miskin. Hal ini dapat menyebabkan masalah dalam pengembangan sistem yang kompleks karena isu-isu fundamental dan masalah yang tidak diakui sampai dengan baik ke dalam proses pembangunan. Bayangkan membangun mobil dan menemukan terlambat dalam proses prototyping bahwa Anda harus mengambil mesin seluruh keluar untuk mengubah minyak (karena tidak ada yang berpikir tentang perlunya untuk mengubah minyak sampai setelah itu didorong 10.000 mil). Metodologi Prototyping lembaran lembaran prototyping berbasis sama dengan prototyping berbasis metodologi dalam bahwa mereka mencakup pengembangan prototipe; Namun prototipe lembaran yang dilakukan pada titik yang berbeda dalam SDLC. Ini prototipe digunakan untuk tujuan yang sangat berbeda dari yang dibahas sebelumnya, dan mereka memiliki sangat berbeda penampilan (lihat Gambar 1-6). Metodologi lembaran prototyping berbasis memiliki analisis yang relatif menyeluruh fase yang digunakan untuk mengumpulkan informasi dan mengembangkan ide-ide untuk konsep sistem. Namun, banyak fitur yang disarankan oleh pengguna tidak dapat dipahami dengan baik, dan mungkin ada menantang masalah teknis yang harus diselesaikan. Masing-masing masalah ini diperiksa oleh menganalisis, merancang, dan membangun prototipe desain.Sebuah prototipe desain tidak sedang bekerja Sistem, yang merupakan produk yang merupakan bagian dari sistem yang perlu perbaikan tambahan, dan itu hanya berisi detail yang cukup untuk memungkinkan para pengguna memahami isu-isu di bawah pertimbangan. Misalnya, pengguna tidak sepenuhnya jelas tentang bagaimana sebuah order entry Sistem harus bekerja. Tim analis mungkin membangun serangkaian halaman HTML dilihat menggunakan