Кризис программного обеспечения

Кризис программного обеспечения — это термин, используемый для описания периода в истории разработки программного обеспечения (конец 1960-х — 1980-е годы), а также для обозначения хронических проблем в индустрии, связанных с несоответствием между растущей сложностью создаваемых программных систем и возможностями существующих методов и инструментов их разработки. Кризис проявлялся в систематическом превышении сроков и бюджетов проектов, низком качестве и ненадёжности конечного продукта, а также в трудностях его сопровождения и модификации.

История возникновения и осознания проблемы

Предпосылки

В 1950-е — начале 1960-х годов программирование было уделом узкого круга специалистов, а программы имели сравнительно небольшой объём и решали ограниченный круг задач. Разработка велась «кустарными» методами, часто одним человеком, без формального проектирования и документирования. По мере распространения компьютеров в бизнесе, науке и государственном управлении в середине 1960-х годов возникла потребность в создании крупных, сложных программных комплексов (операционные системы, системы управления базами данных, системы управления предприятиями).

Конференция в Гармиш-Партенкирхене (1968)

Ключевым моментом в осознании кризиса стала конференция НАТО по программной инженерии, проведённая в 1968 году в Гармиш-Партенкирхене (ФРГ). На ней впервые был публично употреблён термин «кризис программного обеспечения» (software crisis). Участники конференции, среди которых были ведущие специалисты из США и Европы, констатировали, что традиционные методы разработки, заимствованные из индивидуального программирования, не работают при создании крупных систем. Проекты регулярно проваливались: срывались сроки, превышались бюджеты, а полученные программы содержали большое количество ошибок и были крайне сложны в обслуживании.

Основные проявления кризиса

Кризис программного обеспечения проявлялся в следующих систематических проблемах:

Превышение бюджета и сроков. Стоимость разработки часто в несколько раз превышала первоначальные оценки, а сдача проекта задерживалась на годы.
Низкое качество. Программное обеспечение содержало множество дефектов (багов), которые было трудно обнаружить и исправить. Надёжность систем оставалась низкой.
Несоответствие требованиям. Готовый продукт часто не удовлетворял реальным потребностям заказчика, либо требования менялись в процессе разработки, и система не успевала адаптироваться.
Сложность сопровождения. Код был плохо структурирован, слабо документирован, что делало его модификацию и исправление ошибок крайне трудоёмкими и дорогими.
Низкая производительность труда. Программисты тратили значительное время на рутинные операции, а не на решение содержательных задач.

Причины кризиса

Технологические и методологические причины

Отсутствие инженерного подхода. Разработка программного обеспечения долгое время воспринималась как искусство или ремесло, а не как инженерная дисциплина. Не применялись формальные методы проектирования, тестирования и управления проектами.
Сложность управления. С ростом размера команды и объёма кода резко возрастало количество связей между компонентами, что делало управление проектом и координацию работы разработчиков крайне сложной задачей. Закон Брукса (Fred Brooks, «Мифический человеко-месяц», 1975) гласит: «Добавление рабочей силы к запаздывающему проекту делает его ещё более запаздывающим».
Неадекватные языки и инструменты. Ранние языки программирования (ассемблеры, Фортран, Кобол) были ориентированы на решение вычислительных или бизнес-задач, но не предоставляли средств для структурирования больших программ, управления памятью, обработки ошибок и модульного тестирования. Отладка была трудоёмким процессом, часто с использованием перфокарт и распечаток.
Недостаток формальных методов. Отсутствие математически строгих методов спецификации, верификации и доказательства корректности программ приводило к тому, что ошибки обнаруживались только на этапе тестирования или эксплуатации.
Проблемы коммуникации. Сложность передачи знаний между заказчиком, аналитиком, проектировщиком и программистом приводила к искажению требований и недопониманию.

Организационные и человеческие причины

«Серебряной пули» нет. Фред Брукс в своей знаменитой статье 1986 года утверждал, что не существует единого технологического прорыва, который мог бы кардинально повысить производительность и качество разработки ПО, как это произошло в других инженерных дисциплинах (например, появление транзистора в электронике).
Неверные оценки. Программисты систематически недооценивали сложность задач, особенно на ранних этапах, когда требования были неясны.
Отсутствие повторного использования кода. Каждый проект часто начинался «с нуля», что приводило к дублированию усилий и накоплению ошибок.

Реакция на кризис: возникновение программной инженерии

Осознание кризиса привело к формированию новой дисциплины — программной инженерии (software engineering), которая ставила своей целью внедрение инженерных принципов в процесс разработки ПО. Ключевые направления преодоления кризиса включали:

Структурное программирование

В 1970-х годах получила распространение парадигма структурного программирования, предложенная Эдсгером Дейкстрой и другими. Она предполагала отказ от оператора безусловного перехода (GOTO) и использование только трёх базовых управляющих конструкций (следование, ветвление, цикл). Это делало код более читаемым, предсказуемым и легче поддающимся верификации.

Методологии проектирования

Были разработаны формальные методологии, такие как:

Нисходящее проектирование (Top-down design). Разбиение задачи на подзадачи, каждая из которых реализуется отдельным модулем.
Модульное программирование. Разделение программы на независимые, слабо связанные модули с чётко определёнными интерфейсами.
Структурный анализ и проектирование (SADT, Structured Analysis and Design Technique). Методология, использующая диаграммы для описания функций системы и потоков данных.

Инструментальные средства

Компиляторы и интерпретаторы стали более мощными, появились языки высокого уровня, поддерживающие структурное программирование (Pascal, C, Ada).
Системы управления версиями (SCCS, RCS, CVS) позволили отслеживать изменения в коде и координировать работу нескольких разработчиков.
Среды разработки (IDE) начали объединять редактор, компилятор и отладчик в единую среду.

Модели жизненного цикла

Каскадная модель (Waterfall). Предложенная Уинстоном Ройсом в 1970 году, она предполагала последовательное выполнение этапов: анализ требований, проектирование, реализация, тестирование, сопровождение. Эта модель, хотя и подвергалась критике за жёсткость, стала первым формальным описанием процесса разработки.
Спиральная модель (Барри Боэм, 1988). Ввела итеративный подход с анализом рисков на каждом витке спирали, что позволяло снижать неопределённость и корректировать требования.

Современное состояние и критика термина

Хотя термин «кризис программного обеспечения» возник в 1960-х годах, многие проблемы, характерные для того периода, сохраняются и в XXI веке. Проекты по-прежнему запаздывают, выходят за рамки бюджета, а программное обеспечение содержит ошибки. Однако масштаб и характер проблем изменились.

Аргументы против использования термина

Некоторые специалисты (например, Джеймс Бах) считают, что термин «кризис» устарел и не отражает реального положения дел. Они указывают на то, что:

Индустрия программного обеспечения стала огромной и успешной, создавая продукты, которые работают в критически важных системах (авиация, медицина, финансы).
Разработаны и широко применяются эффективные методологии (Agile, Scrum, DevOps), которые позволяют управлять сложностью и быстро адаптироваться к изменениям.
Качество многих программных продуктов (например, операционных систем, браузеров, игр) находится на высоком уровне.

Современные вызовы

Вместо единого «кризиса» сегодня говорят о ряде хронических проблем и вызовов:

Сложность интеграции. Современные системы состоят из множества взаимодействующих компонентов, часто от разных производителей, что создаёт проблемы совместимости и безопасности.
Безопасность и уязвимости. Растущее количество кибератак и уязвимостей в программном обеспечении является серьёзной проблемой.
Управление требованиями. В условиях быстрого изменения рынка и технологий требования к ПО постоянно меняются, что требует гибких подходов.
Дефицит квалифицированных кадров. Несмотря на рост числа программистов, спрос на высококвалифицированных специалистов, способных работать со сложными системами, остаётся высоким.
Наследие (Legacy). Огромное количество работающего ПО написано на устаревших языках и платформах, его сопровождение и модернизация требуют значительных затрат.

Таким образом, «кризис программного обеспечения» — это исторический термин, обозначивший переломный момент в развитии индустрии, который привёл к формированию программной инженерии как научной и инженерной дисциплины. Хотя острые проявления кризиса 1960-х годов были в значительной степени преодолены, фундаментальные проблемы сложности, качества и управления проектами остаются актуальными и сегодня.

Источники

Брукс Ф. «Мифический человеко-месяц, или Как создаются программные системы». — СПб.: Символ-Плюс, 1999.
Дейкстра Э. «Дисциплина программирования». — М.: Мир, 1978.
Боэм Б. «Спиральная модель разработки и усовершенствования программного обеспечения» (1988).
Ройс У. «Управление разработкой крупных программных систем» (1970).
Материалы конференции НАТО по программной инженерии, Гармиш-Партенкирхен, 1968.
Бах Дж. «Кризис программного обеспечения: миф и реальность» (1999).

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →