Кажется, мы стали забывать, как должен выглядеть полный цикл разработки ПО. При разборе старых завалов, был обнаружен артефакт — документы ещё советской научно-исследовательской работы конца 70-х по созданию системы управления разработкой проектов программных комплексов. Это уже сложно достоверно установить, но, возможно, именно она легла в основу ГОСТ 19, разработанного примерно в то же время.

Среди прочего, в откопанной документации была найдена такая вот замечательная схема этапов разработки больших программных систем. Кроме самих этапов, на ней отображена, и это важно, цикличность всего процесса. Кто-то сказал про этот ваш «аджайл»?..

Она настолько прекрасна, что я решил векторизировать её существенную часть и использовать в дальнейшем как справочную диаграмму. Показывать себе и окружающим как напоминание того, как оно должно быть на самом деле.

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

В 90-х годах это, вместе с очень многим другим, было выкинуто и забыто как неактуальное знание мёртвой империи. Но из своего опыта, уже достаточно большого, что бы можно было делать такие обобщения, я могу сказать, что именно к такой схеме работы надо хотя бы стремиться. Костыльно-ориентированное, «сиюминутное» программирование появляется именно из-за пренебрежения работой по проектированию системы и её алгоритмов. И если для небольших или типовых программных продуктов это ещё допустимо, хотя и влечёт увеличение трудозатрат и потери в эффективности из-за недостаточно обоснованных решений, то в больших проектах это уже через пару месяцев приведёт к полному распаду системы на плохо интегрированные лоскутные куски.

Может, даже получится как-то склеить эти куски костылями в единое целое. Но уже в этот момент приходит понимание, что рождённое чудо некромагии не выдержит ещё одной итерации разработки и, конце-концов, его придётся выбрасывать. И делать всё с нуля. Поэтому, лучше сразу придерживаться (или хотя бы стараться) процесса разработки, уже выстраданного набитыми шишками многих инженеров до нас.

comments powered by HyperComments