Cara Menggunakan nTask untuk Manajemen Proyek Waterfall – Panduan Praktis untuk Pertama Kali

Kami melakukan analisis ekstensif terhadap berbagai faktor yang memengaruhi manajemen proyek air terjun. Ini membantu kami menyederhanakan bagaimana perangkat lunak manajemen proyek nTask dapat digunakan untuk memecahkan masalah tersebut. Waterfall adalah model manajemen proyek SDLC yang populer.

Namun, ini rumit di berbagai titik. Artikel ini merinci bagaimana Anda dapat menggunakan nTask untuk bertahan dengan produktivitas maksimum terkait semua model bisnis berorientasi air terjun Anda. Kami telah bekerja lebih keras untuk mengilustrasikan berbagai kasus penggunaan kehidupan nyata dan contoh di mana air terjun diimplementasikan, dan bagaimana seseorang dapat menggunakan nTask untuk lebih menyederhanakan proses itu – seterusnya dan seterusnya.

Apa yang Perlu Anda Ketahui tentang Manajemen Proyek Waterfall?

Metodologi Waterfall adalah metodologi tradisional dan paling umum digunakan untuk manajemen proyek. Ini mengikuti proses linier sekuensial itulah sebabnya sering digambarkan sebagai "model siklus hidup sekuensial linier". Seperti namanya, Waterfall berfokus pada perencanaan siklus hidup proyek dengan membagi proyek menjadi bagian-bagian yang berbeda, terpisah dan eksklusif: Dalam model Waterfall, setiap fase harus diselesaikan sebelum fase berikutnya dapat dimulai.

Penyelesaian setiap langkah khas dalam metodologi Waterfall mengarah ke tahap proyek berikutnya seperti air terjun yang sebenarnya. Setelah segmen proyek selesai, tidak ada perubahan lain yang dapat dibuat untuk itu dan tidak ada satu langkah pun yang dapat dilewati untuk menyelesaikan yang berikutnya. Oleh karena itu, setiap tahap bergantung pada penyelesaian langkah atau level sebelumnya. Hal ini membuat Model Waterfall paling berguna untuk proyek yang lebih kecil dengan persyaratan yang terdefinisi dengan baik dan ketidakpastian yang lebih sedikit. Kesederhanaan dan kemudahan penerapannya telah menjadikannya versi paling populer dari siklus hidup pengembangan sistem (SDLC) untuk rekayasa perangkat lunak dan proyek TI.

Saat menggunakan Model Air Terjun, penekanannya terletak pada memastikan persyaratan dan desain sesuai dengan kebutuhan proyek sebelum melanjutkan ke tahap pengembangan selanjutnya.

Latar belakang manajemen proyek air terjun

Sumber – Codeacademy.com

Asal usul Model Air Terjun sering dikaitkan dengan industri manufaktur dan konstruksi. Metodologi Waterfall sangat ideal untuk industri ini karena mereka mengikuti proses produksi yang sangat terstruktur: persyaratan dinyatakan dengan jelas dan digariskan selama tahap awal proses dan tahap lainnya dirancang berdasarkan persyaratan. Sama seperti dalam metodologi Waterfall, setiap perubahan selanjutnya dalam setiap tahap siklus manajemen proyek tidak hanya terlalu mahal tetapi tidak mungkin dalam beberapa kasus.

Dr. Winston W. Royce sering tetapi keliru disebut "bapak Air Terjun", diakreditasi dengan deskripsi formal pertama dari proses dalam sebuah artikel yang dia tulis pada tahun 1970. Apa yang Dr. Royce gambarkan adalah model yang cacat untuk pengembangan perangkat lunak saat dia berpendapat untuk model dengan beberapa iterasi atau berjalan. Dia berpendapat bahwa tanpa beberapa iterasi proyek, dengan yang pertama menjadi prototipe, proyek akan terlalu berisiko dan bahkan mengundang kegagalan. Menurutnya, iterasi prototipe sangat penting untuk lebih memahami persyaratan dan teknologi yang terlibat dalam proyek dan untuk memastikan bahwa produk akhir memberikan apa yang dibutuhkan pelanggan.

Bacaan Tambahan:

7 Fitur Teratas yang Harus Dicari di Alat Manajemen Proyek Gratis Anda

Sementara Dr. Royce dikaitkan dengan deskripsi proses yang diketahui pertama kali, presentasi pertama yang diketahui dikaitkan dengan Herbert D. Benington. Pada tanggal 29 Juni 1956, Herbert D. Benington memberikan presentasi tentang pengembangan perangkat lunak untuk SAGE di Simposium tentang metode pemrograman tingkat lanjut untuk komputer digital. Dalam presentasinya, ia menjelaskan penggunaan fase-fase tersebut dalam rekayasa perangkat lunak. Masih istilah, "Air Terjun" tidak digunakan untuk menggambarkan proses.

Menurut Wikipedia, Bell dan Thayer adalah orang pertama yang menggunakan istilah "Air Terjun" dalam makalah tahun 1976.

Pada 1980-an, Model Air Terjun mendapat kritik keras karena sifatnya yang kaku.

Karena perubahan kebutuhan industri pengembangan perangkat lunak dan kegagalan linieritas Model Waterfall dalam memberikan umpan balik awal, banyak versi Model Waterfall telah muncul. Versi ini sering secara kolektif disebut sebagai Model Air Terjun Modifikasi.

Model Waterfall yang lebih modern memiliki loop umpan balik ke fase sebelumnya untuk memungkinkan modifikasi. Versi lain dari model Air Terjun adalah "model sashimi" Peter DeGrace (air terjun dengan fase yang tumpang tindih), Model-V atau Model Air Terjun Bent, dll.

Metodologi Air Terjun dan Evolusinya – Model Air Terjun Tradisional

Sejak tahun 1970-an, bisnis dan proyek telah menggunakan metodologi Waterfall untuk manajemen proyek. Memanfaatkan diagram alur sederhana yang dimulai dari titik A dan mengikuti langkah-langkah berurutan untuk mencapai akhirnya tidak hanya mudah dipahami tetapi juga diterapkan. Tahapan metodologi Waterfall dikembangkan oleh Dr. Royce dengan tujuan mencegah revisi yang mahal di bagian akhir dari siklus pengembangan proyek. Dr. Royce mencoba menjelaskan bagaimana dalam pengalamannya Model Air Terjun dilengkapi dengan risiko kegagalan.

Dalam model air terjun asli Royce, ia menguraikan tahapan ini untuk menekankan pentingnya langkah-langkah ini untuk proyek pengembangan perangkat lunak yang besar dan kompleks. Dia juga ingin menunjukkan bahwa karena langkah-langkah tersebut direncanakan dan dijalankan secara berbeda, pemanfaatan sumber daya yang terbaik mengharuskan tim harus menyertakan orang-orang yang dapat melakukan langkah-langkah ini dengan paling baik.

Tahapan Khas Model Air Terjun

Berbagai tahapan Model Air Terjun dapat dimodifikasi, dihilangkan atau ditambah tergantung pada kerangka kerja dan persyaratan proyek.

Langkah-langkah berurutan dalam model Waterfall tipikal adalah sebagai berikut:

1. Konsepsi : Fase ini adalah di mana ide untuk proyek berkecambah. Fase ini melibatkan penilaian kasar dari proses, misalnya apakah proyek tersebut menguntungkan, berapa biaya yang akan dikeluarkan, dll.
2. Inisiasi : Setelah konsepsi, proyek dimulai dengan mempekerjakan tim proyek, mendefinisikan tujuan, ruang lingkup, tujuan, dan hasil. Tahap ini sangat penting karena Model Air Terjun menekankan memastikan bahwa persyaratan dan desain sesuai dengan kebutuhan proyek.
3. Pengumpulan dan Analisis Persyaratan : Semua persyaratan proyek yang mungkin dikumpulkan dan dianalisis oleh tim untuk melihat kelayakan proyek. Ini mungkin juga mengharuskan tim memahami model bisnis klien dan menganalisis potensi risiko yang terkait dengan proyek. Semua informasi yang dibuat pada fase ini kemudian didokumentasikan dalam dokumen spesifikasi kebutuhan.
4. Desain : Pada fase ini, spesifikasi kebutuhan dipelajari, dievaluasi dan desain sistem disiapkan untuk penyelesaian proyek. Persyaratan perangkat keras dan perangkat lunak diidentifikasi dan arsitektur sistem secara keseluruhan didefinisikan. Spesifikasi desain yang dibuat pada fase ini digunakan pada fase coding.
5. Implementasi/Pengkodean : Ini adalah fase di mana pengembangan/pengkodean sebenarnya dimulai sesuai dengan spesifikasi desain. Manajer proyek mendelegasikan tugas di antara anggota tim yang biasanya terdiri dari pemrogram, perancang antarmuka, dan spesialis lainnya, menggunakan alat seperti kompiler, debugger, juru bahasa, dan editor media. Tergantung pada sifat proyek dan ukuran tim, tim dibagi menjadi unit yang lebih kecil.
6. Dalam kebanyakan kasus, sistem pertama kali dikembangkan dalam program kecil yang disebut unit dan diintegrasikan ke fase berikutnya. Saat setiap unit berkembang, itu diuji fungsinya, yang disebut sebagai Pengujian Unit. Keluaran akhir dari langkah ini dapat berupa satu atau lebih komponen produk yang dibangun sesuai dengan standar pengkodean yang telah ditentukan sebelumnya dan di-debug, diuji, dan diintegrasikan untuk memenuhi persyaratan arsitektur sistem. Tidak peduli ukuran tim, kolaborasi dan koordinasi sangat penting untuk memastikan bahwa semua persyaratan terpenuhi.
7. Pengujian : Setelah semua unit yang dikembangkan terintegrasi, seluruh sistem yang dikembangkan kemudian diuji untuk setiap kesalahan. Pada fase ini, pemenuhan harapan klien juga diverifikasi.
8. Deployment : Setelah menyelesaikan semua pengujian, produk atau proses dikirimkan ke pelanggan, dirilis ke pasar atau diimplementasikan. Selama proses ini, semua pedoman, peraturan, dan/atau pedoman organisasi khusus industri yang lazim harus dipatuhi dengan ketat. Selanjutnya, verifikasi dan pengujian pasca implementasi harus dilakukan untuk memastikan keberhasilan implementasi akhir.
9. Pemeliharaan : Jika ada masalah yang diidentifikasi oleh pengguna akhir, tim pengembangan diperlukan untuk menyelesaikan, mengubah, atau memodifikasi produk untuk memastikan efektivitasnya. Jangka waktu pemeliharaan biasanya untuk jangka waktu tertentu dan telah disepakati sebelumnya.

Diagram 2: Representasi Dasar Model Waterfall Khas untuk Pengembangan Perangkat Lunak

Popularitas Model Air Terjun PM

Mengapa Model Air Terjun mendapatkan popularitas di mana-mana meskipun ada upaya Dr. Royce dalam memperingatkan orang-orang tentang jebakan model?

Metodologi Waterfall adalah metodologi yang paling umum digunakan untuk manajemen proyek. Model ini digunakan di berbagai industri bahkan sebelum nama "air terjun" diberikan. Alasan utama popularitas dan penggunaan luas Model Air Terjun adalah sebagai berikut:

• Mudah dipahami, digunakan, dan dikelola

Sebagian besar manajer proyek menemukan struktur Model Air Terjun mudah dipahami dan diterapkan karena mengikuti siklus hidup proyek. Selain itu, tidak perlu melatih tim dan membiasakan mereka dengan metodologi Waterfall. Kekakuan seluruh proses tidak hanya membuatnya mudah untuk diterapkan dan dikendalikan, tetapi juga mengurangi beban manajemen proyek.

• Berdisiplin

Pendekatan Model Waterfall yang terstruktur dengan jelas membuatnya mudah untuk dipantau dan ketika setiap tahap selesai, manajer proyek dan klien dapat melihat kemajuan yang terlihat. Karena jumlah waktu maksimum yang dihabiskan pada fase persyaratan dan desain, kemungkinan tim melewatkan tenggat waktu berkurang secara drastis.

• Dokumentasi Berkualitas dan Terperinci

Dokumentasi dipelihara dan diperbarui sejak tahap awal. Dokumen cara yang ketat diperbarui memastikan bahwa ada pemahaman yang lengkap antara tim dan klien tentang apa yang akan disampaikan. Hal ini tidak hanya membuat perencanaan dan perancangan lebih mudah tetapi juga membantu pemangku kepentingan jika mereka perlu melihat lebih detail tentang fase tertentu.

• Keterlibatan Pelanggan Minimum

Model Air Terjun dirancang sedemikian rupa sehingga setelah persyaratan didefinisikan dan dipahami dengan jelas, kehadiran pelanggan tidak sepenuhnya diperlukan. Ini menghilangkan beban tambahan apa pun pada tim dan mencegah pengenalan perubahan baru apa pun di fase proyek selanjutnya, yang pada gilirannya memastikan penyelesaian proyek tepat waktu.

• Departementalisasi

Fleksibilitas Model Waterfall memungkinkan berbagai anggota tim untuk terlibat atau melanjutkan pekerjaan pada proyek lain tergantung pada fase mana proyek tersebut masuk. Dengan tenggat waktu terjadwal yang ditetapkan untuk setiap tahap pengembangan, proyek bergerak melalui proses pengembangan secara berurutan membebaskan sumber daya .

• Asuransi Berkualitas

Model ini sangat ideal untuk proyek-proyek yang persyaratannya didefinisikan dengan jelas dan ketat dan di mana setiap perubahan persyaratan nantinya tidak mungkin dilakukan. Selain itu, Model Air Terjun sangat ideal untuk proyek-proyek di mana kualitas produk lebih diutamakan dari waktu ke waktu atau masalah biaya.

Mengapa Tidak Lebih Banyak Proyek Menggunakan Model Manajemen Proyek Waterfall?

Beberapa keuntungan terbesar dari Model Air Terjun berubah menjadi kekurangannya tergantung pada sifat proyeknya.

Keterbatasan terbesar metodologi Waterfall untuk proyek pengembangan perangkat lunak adalah tidak cocok untuk proyek skala besar atau panjang. Kerugian lainnya termasuk: (6)

• Sedikit atau Tidak Ada Perubahan atau Revisi:

Penekanan Model Air Terjun pada persyaratan yang jelas dan terdefinisi dengan baik berarti bahwa setelah diselesaikan, setiap perubahan persyaratan tidak hanya akan sulit tetapi juga mahal. Dengan demikian, Model Waterfall tidak cocok untuk proyek dengan persyaratan yang tidak jelas. Ini juga berarti bahwa setiap perubahan dalam perangkat lunak dan perangkat keras dalam proyek jangka panjang akan sulit untuk diatasi. Ini juga menyiratkan bahwa setiap kejadian proyek yang tidak terduga tidak dapat diatasi dengan menggunakan metode ini.

• Keterlambatan Pengiriman Produk:

Karena tahap awal model dikhususkan untuk memahami persyaratan, pengembangan perangkat lunak dimulai kemudian dalam siklus hidup proyek. Ini berarti bahwa para pemangku kepentingan tidak dapat melihat perangkat lunak sampai nanti dalam siklus hidup proyek.

• Ketidakpraktisan Gathering Persyaratan yang Akurat dan Lengkap :

Mengumpulkan persyaratan yang jelas, terdefinisi dengan baik dan lengkap pada fase awal tidak hanya sulit, untuk beberapa proyek juga tidak praktis. Seringkali pelanggan tidak memiliki gambaran yang jelas tentang semua persyaratan di awal siklus hidup proyek, sebaliknya mereka mempelajari dan mengklarifikasi persyaratan saat proyek berlangsung.

Penggambaran Modern Model Air Terjun

Terlepas dari berbagai kekurangannya, Model Waterfall modern adalah salah satu model siklus hidup pengembangan perangkat lunak (SDLC) yang paling umum. Versi modern Model Waterfall berisi loop umpan balik di seluruh siklus hidup proyek termasuk pemeliharaan pasca pengiriman.

Dalam model ini, Pengujian bukanlah fase yang terpisah melainkan dilakukan terus menerus selama proses perangkat lunak. Hal ini diberikan kepentingan khusus selama fase pemeliharaan untuk memastikan bahwa tidak hanya perangkat lunak yang bekerja sesuai kebutuhan tetapi juga persyaratan tambahan yang dimasukkan ke dalam desain.

Model Air Terjun Modern dengan jelas menggambarkan rute yang harus diambil selama pengembangan dan pemeliharaan hingga penghentian perangkat lunak. Model Air Terjun Modern menghilangkan banyak masalah dengan Model Air Terjun tradisional, namun model ini memiliki masalah tersendiri. Misalnya, penyelesaian setiap fase mencakup dokumentasi yang lengkap dan berkualitas dari fase tersebut dan persetujuan oleh kelompok jaminan kualitas perangkat lunak (SQA) dan ini juga harus dilakukan jika ada modifikasi. Desakan untuk memelihara dokumentasi yang lengkap dapat mengakibatkan penundaan dan dokumen yang tidak perlu.

Model Kasus Penggunaan Super ATM ACME untuk Penarikan Uang Tunai

Deskripsi singkat:

Use case ini menjelaskan bagaimana Nasabah Bank menggunakan ATM untuk menarik uang dari rekening bank.

Aktor:

Gambar di bawah menunjukkan semua aktor dalam model kasus penggunaan ACME Super ATM.

Aktor-aktor tersebut meliputi pelanggan, sistem bank, administrator layanan dan administrator keamanan.

Prasyarat:

• Nasabah bank harus memiliki kartu bank.
• Koneksi jaringan ke Sistem Bank harus aktif.
• Sistem harus memiliki setidaknya sejumlah uang tunai yang dapat dikeluarkan.
• Pilihan layanan tarik tunai harus tersedia.

Lihat Juga:

5 Tantangan Umum Manajemen Proyek dan Solusi untuk Mengatasinya Seperti Profesional

Aliran Dasar:

• Masukkan kartu
• Baca Kartu
• Otentikasi Pelanggan
• Pilih Penarikan
• Sistem menampilkan berbagai opsi layanan yang saat ini tersedia di mesin
• Pilih Jumlah
• Sistem meminta jumlah yang akan ditarik dengan menampilkan daftar jumlah penarikan standar
• Konfirmasi Penarikan
• Lakukan Penilaian Dana di Tangan
• Lakukan Transaksi Perilaku
• Keluarkan Kartu
• Pelanggan mengambil kartu bank dari mesin
• Keluarkan Uang Tunai
• Sistem membagikan jumlah yang diminta kepada Pelanggan
• Sistem mencatat entri log transaksi untuk penarikan
• Gunakan Kasus Akhir

Aliran Alternatif:

Aliran Alternatif mencakup aliran untuk skenario berikut:

• Menangani Penarikan Jumlah Non-Standar
• Menangani Kartu Bank yang Tidak Dapat Dibaca
• Penanganan Tanda Terima
• Penanganan Kesalahan
• Menangani Sistem Bank Berhenti Merespon

Aliran Pengecualian:

Aliran Pengecualian mencakup aliran untuk skenario berikut ini:

• Nilai Dana di Tangan
• Lakukan Penarikan
• Layanan Penutupan
• Menangani Penyesuaian Transaksi

Ketentuan Posting:

• ATM telah mengembalikan kartu dan memberikan uang tunai kepada Nasabah, dan penarikan tersebut terdaftar di rekening Nasabah.
• ATM telah mengembalikan kartu kepada Nasabah, dan tidak ada penarikan yang tercatat pada rekening Nasabah.
• ATM telah mengembalikan kartu, tetapi belum memberikan jumlah uang tunai yang terdaftar sebagai penarikan dari rekening Nasabah; perbedaan tersebut dicatat pada log ATM.
• ATM telah menyimpan kartu, tidak ada penarikan yang terdaftar di rekening Nasabah, dan Nasabah telah diberitahu ke mana harus menghubungi untuk informasi lebih lanjut.

Poin Ekstensi Publik:

Tidak ada

Persyaratan Khusus

• Pengeluaran Uang Tunai yang Andal

Dalam Model Kasus Penggunaan Super ATM ACME untuk Penarikan Uang Tunai, semua persyaratan ditetapkan dan didefinisikan dengan jelas, maka Model Air Terjun sangat ideal untuk contoh ini. Setelah persyaratan dicatat, sangat sedikit umpan balik yang diperlukan dari pelanggan dan tahap pengembangan dan desain dapat diselesaikan mengikuti pola sekuensial liner. Proyek dapat dengan mudah dikelola dengan bantuan perangkat lunak manajemen proyek seperti nTask dengan setiap tahap didefinisikan dengan jelas dan dipecah sesuai dengan kebutuhan.

Model Kasus Penggunaan Super ATM ACME untuk Mengautentikasi Pelanggan

Deskripsi singkat:

Kasus penggunaan ini digunakan untuk mengautentikasi bahwa individu yang menggunakan ATM (Nasabah) berwenang untuk menggunakan kartu bank yang dimasukkan dan bahwa akun yang terkait dengan kartu bank tersebut aktif.

Aktor:

Aktor-aktor tersebut meliputi pelanggan, sistem bank, administrator layanan dan administrator keamanan.

Prasyarat:

• Kartu bank telah dimasukkan ke dalam ATM.
• Informasi kartu bank telah berhasil dibaca.
• Pelanggan sedang berdialog dengan use case yang disertakan.
• ID Sesi ATM telah dibuat.

Aliran Dasar

• Validasi Informasi Kartu
• Sistem mengirimkan informasi kartu bank ke Sistem Bank
• Sistem juga mengirimkan ID ATM dan pengenal sesi ATM ke Sistem Bank
• Sistem Bank mengakui bahwa informasi kartu bank adalah valid dan kartu tersebut dapat digunakan
• Validasi Identitas Pengguna
• Sistem meminta PIN kepada Pelanggan
• Pelanggan memasukkan PIN
• Sistem memeriksa apakah PIN yang dimasukkan identik dengan PIN yang dibaca dari kartu bank
• PIN Divalidasi
• Kasus Penggunaan Berakhir

Aliran Alternatif:

Aliran Alternatif mencakup aliran untuk skenario berikut:

• Menangani Tidak Ada Komunikasi Dengan Sistem Bank
• Menangani Tidak Ada Komunikasi Dengan Bank Nasabah
• Menangani Kartu atau Akun Tidak Aktif
• Menangani Kartu Bank yang Dicuri
• Menangani Informasi Kartu Bank yang Tidak Valid
• Tangani PIN yang Benar Tidak Dimasukkan
• Penanganan Kesalahan
• Menangani Sistem Bank Berhenti Merespon

Aliran Pengecualian:

Aliran Pengecualian mencakup aliran untuk skenario berikut ini:

• Nilai Dana di Tangan
• Lakukan Penarikan
• Layanan Penutupan
• Menangani Penyesuaian Transaksi

Ketentuan Posting:

• Pelanggan telah diberi wewenang untuk menggunakan kartu tersebut.
• Nasabah dilarang menggunakan kartu, dan kartu telah disita.
• Nasabah dilarang menggunakan kartu, dan kartu belum disita.

Poin Ekstensi Publik

Tidak ada

Persyaratan Khusus

Tidak ada

Dalam Model Kasus Penggunaan Super ATM ACME untuk Mengautentikasi Pelanggan, semua persyaratan ditetapkan dan didefinisikan dengan jelas. Ukuran proyek kecil dan dapat dengan mudah diselesaikan dengan bantuan proses yang kaku. Setelah persyaratan telah dicatat, tahap pengembangan dan desain dapat diselesaikan dalam proses linier. Proyek dapat dengan mudah dikelola dengan bantuan perangkat lunak manajemen proyek seperti nTask dengan setiap tahap didefinisikan dengan jelas dan dipecah sesuai dengan kebutuhan.

Aplikasi Industri – Departemen Pertahanan Amerika Serikat

Contoh penggunaan metodologi Waterfall yang banyak direferensikan adalah Departemen Pertahanan Amerika Serikat. Pada tahun 1985, Departemen Pertahanan Amerika Serikat menggunakan pendekatan Waterfall di DOD-STD-2167A, standar mereka untuk bekerja dengan kontraktor pengembangan perangkat lunak. Meskipun mereka tidak menentukan metodologi mereka sebagai "air terjun", Departemen Pertahanan Amerika Serikat (DOD) masih menggunakan prinsip-prinsip dasar Model Air Terjun.

Pemerintah Amerika Serikat menetapkan Model Air Terjun karena keunggulan model memenuhi persyaratannya dengan sempurna. Pemerintah federal bersikeras pada ketelitian teknik dan produk kualitas unggul sambil mempertahankan kontrol besar atas produk akhir. Ini bersama dengan dimasukkannya enam fase-Desain Awal, Desain Terperinci, Pengkodean, dan Pengujian Unit, Integrasi, dan Pengujian-dikombinasikan dengan dokumentasi yang luas, preferensi yang kuat untuk metode pengembangan sekuensial single-pass, dan pengawasan berat membuat DOD -STD-2167 contoh terbaik dari Metode Air Terjun.

Pada tahun 1986, salinan draf Revisi A ke MIL-STD 2167 muncul yang menghilangkan penekanan pada desain top-down dan mengusulkan penggunaan prototipe cepat sebagai alternatif air terjun. Ini karena Model Air Terjun mendapat kritik keras selama ini. Terlepas dari kenyataan bahwa DOD telah menjauhkan diri dari Metodologi Air Terjun, pengembangan dan akuisisi perangkat lunak Federal AS masih mempertahankan pendekatan berorientasi perangkat keras dan air terjun yang kuat.

Sebuah laporan 2010 oleh National Research Council menekankan berapa banyak terminologi yang digunakan untuk menggambarkan fase pengembangan teknik dan manufaktur yang berfokus pada elemen Model Air Terjun seperti tinjauan desain awal dan tinjauan desain kritis. Penekanan pada Metodologi Manajemen Proyek Air Terjun ini dapat disebabkan oleh peningkatan penekanan pada kualitas dan kerahasiaan. Fase terpisah dari Model Waterfall memastikan bahwa tidak setiap anggota tim terlibat dalam keseluruhan proyek.

Pada tahun 2000, Instruksi DOD (DODI) 5000.2 mengidentifikasi akuisisi evolusioner sebagai pendekatan yang disukai untuk akuisisi. Namun, peraturan seri 5000 tetap didominasi oleh terminologi khusus untuk Model Air Terjun. Tinjauan desain awal (PDR) dan tinjauan desain kritis (CDR), merek dagang dari Model Air Terjun, ditentukan untuk setiap program.

Apakah Model Manajemen Proyek Waterfall untuk Anda?

Meskipun banyak kekurangan dan batasannya, Model Air Terjun masih digunakan sampai sekarang. Namun, tidak ada satu metode manajemen proyek yang sesuai dengan kebutuhan semua bisnis, bahkan tidak semua proyek ditangani oleh bisnis yang sama. Jadi, apakah itu model yang ideal untuk kebutuhan proyek Anda tergantung pada berbagai faktor.

Karena bisnis bervariasi menurut jenis, ukuran, industri, dan banyak faktor lainnya, begitu juga proyek. Daripada mencari metodologi yang terbaik, bisnis harus mempelajari metodologi ini, kegunaannya, dan aplikasinya dan memutuskan metodologi terbaik untuk mereka sesuai dengan variabel berikut:

• Tujuan organisasi
• Nilai inti
• Kendala proyek
• Pemangku kepentingan Proyek
• Ukuran proyek
• Biaya proyek
• Kemampuan mengambil risiko
• Kebutuhan akan fleksibilitas

Model Waterfall digunakan oleh bisnis yang persyaratan produk akhirnya tetap namun waktu dan uangnya bervariasi. Model Waterfall memungkinkan manajer proyek untuk memulai proyek yang sama beberapa kali sampai hasil yang diinginkan tercapai. Tidak banyak bisnis akan menemukan mekanisme built-in dari metodologi Waterfall untuk menyesuaikan dan memikirkan kembali pendekatan mereka sampai mereka mencapai hasil optimal yang diinginkan.

Metodologi Waterfall sangat ideal untuk proyek dengan persyaratan yang dipahami dengan jelas, tetap dan terdokumentasi, alat teknis, arsitektur dan infrastruktur yang dipahami dengan baik, akses ke sumber daya yang cukup dengan keahlian yang diperlukan, produk yang terdefinisi dengan baik, dan siklus hidup yang singkat. Pendekatan linier Model Air Terjun tidak memungkinkan penemuan atau perubahan apa pun pada persyaratan produk awal. Setiap perubahan pada persyaratan akan mengharuskan proyek harus kembali ke tahap satu dan seluruh proses dimulai dari awal lagi. Ini bisa menjadi masalah serius di banyak industri, yang sebagian besar bekerja dengan garis waktu yang ketat.

Tabel berikut ini cukup membantu. Lihatlah.

Tabel 1: Persyaratan Model Air Terjun

Metodologi manajemen proyek sangat penting untuk bisnis saat ini. Dengan menggunakan gaya yang sesuai untuk bisnis Anda, Anda dapat mengubah cara tim Anda berkolaborasi, mengerjakan tugas, dan menyelesaikan pencapaian proyek.

Aplikasi di Industri Perangkat Lunak

Model Waterfall banyak digunakan dalam industri perangkat lunak ketika persyaratan produk didefinisikan dengan jelas. Menurut Royce, program paling sederhana dapat diselesaikan hanya dalam dua langkah: Analisis dan Coding. Namun, untuk program yang lebih kompleks mungkin diperlukan perencanaan yang lebih.

Langkah pertama untuk pengembangan perangkat lunak apa pun adalah membuat spesifikasi fungsional. Agar Model Air Terjun menjadi efektif, spesifikasi ini penting untuk direncanakan dengan baik dan didefinisikan dengan jelas. Ini akan melibatkan berbicara dengan pakar bisnis dan memeriksa proses bisnis yang saat ini dilayani oleh sistem komputer manual atau lama untuk lebih memahami proses bisnis.

Lihat Juga : Apakah JIRA Perangkat Lunak Manajemen Proyek yang Kontraproduktif Di Pasar Saat Ini?

Ketika persyaratan dicatat, mereka harus dikonfirmasi oleh pakar bisnis dan klien. Ketika spesifikasi fungsional diselesaikan, salinan terakhir dari persyaratan dirancang dan dikunci.

Ini diikuti oleh produksi aplikasi prototipe yang tidak berfungsi bersama dengan antarmuka pengguna. Ini membantu klien, serta pengembang, memahami bagaimana produk akan berfungsi. Setelah tahap ini selesai, pengembangan perangkat lunak dimulai.

Ketika aplikasi selesai dan diuji, rilis beta diterbitkan dan disediakan untuk pengujian. Setiap bug yang ditemukan dengan cepat diperbaiki. Ketika tidak ada bug signifikan yang tersisa, aplikasi dapat ditayangkan sebagai rilis versi 1.0.

Aplikasi untuk Industri Otomotif

Industri seperti konstruksi dan manufaktur telah menggunakan Model Air Terjun sejak sebelum Dr. Royce menerbitkan makalahnya pada tahun 1970. Proses perakitan dan manufaktur industri mobil bersifat kaku dan memerlukan sedikit penyesuaian setelah pabrik didirikan. Dengan demikian, persyaratan utama dibahas dan diselesaikan bahkan sebelum pabrik didirikan dan desain serta proses produksi disiapkan dengan mengingat persyaratan.

Proses perakitan itu sendiri mengikuti serangkaian tugas yang harus dilakukan begitu saja atau seluruh proses runtuh. Hanya setelah satu tahap selesai, proses dapat dilanjutkan ke tahap berikutnya. Setiap perubahan pada persyaratan dapat memerlukan perombakan total proses dan membutuhkan waktu dan uang ekstra.

nTugas Vs Air Terjun Di SDLC

Setelah Anda menentukan bahwa Model Waterfall adalah model yang paling sesuai dengan kebutuhan Anda, Anda harus mempertimbangkan penggunaan sistem manajemen proyek kolaboratif berbasis cloud seperti nTask. Alat kolaboratif seperti nTask dirancang khusus untuk meningkatkan produktivitas dan efisiensi tim Anda, apa pun metodologi manajemen proyek yang Anda gunakan.

Dengan bantuan nTask, Anda dapat dengan mudah mengelola proyek dengan berbagai ukuran, menetapkan dan mendelegasikan tugas, berbagi file dan informasi secara real-time dan memenuhi semua kebutuhan manajemen proyek Anda.

Memutuskan untuk mencoba metodologi air terjun? Sekarang setelah Anda melihat pentingnya dokumentasi dalam metode ini, Anda tahu langkah pertama adalah menemukan platform untuk melacak semua tugas yang diperlukan dan membaginya dengan tim Anda.

nTask dapat membantu dari saat Anda mengumpulkan persyaratan hingga fase pengujian:

• Kelola dan uraikan dengan jelas durasi dan libatkan pemangku kepentingan dari setiap tahap.
• Kumpulkan, diskusikan, dan dokumentasikan semua persyaratan secara real-time dengan semua pemangku kepentingan terkait. Dengan nTask, tahap selanjutnya hanya akan dimulai pada penyelesaian tahap sebelumnya diikuti hanya dengan dokumentasi dan persetujuan yang lengkap.
• Buat alur kerja untuk tim Anda berdasarkan persyaratan akhir. nTask memungkinkan Anda untuk melihat dengan jelas kemajuan proyek dan memungkinkan Anda untuk memberikan umpan balik pada setiap tugas di setiap tahap Model Air Terjun.
• nTask memudahkan untuk berkolaborasi dan berkomunikasi dengan seluruh tim atau hanya sebagian dari tim.
• Membuat, memelihara, dan membagikan dokumentasi lengkap untuk setiap tahap Model Waterfall menjadi mudah dengan bantuan nTask. Anda dapat mengontrol siapa yang dapat melihat dokumentasi sehingga hanya informasi relevan yang dibagikan dengan anggota tim.

Meskipun pada titik ini kami benci untuk memotong, ini adalah posting dua bagian. Untuk pembaruan lebih lanjut, tandai halaman ini dan jangan lupa untuk menindaklanjutinya setelah satu atau dua minggu. Sekarang, jika Anda memiliki sesuatu untuk dibagikan, Anda dapat melakukannya melalui bagian komentar di bawah. Atau, Anda dapat mengirim email kepada kami di [email protected]. Kami ingin menghubungi Anda kembali.

Baca juga:

• 21 Aplikasi Produktivitas Gratis Terbaik Tahun 2022
• 23 Aplikasi Daftar Tugas Terbaik Tahun 2022 untuk Manajemen Tugas Pribadi
• 10 Keterampilan Manajemen Proyek Penting untuk Manajer Proyek tahun 2022
• Metode Getting Things Done (GTD) dan 14 Aplikasi & Alat GTD Terbaik
• 19 Perangkat Lunak Pelacakan Waktu Teratas untuk Meningkatkan Produktivitas Tim
• 27 Perangkat Lunak Manajemen Tugas Terbaik untuk Startup di 2022
• 36 Aplikasi Produktivitas Gratis Terbaik tahun 2022
• 30 Aplikasi To-do List Terbaik tahun 2022 untuk Manajemen Tugas Pribadi
• 22 Alat Manajemen Proyek Gratis Terbaik untuk Tim Agile pada tahun 2022
• Mengelola Tim Virtual: Tantangan, Tip & Alat Manajemen Tim Virtual
• 47 Kutipan Kerja Tim Terbaik Untuk Merayakan Kolaborasi & Motivasi