Водопадная модель разработки

Водо­пад­ная или кас­кад­ная модель раз­ра­ботки про­грамм­ного обес­пе­че­ния (waterfall, водо­пад) — это про­цесс раз­ра­ботки, в кото­ром после­до­ва­тельно про­хо­дят фазы сбора и ана­лиза тре­бо­ва­ний, про­ек­ти­ро­ва­ния и про­то­ти­пи­ро­ва­ния, реа­ли­за­ции, тести­ро­ва­ния, инте­гра­ции и поддержки.

Сле­дуя водо­пад­ной моде­ли, раз­ра­бот­чики строго последовательно пере­ходят от одного про­цесса к дру­го­му. Сна­чала пол­но­стью завер­ша­ется этап сбора тре­бо­ва­ний — составлется спи­сок выяв­лен­ных тре­бо­ва­ний к ПО. Только после того как тре­бо­ва­ния собраны и зафик­си­ро­ва­ны, про­ис­хо­дит пере­ход к про­цессу про­ек­ти­ро­ва­ния, в ходе кото­рого фор­ми­ру­ется тех­ни­че­ское зада­ние на раз­ра­бот­ку, содер­жа­щее опи­са­ние задач, сто­я­щих перед раз­ра­бот­чи­ка­ми, а также спо­со­бов их реа­ли­за­ции и име­ю­щихся огра­ни­че­ний. После того как про­ек­ти­ро­ва­ние пол­но­стью завер­ше­но, раз­ра­бот­чи­ками выпол­ня­ется реа­ли­за­ция про­екта согласно тех­ни­че­скому зада­нию — если на при­мере раз­ра­ботки сай­та, то рису­ется дизайн, осу­ществ­ля­ется верстка и про­грам­ми­ро­ва­ние. После того как фаза раз­ра­ботки завер­ше­на, про­из­во­дится тести­ро­ва­ние и отладка раз­ра­бо­тан­ного про­дук­та: на этой ста­дии выяв­ля­ются и устра­ня­ются все недочёты согласно тех­ни­че­скому зада­нию. После этого осу­ществ­ля­ется запуск про­екта и обес­пе­чи­ва­ется его под­держка — обес­пе­че­ние рабо­то­спо­соб­но­сти и устра­не­ние оши­бок.

Водо­пад­ная модель под­ра­зу­ме­ва­ет, что пере­ход от одной фазы созда­ния про­дукта к дру­гой про­ис­хо­дит только после пол­ного завер­ше­ния преды­ду­щей фазы и что пере­ходов назад и пере­кры­тия фаз не про­ис­хо­дит.

Раз­ра­ботка ПО в рам­ках этой модели поз­во­ляет строго зафик­си­ро­вать бюд­жет и сро­ки. Одна­ко, работа по этой модели может быть эффек­тивна только в том слу­чае, если Заказ­чик весьма детально пони­мает цели и задачи раз­ра­ба­ты­ва­е­мого про­дукта, а также спо­со­бен их сфор­му­ли­ро­вать. Это обу­слов­лено тем, что объём работы тоже фик­си­ру­ется — если что-то не попало в ТЗ, то это скорее всего не будет реализовано в рам­ках согла­со­ван­ного бюд­жета и сроков. Внесение изме­не­ний в водо­пад­ные про­екты тоже доста­точно про­бле­ма­тич­но. Таким обра­зом для реально боль­ших про­ек­тов и для раз­ра­ботки чего-либо инно­ва­ци­он­ного такая модель не под­хо­дит.

Аль­тер­на­тива «водо­паду» — итеративная модель раз­ра­ботки (раз­лич­ные «гиб­кие» мето­до­ло­гии, напри­мер).