Организация товарного производства программ. Часть 2.

Удешевление вычислительной техники, разработка программных средств поддержки отдельных видов работ и управления совместным использованием ресурсов (особенно реализация идей виртуализации ресурсов) позволили перейти от пакетного режима использования ЭВМ к диалоговому, точнее, к оптимальному сочетанию этих режимов. Принято считать, что диалоговый режим в 2— 5 раз повышает производительность труда программистов, так как теперь не программисты, а ЭВМ стоит в очереди на обслуживание.

Эксперименты показывают, что даже минимальные задержки негативно сказываются на производительности труда разработчиков. Видимо, это связано с разрывом цепочек действий. Согласно публикациям, производительность труда увеличивается на 62 % при уменьшении времени отклика системы с 2,23 до 0,84 с (Г. Н. Ламберт) и вдвое при уменьшении времени отклика с 2,0 до 0,25 с (А. Дж. Тхадхани). В этих исследованиях время отклика 0,84 с удалось получить при 40%-ной загруженности ЭВМ с использованием TSO/SPF в операционной системе MVS, а 0,25 с — при 50%-ной загруженности ЭВМ с использованием VM/CMS. Эксперименты проводились на программных проектах трудоемкостью соответственно 35 и 375 человеко-месяцев.

Устранение затрат, связанных с чрезмерной специализацией и пакетным режимом работы служб производства ПО, могло бы дать значительно больший эффект, чем диалоговый режим использования ЭВМ, но возможность реализации этого представляется пока проблематичной. Даже если правила допускают оперативное решение вопросов, например по телефону, сказываются присущие людям ограничения. Интерактивный режим требует частой смены решаемых задач, а человек не центральный процессор. Ему для переключения требуются минуты, часы, иногда и значительно большие промежутки времени — может порваться цепочка действий или рассуждений.

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