Специфика создания ПО как вида конструкторской деятельности

В конце 40-х – начале 50-х годов текущего столетия ошибки программирования не представляли серьезной проблемы. Они объяснялись отсутствием опыта при использовании новой техники. Казалось, что по мере приобретения практических навыков процесс написания программ превратится в такое же обычное занятие, как управление велосипедом или мотоциклом. Однако ни в шестидесятые, ни в семидесятые годы положение существенно не изменилось.

Сложные технические проекты (мосты, здания, дороги...) чаще всего завершались в предусмотренные сроки и в рамках сметной стоимости. В отношении же разработки программного обеспечения больших систем никто не осмеливался высказывать подобные прогнозы. Поставки программного обеспечения часто задерживались, были ненадежны и требовали больших затрат на сопровождение.

Трудности в разработке ПО порождаются, очевидно, комбинациями различных специфичных причин, некоторые из которых приведены ниже.

1. Внутренняя сложность процесса и "неалгоритмичность" человеческого мышления. Процессу разработки ПО присуща высокая сложность (научная сложность автоматизируемой области + логическая сложность программ). Простота и естественность машинных команд обманчива, к тому же человеческий мозг не привык мыслить детерминировано и строго, как компьютер.

2. Абстрактность. Управление и создание ПО проходит "вслепую", трудно "увидеть", что происходит.

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

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

4. Строгость оценки и путаница в требованиях. Во многих других отраслях промышленности существуют "допуски". В программировании же их нет и не может быть. В то же время требования к требуемому ПО изначально расплывчаты, а часто и запутанны.

5. Трудности планирования. Инженеру проще предусмотреть возрастание стоимости работ, вызванного увеличением размеров сооружения, чем разработчику программного обеспечения определить сложность программы большего объема. Попытки экстраполяции опыта разработки небольших программ на проектирование программного обеспечения больших систем, как правило, обречены на неуспех.

6. Неприменимость традиционных методов управления. Когда программистский проект начат, практически ничем нельзя повлиять на скорость его выполнения; добавление рабочей силы сверх исходного уровня, заранее установленного для этого этапа, приводит к весьма незначительным результатам, порой даже противоположным желаемым.