Tahukah Anda bahwa ada metodologi manajemen proyek yang berbeda? Masing-masing mencakup semua siklus operasi utama:

• Pengembangan persyaratan
• Perencanaan
• Desain
• Pengkodean
• Pengujian
• Optimasi.

Hari ini kita akan membicarakan dua di antaranya. Dua yang kami gunakan secara aktif dalam proyek kami. Kami membaca, menganalisis, memilih. Berikut perbandingan dua metodologi - Agile dan Waterfall.

Lincah

Metodologi ini didasarkan pada 12 prinsip (yang disebut Agile Manifesto). Mari kita lihat prinsip praktis utama Agile:

• Pelanggan dapat mengubah atau menyesuaikan kebutuhan mereka pada setiap tahap pengembangan.
• Indikator terbaik efektivitas tim adalah solusi yang berhasil.
• Cara komunikasi yang paling produktif adalah komunikasi pribadi.
• Versi baru produk dirilis setelah setiap iterasi atau setiap beberapa bulan (tergantung proyeknya).

Sebuah studi profesional berskala besar dilakukan pada tahun 2015. Dia menargetkan 601 proyek IT. Hasilnya menunjukkan bahwa Agile adalah pendekatan manajemen proyek yang paling umum saat ini.

Agile: manfaat

• Kemampuan untuk mengulang sepenuhnya suatu proyek bahkan setelah melalui beberapa iterasi.

• Proyek ini dibagi menjadi segmen pendek dan transparan (iterasi), dalam Scrum disebut sprint.

• Fleksibilitas Agile meminimalkan semua risiko yang mungkin terjadi.

• Agile sangat ideal untuk pengembangan MVP.

Tangkas: Kekurangan

• Menghitung anggaran proyek menjadi sangat rumit karena persyaratan yang terus berubah.
• Tim pengembangan tidak hanya harus berkualifikasi tinggi, tetapi juga berorientasi pada pelanggan.
• Persyaratan baru sering kali bertentangan dengan arsitektur proyek saat ini.
• Penyesuaian terus-menerus terhadap persyaratan terkadang menimbulkan perasaan bahwa proyek tidak akan pernah selesai :)

Air terjun

Metodologi Air Terjun didasarkan pada prinsip pengembangan yang konsisten. Secara singkat, diagram alur manajemen proyek terlihat seperti ini:

1. Analisa Kebutuhan
2. Perencanaan
3. Penerapan
4. Pengujian dan optimasi
5. Penyebaran
6. Mendukung

Transisi ke setiap langkah berikutnya hanya dimungkinkan setelah selesainya tahap sebelumnya. Pada saat yang sama, memperkenalkan fungsionalitas baru diperbolehkan setelah proyek diterapkan dan semua bug telah diperbaiki.

Air Terjun: manfaat

• Struktur manajemen yang jelas dan logis (bagus bahkan untuk tim dengan sedikit pengalaman).
• Dokumentasi keren yang tidak memungkinkan adanya perbedaan dan salah tafsir.
• Memungkinkan Anda melacak sumber daya, waktu, dan kemungkinan risiko dengan mudah.
• Jumlah tugas yang konstan untuk pengembang.

Air Terjun: Kerugian

• Waterfall tidak berarti kemampuan untuk menyesuaikan kebutuhan; itu tidak cukup fleksibel.
• Waterfall membutuhkan lebih banyak waktu dan sumber daya dibandingkan dengan Agile.
• Anda hanya dapat “mencoba” proyek Anda setelah proyek tersebut dirilis. Tidak ada kemungkinan untuk mengubah fungsionalitas selama proses pengembangan.
• Interaksi minimal antara pelanggan dan tim pengembangan.

Apa yang harus dipilih?

Agile adalah pilihan Anda jika:

• Anda memiliki tim pengembangan yang berpengalaman.
• Anda tidak memiliki gambaran akurat tentang fungsi akhir produk.
• Perubahan pada proyek harus dilaksanakan secepat mungkin.
• Anda ingin terlibat aktif dalam proyek selama pengembangannya.
• Anda perlu mengirimkan produk yang berfungsi secepat mungkin.
• Anda adalah seorang pemula.

Pilihan Anda adalah Air Terjun jika:

• Persyaratan proyek Anda kemungkinan besar tidak akan berubah.
• Kualitas produk jauh lebih penting daripada waktu dan sumber daya yang ingin Anda investasikan di dalamnya.
• Anda tidak terlalu tertarik untuk mengamati hasil antara setelah setiap tahap pengembangan dan tidak berusaha untuk mengambil bagian aktif dalam proyek.

Dan terakhir, mari kita lihat statistiknya. Hal ini menunjukkan bahwa proyek yang dilaksanakan menggunakan Agile memiliki peluang keberhasilan tiga kali lebih besar dibandingkan proyek yang dikelola menggunakan metodologi Waterfall.

Agile dan Air Terjun: Kesimpulan

Anda tidak akan pernah menemukan solusi terbaik untuk manajemen proyek. Sebuah metodologi yang dapat dengan sempurna menyederhanakan semua tahap pengembangan dan menyeimbangkan semua risiko yang mungkin terjadi hanya ada dalam fantasi. Kerugian terbesar dari Waterfall adalah kurangnya fleksibilitas. Dengan menggunakan metodologi ini, Anda tidak akan dapat mengubah persyaratan proyek selama proses pengembangan. Dan kemampuan untuk beradaptasi dengan kondisi pasar modern saat ini merupakan nilai tambah yang besar.

Namun, bukan berarti Air Terjun itu buruk dan harus dilupakan. Ini bagus untuk proyek kecil. Nah, jika Anda belajar menggabungkan Agile dan Waterfall secara kompeten dalam satu proyek, ini akan membuka cakrawala baru dan memberikan banyak peluang menarik.

Pengembangan perangkat lunak. Hari ini kita akan membicarakan yang paling populer – Air terjun, atau metodologi kaskade.

Konsep umum pendekatan ini dikemukakan oleh Dr. Winston Royce pada tahun 1970. Hal ini didasarkan pada urutan langkah logis yang harus diambil sepanjang siklus hidup pengembangan perangkat lunak. Setiap tahap disetujui oleh karyawan yang kompeten, didokumentasikan dan diteruskan.
Meskipun popularitas model Waterfall telah berkurang dalam beberapa tahun terakhir, sifat proses sekuensial yang digunakan dalam metode Waterfall secara intuitif lebih dekat dengan pengembang dan karena itu mendominasi TI.

Bagaimana air itu jatuh

Model yang diusulkan oleh Royce sangat sederhana dan mudah dipahami. Terdiri dari 7 blok yang masing-masing mencakup wilayah tanggung jawabnya sendiri.

Model ini tidak relevan di semua tempat dan tidak di setiap perusahaan. Jauh sebelum perangkat lunak mulai dikembangkan di setiap gedung perkantoran, pengembangan perangkat lunak dilakukan oleh perusahaan besar, yang pertama-tama adalah waktu dan keakuratan kepatuhan terhadap spesifikasi teknis, dan kedua, kebenaran dan kelengkapan keputusan yang dibuat pada setiap tahap.

Itulah sebabnya model air terjun sering disalahartikan sebagai proses pengembangan yang mengecualikan interaksi antar tahapan dalam urutan terbalik tanpa alasan yang menentukan. Dan tahapannya sendiri seringkali terfragmentasi untuk menyenangkan banyak badan pengawas, atau digabungkan karena profesi pengembang yang terkait.

Kami juga akan mengurangi model yang ditentukan menjadi 6 blok, menggabungkan operasi “Instalasi” dan “Dukungan” menjadi satu – “Penerapan”. Sekarang mari kita lihat fungsi yang dapat dieksekusi:

Persyaratan. Sederhananya, pada tahap ini semua dokumentasi masukan dibuat, sesuai dengan pengembangan yang akan dilakukan. Pertama-tama, kebutuhan dan keinginan pelanggan dianalisis, kemudian diproyeksikan ke dalam kemampuan perusahaan dan keadaan pasar. Hasilnya adalah sebuah dokumen yang menjelaskan apa yang harus dilakukan oleh perangkat lunak, namun tidak menjelaskan bagaimana atau dengan alat apa.

Desain. Pada tahap ini, logika pengoperasian perangkat lunak disepakati. Masih belum ada keputusan implementasi spesifik yang dibuat di sini, namun fungsi semua bagian aplikasi sudah dijelaskan. Pada akhirnya, para pengembang sudah memiliki gambaran tentang berapa lama proyek tersebut dapat memakan waktu dan personel.

Konstruksi. Di sini kita sudah berbicara tentang alat khusus untuk mengimplementasikan ide: persyaratan desain, bahasa pemrograman, tingkat data, layanan, dll. Disepakati. Kerangka logika yang dijelaskan di bagian sebelumnya memperoleh “daging”; untuk pertama kalinya, penampilan dari produk jadi terbentuk.

Perwujudan. Tahap eksekusi, yang biasanya mencakup sebagian besar pengembangan. Jika model klasik memungkinkan interaksi bebas dengan tahapan sebelumnya, maka dalam praktiknya hanya perubahan kecil pada “Desain” yang diperbolehkan.

Pengujian. Pada tahap ini, QA, beta, dan semua penguji lainnya menemukan dan melaporkan masalah dalam aplikasi. Fase ini paling sering menyebabkan perlunya pengulangan fase pengkodean sebelumnya untuk menyelesaikan masalah kritis. Jika pengujian menghasilkan revisi kode yang sering, hal ini menyebabkan kembalinya ke tahap desain.

Penyebaran. Setelah aplikasi dibuat, aplikasi dapat disajikan kepada pelanggan dan dilepaskan ke alam liar. Karena tahap ini juga mencakup dukungan, interaksi dengan tahap sebelumnya tidak dapat dihindari.

Keuntungan dari model kaskade

Dalam beberapa tahun terakhir, model air terjun telah kehilangan posisi terdepan karena metodologi yang lebih fleksibel. Hal ini disebabkan oleh dinamika umum di bidang TI, ketika tim yang terdiri dari 5-9 orang bertanggung jawab atas pengembangan perangkat lunak, dan tenggat waktu dapat dengan mudah diubah karena meningkatnya fungsionalitas.

Namun, model air terjun masih relevan untuk proyek dan organisasi besar. Dan itulah kenapa:

• Tahan terhadap perubahan komposisi personel. Pengembang mungkin datang dan pergi sepanjang siklus hidup proyek, namun karena dokumentasi yang terperinci, hal ini berdampak kecil pada lini waktu proyek.
• Disiplin. Model air terjun memaksa pengembang yang terlibat dalam proyek untuk disiplin dan tetap pada jalurnya. Jika perlu, badan pengelola yang bertanggung jawab atas pengambilan keputusan ditambahkan ke model umum, sementara pelaku diharuskan bekerja dalam kerangka sistem.
• Fleksibilitas pada tahap awal. Perubahan pada tiga fase pertama dapat dilakukan segera dan dengan sedikit usaha karena tidak didukung oleh kode. Dengan demikian, pelanggan dan kontraktor memiliki cadangan waktu yang signifikan untuk melakukan perubahan radikal dalam konsep pengoperasian perangkat lunak.
• Fokus pada tenggat waktu dan keuangan. Karena kenyataan bahwa setiap tahap menguraikan secara lengkap garis besar perangkat lunak masa depan, semua pengembang memahami peran, batasan pekerjaan, dan tenggat waktu mereka. Hal ini memungkinkan Anda untuk beroperasi dengan bilangan real di depan pelanggan, yang membuat model proyek menarik.

Kekurangan model air terjun

Pada tahun 1970-an, ide-ide Royce masih relevan. Namun setelah hampir 50 tahun, metode pengembangan air terjun menjadi semakin tidak cocok untuk TI. Itu sebabnya:

• Struktur perangkat lunak non-adaptif. Pada tahap pertama, model air terjun bisa fleksibel, tetapi jika masalah dalam keseluruhan struktur teridentifikasi selama tahap pengujian, hal ini akan menimbulkan konsekuensi bencana dalam bentuk tenggat waktu yang terlewat dan bahkan kegagalan pelanggan. Dengan demikian, peran manajer dan pengembang yang bertanggung jawab semakin meningkat, yang tingkat kompetensinya sering menimbulkan permasalahan di perusahaan mana pun.
• Mengabaikan pengguna akhir. Semakin rendah proses bergerak dalam air terjun, semakin berkurang peran pelanggan, apalagi klien yang diwakilinya. Membuat perubahan apa pun pada fungsionalitas perangkat lunak akan memulai seluruh rangkaian tahapan baru, sehingga produk yang diperoleh dengan menggunakan model kaskade masih jauh dari menargetkan pengguna massal.
• Pengujian terlambat. Dari uraian di atas mudah untuk mengidentifikasi tahap metodologi yang paling bermasalah – pengujian. Di sinilah kesalahan yang paling sering dilakukan pada setiap tahap diidentifikasi. Metodologi yang lebih tangkas menggunakan pengujian sebagai aktivitas mendasar yang terjadi secara terus-menerus. “Waterfall” memungkinkan rendahnya kualifikasi karyawan di setiap tahap dan kualitas pelaksanaan yang buruk, karena dengan pengujian yang terlambat, masalah tidak dapat diselesaikan secara mendasar, hanya dengan bantuan “tambalan”.

Ternyata metodologi kaskade merupakan solusi yang sangat baik dalam hal waktu dan pelaporan, namun sangat lemah dalam hal kualitas. Oleh karena itu, saat ini disarankan untuk menggunakannya hanya dalam tiga kasus:

1. Ketika perangkat lunak berorientasi pada pelanggan, yang membutuhkan transparansi pekerjaan dan pelaksanaan tepat waktu.
2. Jika ada manajer yang memenuhi syarat dalam staf.
3. Saat melaksanakan proyek yang tidak memiliki persaingan di pasar.

Terlepas dari kenyataan bahwa 3 poin ini menjadi semakin kurang umum dalam praktik nyata, model kaskade akan populer dan diminati sejak lama karena organisasinya yang jelas. Artinya, setiap pengembang profesional harus memahami prinsip dasarnya dan siap untuk eksis dalam kerangka skema ini.

Sayangnya, tidak ada proses pengembangan perangkat lunak universal yang sepenuhnya cocok untuk setiap proyek. Yang terdepan adalah metodologi – sistem standar yang berisi konsep, metode dan metode yang menentukan gaya pembuatan perangkat lunak.

Metodologi dipilih, pertama, untuk tugas tertentu, ruang lingkup pekerjaan, tujuan pelanggan, dan anggaran. Kedua, jangan lupakan aktivitas spesifik perusahaan IT. Dukungan teknis, outsourcing, dan pengembangan internal proyek Anda memerlukan pendekatan yang berbeda.

Beberapa kategori model pengembangan perangkat lunak yang paling umum adalah Agile dan Waterfall, masing-masing fleksibel dan air terjun. Kami akan memberikan penjelasan singkat masing-masing, mempertimbangkan kelebihan dan kekurangannya, dan memutuskan sistem yang tepat untuk proyek tersebut.

Metodologi tangkas menganut prinsip pengembangan berulang. Proses pembuatan produk dibagi menjadi serangkaian siklus pendek 1-4 minggu. Setiap iterasi adalah proyek terpisah dengan perencanaan, desain, pemrograman, pengujian, dan retrospektif.

Saat membayar pengembang dalam kerangka Agile, mereka biasanya memilih antara tim khusus untuk proyek tersebut (Tim Khusus) dan sistem Waktu & Bahan (T&M). Kami telah membandingkan beberapa mekanisme untuk membangun hubungan keuangan dengan kontraktor. Temuan kami dari sudut pandang klien dan pengembang dapat ditemukan.

Model pembangunan fleksibel didasarkan pada 12 prinsip, yang kami anggap sebagai hal berikut yang menentukan:

• perangkat lunak yang berfungsi adalah indikator terbaik efektivitas tim pengembangan;
• persyaratan pengeditan diterima pada setiap tahap pengembangan;
• komunikasi pribadi adalah cara komunikasi yang paling produktif;
• versi baru produk dirilis setiap iterasi atau beberapa bulan, bergantung pada proyeknya.

Kelas Agile mencakup teknik-teknik seperti Extreme Programming (XP), FDD, DSDM, Scrum dan lain-lain.

Air terjun

Prinsip sistem kaskade adalah konsistensi. Proses pengembangan dibagi menjadi beberapa langkah berikut:

1. Analisis kebutuhan

2. Perencanaan

3. Implementasi

4. Integrasi

5. Pengujian

7. Dukungan

Transisi ke setiap fase terjadi hanya setelah akhir fase sebelumnya. Fitur baru ditambahkan setelah rilis dan bug sebelumnya telah diperbaiki. Karena dokumentasi yang jelas dan persyaratan yang stabil, model interaksi keuangan harga tetap lebih cocok untuk proyek air terjun.

Sekarang mari kita bandingkan kelebihan dan kelemahan Agile dan Waterfall.

Keuntungan metodologi:

Modelnya fleksibel

• Penyesuaian terhadap persyaratan fungsional dimasukkan ke dalam proses pengembangan untuk memberikan keunggulan kompetitif. Faktanya, hanya setelah 2 kali iterasi, proyek tersebut dapat diputar 360 derajat dan dibuat menjadi produk yang sama sekali berbeda.
• Proyek ini dibagi menjadi iterasi pendek dan transparan.
• Minimalkan risiko dengan proses perubahan yang fleksibel.
• Dapatkan versi pertama produk yang berfungsi dengan cepat.

Model kaskade

• Struktur proses yang jelas dan sederhana, nyaman untuk tim dengan sedikit pengalaman.
• Dokumentasi berkualitas tinggi dan terperinci.
• Dalam sebuah proyek, Anda dapat dengan mudah melacak sumber daya, risiko, dan waktu yang dihabiskan.
• Tujuan produk konsisten dari awal hingga akhir.

Kekurangan metodologi:

Modelnya fleksibel

• Tidak mungkin menghitung jumlah pekerjaan secara pasti karena persyaratan yang terus berubah.
• Karena Agile lebih merupakan filosofi daripada proses, Anda perlu membenamkan diri dalam sistem dan menerimanya, yang tidak dibutuhkan setiap proyek.
• Tim harus berkualifikasi tinggi dan berpengalaman, berorientasi pada pelanggan.
• Persyaratan baru mungkin bertentangan dengan arsitektur atau fungsionalitas yang ada.
• Dengan segala penyesuaian dan perubahan, ada risiko proyek tidak akan pernah selesai.

Model kaskade

• Persyaratan ditentukan dan diperbaiki sejak awal, sehingga menghilangkan fleksibilitas proses pengembangan.
• Lebih banyak waktu dan sumber daya dihabiskan untuk proyek ini.
• Klien hanya akan melihat produk jadi, sangat sulit untuk mengubah apa pun.
• Kurangnya umpan balik antar tahap pengembangan.

Setelah mempelajari perangkat kerasnya, kita dapat dengan mudah belajar menggunakan Agile dan Waterfall dalam proyek kita!

Model pengembangan tangkas berfungsi jika:

1. Tim yang berpengalaman terlibat dalam proyek ini.

2. Fungsi akhir produk masih belum diketahui, dan perubahan harus dilakukan secepat mungkin.

3. Pengguna akhir terlibat dalam proyek sejak awal.

4. Penting untuk mengembangkan perangkat lunak yang berfungsi dengan cepat.

5. Anda adalah seorang pemula.

Pilih model kaskade jika:

1. Persyaratan proyek stabil dan praktis tidak berubah;

2. Kualitas produk jauh lebih penting daripada waktu dan sumber daya yang dikeluarkan;

3. Proyek dikembangkan secara outsourcing;

4. Pengguna akhir hanya menerima hasil pekerjaan tanpa ikut serta dalam prosesnya.

Harus dikatakan bahwa kedua model akan membantu mengimplementasikan proyek Anda. Pertama-tama, Anda memilih opsi yang memungkinkan Anda membuat produk berkualitas dan mengelola anggaran Anda secara efektif.

Tentu saja, begitu Anda mencapai garis finis, tidak ada yang akan peduli dengan metodologi yang dipilih. Oleh karena itu, meskipun model pengembangannya ternyata tidak sesuai, tim harus cukup kuat untuk memberikan hasil yang layak.

Sekarang pergilah dan kerjakan proyekmu!

Pada tahap pengembangan manajemen saat ini, belum ditemukan metode universal yang dapat diterapkan pada proses pengembangan perangkat lunak. Tidak ada metode optimal yang cocok untuk setiap proyek. Inti dari metode apa pun adalah standar, definisi, prosedur, fungsi, dll.

Setiap metodologi yang dipilih oleh pemimpin tim proyek dipilih untuk tugas spesifik dalam proyek, serta tenggat waktu dan anggaran yang dialokasikan oleh pelanggan. Selain itu, bidang perusahaan TI memiliki ciri khasnya sendiri: dukungan proyek, dukungan teknis, outsourcing - semua ini memerlukan pendekatan individual dari pihak perusahaan.

Metodologi yang paling populer dan diminati dalam pengembangan perangkat lunak modern adalah Waterfall (air terjun) dan Agile (fleksibel). Dalam artikel ini kami akan menjelaskan secara singkat masing-masing metodologi, mengidentifikasi kelebihan dan kekurangannya, dan mencari tahu metodologi mana yang paling cocok untuk proyek tertentu.

Lincah

Metode penyampaian proyek Agile didasarkan pada iterasi. Seluruh proses pengembangan produk perangkat lunak baru dibagi menjadi beberapa siklus yang berlangsung selama 1-4 minggu. Setiap tahapan dianggap sebagai proyek mikro tersendiri, yang didalamnya terdapat tahap persiapan, tahap perencanaan, pembuatan dan tahap dimana kesesuaian produk dengan kebutuhan pelanggan diperiksa. Hasil dari setiap iterasi adalah produk dengan serangkaian karakteristik teknis tertentu, yang dapat ditunjukkan kepada pelanggan untuk penyesuaian jika diperlukan.

Semua pengembangan perangkat lunak menggunakan metodologi Agile tunduk pada 12 prinsip utama. Yang utama adalah:

• Indikator terbaik interaksi efektif tim proyek adalah produk kerja;
• Perubahan persyaratan dapat terjadi pada setiap tahap pengembangan;
• Metode komunikasi terbaik adalah selalu tatap muka;
• Produk baru dengan karakteristik tertentu muncul di akhir setiap iterasi, atau setiap 1-2 bulan sekali; itu semua tergantung pada proyek dan pengaturannya.

Metode Fleksibel Agile paling sering mencakup metode pemrograman seperti Scrum, FDD dan lain-lain.

Air terjun

Metode Waterfall, yang berarti “air terjun” dalam bahasa Inggris, didasarkan pada pengembangan berurutan. Seluruh proses dibagi menjadi beberapa tahap berikut:

• Penelitian tentang persyaratan yang diperlukan untuk produk akhir;
• Perencanaan pekerjaan pengembangan perangkat lunak;
• Penciptaan produk;
• Integrasi;
• Melakukan kegiatan pengujian;
• Peluncuran produk perangkat lunak baru;
• Dukungan teknis dan pemeliharaan.

Peralihan dari satu tahap ke tahap lainnya hanya terjadi ketika salah satu tahap telah selesai sepenuhnya. Perubahan fungsi produk jadi hanya terjadi setelah diluncurkan ke pasar konsumen (rilis).

Keuntungan dari metode pengembangan

• Pengenalan fungsionalitas baru dan pembuatan penyesuaian yang diperlukan diintegrasikan ke dalam proses pengembangan itu sendiri, yang memungkinkan hal ini dilakukan pada setiap tahap pembuatan produk. Hal ini meningkatkan keunggulan kompetitif perangkat lunak yang sudah jadi;
• Keseluruhan proyek merupakan serangkaian iterasi transparan yang diselesaikan dalam waktu singkat;
• Karena mekanisme penyesuaian yang ada, risiko proyek berkurang;
• Versi pertama perangkat lunak ini keluar dengan cukup cepat.

Air terjun

• Struktur kerja yang transparan dan intuitif yang cocok untuk tim berpengalaman;
• Kualitas tinggi dan detail dari semua dokumentasi;
• Model air terjun memudahkan pelacakan sumber daya, risiko, dan waktu yang dihabiskan untuk pelaksanaan proyek;
• Tugas yang diberikan dibuat sestabil mungkin selama pengembangan.

Kekurangan Metode Pengembangan

• Ketidakmampuan untuk menghitung jumlah penuh yang dihabiskan untuk pembuatan perangkat lunak baru karena persyaratan yang terus berubah selama implementasi;
• Karena Agile lebih seperti sebuah filosofi, setiap orang yang terlibat dalam proyek harus sepenuhnya membenamkan diri di dalamnya, yang seringkali sangat sulit;
• Anggota tim harus berpengalaman, spesialis berkualifikasi tinggi; mereka harus bekerja untuk memenuhi kebutuhan klien;
• Munculnya persyaratan baru mungkin bertentangan dengan struktur dan fungsi yang ada;
• Kemungkinan penyesuaian terus-menerus dapat menyebabkan proyek menjadi tidak terbatas.

Air terjun

• Pendefinisian semua persyaratan pada tahap awal mengarah pada fakta bahwa proyek tidak lagi fleksibel;
• Proyek ini memerlukan lebih banyak sumber daya dan tenggat waktu;
• Pelanggan akan melihat hasil kerja tim proyek di akhir tahap pengembangan;
• Kurangnya komunikasi antar tahap implementasi.

Anda harus memilih jika kondisi berikut terpenuhi:

• Anggota tim adalah karyawan yang berpengalaman;
• Parameter akhir produk tidak pasti, dan perubahan harus dilakukan secepat mungkin;
• Pelanggan terlibat dalam pembuatan produk sejak awal;
• Kecepatan pembangunan diperlukan;
• Jika pembuatan produk perangkat lunak adalah sebuah startup.

Model kaskade harus digunakan ketika:

• Persyaratan produk diketahui dan stabil;
• Kualitas hasil jauh lebih penting daripada sumber daya dan waktu yang dihabiskan untuk proyek tersebut;
• Outsourcing digunakan untuk pembangunan;
• Pelanggan tidak berpartisipasi langsung dalam pembuatan perangkat lunak baru, tetapi hanya menjadi pemverifikasi hasil yang diperoleh.

Masing-masing metode yang dijelaskan di atas dapat membantu Anda dalam merealisasikan proyek Anda. Penting untuk dipahami bahwa ketika memilih metodologi, Anda harus fokus pada kualitas produk akhir yang tinggi dan anggaran Anda sendiri.

Saat Anda mulai bergerak di sepanjang garis finis, semua orang tidak lagi tertarik dengan metode penerapan yang Anda pilih. Oleh karena itu, meskipun metodologi yang dipilih salah, tim harus memiliki segudang pengalaman dan kompetensi agar dapat memperoleh hasil yang baik dari pekerjaannya.

Sebelum memilih metode, analisis proyek Anda, konsultasikan dengan kolega Anda di bengkel, dan komunikasikan dengan pelanggan dan bawahan. Bagaimanapun, kecepatan implementasi, kualitas, biaya, dll bergantung pada metode yang dipilih, baik itu Agile atau Waterfall.

Pemrograman,

Pengembangan aplikasi seluler

Pengembangan produk perangkat lunak mengetahui banyak metodologi yang layak - dengan kata lain, praktik terbaik yang sudah ada. Pilihannya bergantung pada spesifikasi proyek, sistem penganggaran, preferensi subyektif, dan bahkan temperamen manajer. Artikel ini menjelaskan metodologi yang sering kami temui di Edison.

1. “Model Air Terjun” (model air terjun atau “air terjun”)

Salah satu yang tertua, melibatkan tahapan yang berurutan, yang masing-masing harus diselesaikan sepenuhnya sebelum tahap berikutnya dimulai. Model Waterfall memudahkan pengelolaan proyek. Berkat kekakuannya, pembangunan berlangsung cepat, biaya dan tenggat waktu telah ditentukan sebelumnya. Tapi ini adalah pedang bermata dua. Model air terjun akan memberikan hasil yang sangat baik hanya dalam proyek dengan persyaratan yang jelas dan telah ditentukan sebelumnya serta cara untuk mengimplementasikannya. Tidak ada cara untuk mengambil langkah mundur; pengujian dimulai hanya setelah pengembangan selesai atau hampir selesai. Produk yang dikembangkan menurut model ini tanpa pilihan yang masuk akal mungkin memiliki kekurangan (daftar persyaratan tidak dapat disesuaikan kapan pun), yang hanya diketahui di akhir karena urutan tindakan yang ketat. Biaya untuk melakukan perubahan tinggi karena memerlukan waktu menunggu hingga seluruh proyek selesai untuk memulainya. Namun, biaya tetapnya seringkali lebih besar dibandingkan kerugian dari pendekatan ini. Memperbaiki kekurangan yang terjadi selama proses pembuatan adalah mungkin, dan, menurut pengalaman kami, memerlukan satu hingga tiga perjanjian tambahan pada kontrak dengan spesifikasi teknis kecil.

Dengan menggunakan model air terjun, kami membuat banyak proyek dari awal, termasuk pengembangan spesifikasi teknis saja. Proyek yang ditulis di Habré: menengah - , kecil - .

Kapan menggunakan metodologi air terjun?

• Hanya ketika persyaratannya diketahui, dipahami dan dicatat. Tidak ada persyaratan yang saling bertentangan.
• Tidak ada masalah dengan ketersediaan programmer dengan kualifikasi yang dibutuhkan.
• Dalam proyek yang relatif kecil.

2. "Model V"

Mewarisi struktur “langkah demi langkah” dari model kaskade. Model berbentuk V dapat diterapkan pada sistem yang mengutamakan pengoperasian tanpa gangguan. Misalnya program aplikasi di klinik untuk memantau pasien, software terintegrasi untuk mekanisme kontrol airbag darurat pada kendaraan, dan lain sebagainya. Ciri khusus model ini adalah ditujukan untuk pemeriksaan dan pengujian menyeluruh terhadap produk yang sudah dalam tahap awal desain. Tahap pengujian dilakukan bersamaan dengan tahap pengembangan yang sesuai, misalnya pengujian unit ditulis selama pengkodean.

Contoh pekerjaan kami berdasarkan metodologi V adalah aplikasi seluler untuk operator seluler Eropa yang menghemat biaya roaming saat bepergian. Proyek ini dilaksanakan sesuai dengan spesifikasi yang jelas, tetapi mencakup tahap pengujian yang signifikan: kenyamanan antarmuka, fungsionalitas, beban, dan termasuk integrasi, yang harus memastikan bahwa beberapa komponen dari produsen berbeda bekerja sama secara stabil, pencurian uang dan pinjaman adalah mustahil.

Kapan menggunakan model V?

• Jika pengujian menyeluruh terhadap suatu produk diperlukan, maka model V akan membenarkan ide bawaannya: validasi dan verifikasi.
• Untuk proyek kecil dan menengah yang persyaratannya didefinisikan dan ditetapkan dengan jelas.
• Dalam kondisi tersedianya insinyur dengan kualifikasi yang diperlukan, khususnya penguji.

3. "Model Tambahan" (model tambahan)

Dalam model inkremental, persyaratan sistem yang lengkap dibagi menjadi beberapa rakitan. Terminologi ini sering digunakan untuk menggambarkan perakitan perangkat lunak langkah demi langkah. Beberapa siklus pengembangan terjadi, dan bersama-sama membentuk siklus hidup multi-air terjun. Siklus ini dibagi menjadi modul-modul yang lebih kecil dan mudah dibuat. Setiap modul melewati fase definisi persyaratan, desain, pengkodean, implementasi dan pengujian. Prosedur pengembangan menurut model inkremental melibatkan pelepasan produk dengan fungsionalitas dasar pada tahap besar pertama, dan kemudian secara berurutan menambahkan fungsi baru, yang disebut “peningkatan”. Proses ini berlanjut hingga sistem yang lengkap tercipta.

Model inkremental digunakan jika permintaan perubahan individual jelas dan dapat dengan mudah diformalkan dan diimplementasikan. Dalam proyek kami, kami menggunakannya untuk membuat pembaca DefView, dan kemudian jaringan perpustakaan elektronik Vivaldi.

Sebagai contoh, kami akan menjelaskan esensi dari satu kenaikan. menggantikan DefView. DefView terhubung ke satu server dokumen dan sekarang dapat terhubung ke banyak server. Server penyimpanan dipasang di situs institusi yang ingin menyiarkan kontennya ke audiens tertentu, yang secara langsung mengakses dokumen dan mengubahnya ke dalam format yang diperlukan. Elemen akar arsitektur telah muncul - server pusat Vivaldi, yang bertindak sebagai mesin pencari terpadu untuk semua server penyimpanan yang dipasang di berbagai institusi.

Kapan menggunakan model inkremental?

• Ketika persyaratan dasar untuk sistem didefinisikan dan dipahami dengan jelas. Pada saat yang sama, beberapa detail mungkin disempurnakan seiring berjalannya waktu.
• Pengenalan awal produk ke pasar diperlukan.
• Ada beberapa fitur atau tujuan yang berisiko.

4. “RAD Model” (model pengembangan aplikasi cepat atau rapid application development)

Model RAD adalah jenis model inkremental. Dalam model RAD, komponen atau fungsi dikembangkan oleh beberapa tim berketerampilan tinggi secara paralel, seperti beberapa proyek kecil. Jangka waktu satu siklus sangat terbatas. Modul yang dibuat kemudian diintegrasikan ke dalam satu prototipe kerja. Sinergi memungkinkan Anda dengan cepat menyajikan sesuatu yang berhasil kepada klien untuk ditinjau guna menerima umpan balik dan membuat perubahan.

Model pengembangan aplikasi cepat mencakup fase-fase berikut:

• Pemodelan bisnis: mendefinisikan daftar arus informasi antar departemen yang berbeda.
• Pemodelan data: informasi yang dikumpulkan pada tahap sebelumnya digunakan untuk menentukan objek dan entitas lain yang diperlukan untuk peredaran informasi.
• Pemodelan proses: Arus informasi menghubungkan objek untuk mencapai tujuan pembangunan.
• Bangun aplikasi: Menggunakan alat perakitan otomatis untuk mengubah model CAD menjadi kode.
• Pengujian: komponen dan antarmuka baru diuji.

Kapan model RAD digunakan?

Hanya dapat digunakan oleh arsitek yang berkualifikasi tinggi dan sangat terspesialisasi. Anggaran proyek sangat besar untuk membayar para spesialis ini bersama dengan biaya alat perakitan otomatis yang sudah jadi. Model RAD dapat dipilih dengan pengetahuan yang yakin tentang target bisnis dan kebutuhan produksi sistem yang mendesak dalam waktu 2-3 bulan.

5. “Agile Model” (metodologi pengembangan fleksibel)

Dalam metodologi pengembangan “agile”, setelah setiap iterasi, pelanggan dapat mengamati hasilnya dan memahami apakah hasilnya memuaskan atau tidak. Inilah salah satu keunggulan model fleksibel. Kerugiannya antara lain karena kurangnya formulasi hasil yang spesifik, sulit memperkirakan biaya tenaga kerja dan biaya yang diperlukan untuk pengembangan. Extreme Programming (XP) adalah salah satu aplikasi model agile yang paling terkenal dalam praktiknya.

Jenis ini didasarkan pada pertemuan harian singkat - “Scrum” dan pertemuan rutin yang berulang (seminggu sekali, dua minggu sekali, atau sebulan sekali), yang disebut “Sprint”. Dalam pertemuan harian, anggota tim mendiskusikan:

• melaporkan pekerjaan yang telah diselesaikan sejak Scrum terakhir;
• daftar tugas yang harus diselesaikan karyawan sebelum pertemuan berikutnya;
• kesulitan yang dihadapi selama bekerja.

Metodologi ini cocok untuk proyek-proyek besar atau proyek-proyek yang ditujukan untuk siklus hidup yang panjang, terus-menerus beradaptasi dengan kondisi pasar. Oleh karena itu, persyaratan berubah selama proses implementasi. Patut diingat kelompok orang-orang kreatif yang cenderung menghasilkan, memunculkan, dan mencoba ide-ide baru setiap minggu atau bahkan setiap hari. Pengembangan tangkas paling cocok untuk tipe manajer ini. Kami mengembangkan startup internal perusahaan menggunakan Agile. Contoh proyek klien adalah Sistem Pemeriksaan Kesehatan Elektronik, yang dibuat untuk melakukan pemeriksaan kesehatan massal dalam hitungan menit. Di paragraf kedua ulasan ini, mitra Amerika kami menjelaskan hal yang sangat penting yang mendasar bagi kesuksesan di Agile.

Kapan menggunakan Agile?

• Ketika kebutuhan pengguna terus berubah dalam bisnis yang dinamis.
• Perubahan tangkas diterapkan dengan biaya lebih rendah karena seringnya peningkatan.
• Berbeda dengan model air terjun, model tangkas hanya memerlukan sedikit perencanaan untuk memulai suatu proyek.

6. “Model Iteratif” (model berulang atau iteratif)

Model siklus hidup berulang tidak memerlukan spesifikasi persyaratan yang lengkap untuk memulai. Sebaliknya, pembuatan dimulai dengan implementasi suatu fungsi, yang menjadi dasar untuk menentukan persyaratan lebih lanjut. Proses ini berulang. Versinya mungkin tidak sempurna, yang utama berfungsi. Memahami tujuan akhir, kami mengupayakannya agar setiap langkah efektif, dan setiap versi dapat diterapkan.

Diagram menunjukkan "perkembangan" berulang dari Mona Lisa. Seperti yang Anda lihat, pada iterasi pertama hanya ada sketsa Mona Lisa, pada iterasi kedua muncul warna, dan iterasi ketiga menambah detail, saturasi, dan melengkapi prosesnya. Dalam model inkremental, fungsionalitas produk dibangun sepotong demi sepotong, produk terdiri dari bagian-bagian. Berbeda dengan model iteratif, setiap bagian mewakili elemen yang lengkap.

Contoh pengembangan berulang adalah pengenalan suara. Penelitian pertama dan penyiapan perangkat ilmiah dimulai sejak lama, pertama dalam pikiran, kemudian di atas kertas. Dengan setiap iterasi baru, kualitas pengenalan meningkat. Namun pengakuan yang sempurna belum tercapai, sehingga permasalahan belum terselesaikan sepenuhnya.

Kapan waktu optimal untuk menggunakan model berulang?

• Persyaratan untuk sistem akhir didefinisikan dengan jelas dan dipahami sebelumnya.
• Proyeknya besar atau sangat besar.
• Tujuan utama harus didefinisikan, namun rincian implementasi dapat berkembang seiring berjalannya waktu.

7. "Model Spiral" (model spiral)

“Model spiral” mirip dengan model inkremental, namun dengan penekanan pada analisis risiko. Ini bekerja dengan baik untuk memecahkan masalah bisnis yang kritis ketika kegagalan tidak sesuai dengan aktivitas perusahaan, dalam konteks peluncuran lini produk baru, ketika penelitian ilmiah dan pengujian praktis diperlukan.

Model spiral melibatkan 4 tahap untuk setiap putaran:

1. perencanaan;
2. analisis resiko;
3. desain;
4. evaluasi hasil dan, jika kualitasnya memuaskan, transisi ke tahap baru.

Model ini tidak cocok untuk proyek-proyek kecil; ini masuk akal untuk proyek-proyek yang kompleks dan mahal, misalnya, seperti pengembangan sistem aliran dokumen untuk bank, ketika setiap langkah selanjutnya memerlukan lebih banyak analisis untuk menilai konsekuensinya daripada pemrograman. Pada proyek pengembangan EDMS untuk ODU Siberia SO UES, dua pertemuan tentang perubahan kodifikasi bagian arsip elektronik membutuhkan waktu 10 kali lebih lama daripada menggabungkan dua folder oleh seorang programmer. Proyek-proyek pemerintah yang kami ikuti dimulai dengan persiapan oleh komunitas ahli sebuah konsep yang mahal, yang tidak selalu sia-sia, karena membuahkan hasil dalam skala nasional.

Mari kita rangkum

Slide ini menunjukkan perbedaan antara dua metodologi yang paling umum.

Dalam praktik modern, model pengembangan perangkat lunak bersifat multivariat. Tidak ada satu model yang tepat untuk semua proyek, kondisi awal, dan model pembayaran. Bahkan Agile, yang sangat kita cintai, tidak dapat diterapkan di mana-mana karena ketidaksiapan beberapa pelanggan atau ketidakmungkinan pembiayaan yang fleksibel. Metodologi-metodologi tersebut sebagian tumpang tindih dalam hal cara dan sebagian serupa satu sama lain. Beberapa konsep lain hanya digunakan untuk mempromosikan penyusunnya sendiri dan tidak menerapkan sesuatu yang baru dalam praktik.

Tentang teknologi pengembangan:
.
.
.
.

Hanya pengguna terdaftar yang dapat berpartisipasi dalam survei ini. Silahkan masuk.