OberonCore

Таким образом, разработка архитектуры программы, программирование и всё, что с связано с этим процессом - это отдельная часть, связанная с ЭВМ. Она является, своего рода, воплощением в материю. А математика используется лишь на определённых участках создания ПО, как инструмент описания законов происходящих процессов.

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

Дополнил

Точное попадание ++.

Но, между прочим, у строителей есть проект производства работ. То есть не только чертежи дома, но и еще "чертежи", что в каком порядке делать... Так что не все так уж просто с программированием, если проект большой, как дом.

С этим тоже трудно поспорить (как с утверждением) - но это несколько из другой оперы - "архитектура , менеджмент сложных программных продуктов". Не стоит их мешать.

Это уже технические особенности. Никто не говорил, что просто. Напротив, довольно сложный процесс. Особенно без чертежей.

Не... Если уж проводить аналогию. У строителей есть архитектурный архитектурный проект. Это, в нашем понимании (по ГОСТ ЕСПД) - эскизный проект. Или внешнее проектирование, та самая архитектура. Далее у строителей есть инженерный проект - это наш технический проект, или детальное проектирование, или внутреннее проектирование. А вот проект производства работ - это план-график разработки.

Я имел ввиду первую составляющую.

Строго говоря, любое творение проходит пять стадий:
1. Анализ и Моделирование;
2. Проектирование;
3. Планирование;
4. Реализация;
5. Использование.
Суть каждой стадии:
1. а. Сбор информации (требований), их анализ.
1. б. Построение моделей на основе результатов анализа. Первичная селекция моделей.
2. а. Проработка (детализация, обсчет и т.п.) выбранных моделей. Окончательное проектирование (проработка не только всех деталей, но и их сочленений, агрегатов). Модельная проверка функционирования будущего творения, соответствия требованиям, сформированным на первом этапе.
2. б. Проект производства. Моделируется процесс производства будущего творения. Определяются основные стадии/переделы производства; формируется перечень потребных ресурсов с указанием объемов/сроков потребления/использования.
3. а. Планируется процесс производства. Формируются графики поставок/заказов необходимых ресурсов.
3. б. Составляются графики завершения производственных стадий и планы-графики загрузок производственных мощностей (при необходимости, формируются также планы привлечения внешних производственных мощностей: аренда, лизинг, субподряд и т.п.).
4. а. Оперативное планирование процесса производства, потребления ресурсов, загрузки мощностей.
4. б. Фактическое производство. Сбор и обработка данных о прошедшем производственном процессе. Выработка корректирующих действий для п. 4. а.
5. а. Эксплуатация творения (получение положительного эффекта). Оценка эксплуатационных свойств творения, соответствия этих свойств тем, что были включены в исходные требования.
5. б. Корректировка требований к творению, выработка новых требований и отказ от каких-то предыдущих требований. Формализация требований и переход к п. 1. а.

И строительство, и разработка ПО, и любая другая деятельность включает в себя эти стадии в явном или неявном виде...

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

Не вполне понял, -- Вы хотите меня поправить? В чём конкретно? В разборе употребления слова "программирование"? Или в том, что "самая трудоемкая" часть она потому нередко и трудоёмкая, что там нужны специальные знания, которых обычно нет у программера?

Или в том, что программеры под лозунгом "профессионализма", "качества ПО" и прочей "эффективности" прячут свой корыстный интерес в поддержании избыточной сложности инструментария (или психиатрический интерес в поддержке собственного эго), иначе в целом ряде случаев они будут просто не нужны?
*****************
PS Пожалуй, надо оговориться, что цитирование слов не означает обвинение в адрес впервые их употребившего.
Сфера ИТ прежде всего -- "коллективное явление", которое выстраивается и поддерживается локальными интересами, интерпретируемыми тоже локально. То есть до конца не осознаваемыми.